I wonder if this is a crossDomain policy issue. I'm not sure, but you might try:
crossdomain.xml (must be named this - needs to be on the web root of the remote domain.
<!DOCTYPE cross-domain-policy SYSTEM
<!-- put other domains on each line here -->
Sorry if I missed the point.
Thanks for answering. Regarding crossdomain, I highly doubt that's the issue. I've run my app in firebug and checked for any failed data calls and there are none. Also, if it were a crossdomain.xml, from what I know about crossdomain is that the data call would have never responded with data to begin with. This RTE is happening after I get a response from the server. The data is there, it's just not being casted correctly.
Maybe the response comes back before the PlayerPageSummary class gets
registered or the class isn't registering at all, or maybe you are getting
results from a different server request. It looks like the RTE passes
through InitializeStorefrontServiceResponseCommand so I would add some code
there that reports some diagnostics like the properties on the ObjectProxy
and whether the PlayerPageSummary can be retrieved via getClassAlias.
That's a very helpful response. I hadn't thought about that. I'll look into throwing some console messages to see what the status of that class is at the time of the response.
One question though, why do you think it would be fine in a debug build and not a release build? Do you think the extra debug code or something to that extent is slowing it down to allow the class to be registered in time?
We don't have enough information to be making good guesses about what is
going on. Let's see what you find out about the class and response data.
Usually, folks have problems with hardwired URLs and end up hitting a
different server when they deploy the app.
That makes sense. I would love to provide more, but this is a confidential project. I'll take a look at the stuff you mentioned, and if that still doesn't help I'll see what I can do about providing more info. (Worst case maybe break it out into a POC to reproduce the issue)
Thanks for your help and here's an update on this from me. We did try out your suggestion to see if "PlayerPageSummary can be retrieved via getClassAlias". I'm not the one that did the testing, but my teammate who did, said that the class being registered was not the issue.
While he was working on that I further investigated our ANT builder and configuration to see what might have been different between ANT building non-debug SWF and Flash Builder building non-debug SWF. Turns out that my teammate had added some [ArrayElementType] metadata that I was not aware of. Once I realized that, I added it as metadata to be kept in my flex-config.xml which ended up solving the debug vs. release mode issues.
Afterwards, I double-checked the livedocs and also did some Googling. From the above it appears that debug SWF keep all metadata without you needing to explicitly tell it to. On the other hand, outside of a handful of metadata tag such as [Bindable] release builds neeed to be told what to keep.
Does this sound right?
Also, do you know off the top of your head if this is documented by Adobe anywhere and what the link is? I had a real tough time finding anything mentioning how debug SWF retain all metadata.
Thanks again for your help!
I don't think there is much doc on the differences between debug and release
swfs. We want to reserve the ability to make changes to debug swfs to make
them compile faster and easier to debug and profile.
Currently, more metadata is pruned, trace statements are removed (and thus
any computation the trace statement would have caused like toStrings() or
any evaluation of an expression), and constant pools are combined which can
change the order of class initialization.
Ok, so I guess knowing all metadata is kept in a debug SWF will just have to be a piece of knowledge derived from experience and is subject to be changed by Adobe in the future.
It's too bad the documentation is suffering so that Adobe can reserve the right to change things, I understand that from a business perspective. However, as a lowly third party developer having more precise and accurate documentation could have saved significant time troubleshooting for me. I know that's not your call though.
Thanks for the assistance though, you're always awesome in that regard!
I too am a "lowly" developer that is subject to Adobe's sometimes quirky features/bugs issues - many times I have cussed out loud at them (of course they don't hear me). But like you, I also believe they are an amazing company.