I've struggled with this since Jan 9th, 2013 (if not longer) and the only conclusion I can come to is that this simply does not function. No matter what I try and no matter what resource (and I'm finding precious few) I follow to try to implement this within Flash Builder 4.7, Flex SDK 4.6.0 (Build 23201), AIR SDK 3.5, I only succeed in creating a file (with the correct name) that is 123 bytes in size that reads back in as NULL;
I've tried using ByteArray.writeObject()/readObject() as an intermediary with FileStream.writeBytes()/readBytes(), with no luck.
I've tried instantiating an object, setting properties and then using that. I've tried instantiating my correctly formed ValueObject (including the remoteClass alias metadata tag).
I've tried using -verbatim- the example provided in the top most suggested 'Community Help' resource http://www.switchonthecode.com/tutorials/adobe-air-and-flex-saving-ser ialized-objects-to-file It is worth noting that this solitary example of the procedure/SDK-usage is dated to Flex SDK 3.0 and at least 04/04/2009 (first comment on the article).
My frustrating hell (one version of many methods attempted) is detailed on StackOverflow (including -all- mxml, as, and trace output), but so far, no assistance has been forthcoming, alas. This is a severely stripped down and simplified version of what had been a far more complex attempt:
An earlier post* detailing a far more complex attempt interation, with, alas, just as little help (guess this isn't a hot button topic) forthcoming:
* I previously suspected that it was only failing from within iOS on an iPad, but the first example (the stripped down version) made it evident that it didn't work in the AIR mobile device simulator (iPad) in the Windows environment, and indeed, didn't work in a non-mobile project in the windows environment AIR launcher.
I'm at a loss, upset, frustrated, in major trouble with my supervisor/deadlines, etc.
I would very much appreciate any suggestions/help/confirmation/etc.
Just to move ahead with development I've opted for a far less preferable solution of writing out both an XML file and a JPG file. I very much do not like this and very much want to store encapsulated serialized objects locally in the same way I assume will work for storing remotely with AMFPHP (if the project ever gets to that point *sigh*).
Again. Would be so grateful for any help.
It looks like you have Re: Fairly certain that FileStream.writeObject() and FileStream.readObject() do not function - at all -. instead of Re: Fairly certain that FileStream.writeObject() and FileStream.readObject() do not function - at all -.. Could that be the issue? But either way, I don’t think BitmapData can be serialized. I think you have to create a custom serializer for it.
Thank you for your response, but I'm not able to understand the first part. I think it somehow replaced parts of your response with links to this forum post (how very odd).
I may be missing something (entirely possible *chuckle*), but as to serializing BitmapData, to the best of my knowledge, any entity that extends Object (Object is the superclass for BitmapData) can be serialized for Action Message Format.
I'll try to research more, because very often I do find that I'm mistaken in my understanding.
The version that came into my email notification had a bit more information. I think yes, that you're right, that I needed to capitalize the metadata tag. I'm going to scream if that's the reason and the pre-compiler never even gave a warning. Thanks. I'll let you know and mark you as the answer if that resolves it.
Somewhere I think we documented that displayobjects are not serializable. I don’t know if BitmapData counts among that or not, but I wouldn’t be surprised if it doesn’t reconsititute itself.
I think that I've shown pretty conclusively that it would never hurt for a pre-compiler to at least generate a warning on any one might 'add'... something along the lines of
'XXXX' does not match internally defined metadata tag name. Ignore this warning if 'XXXX' represents a user-defined metadata tag name.
Ah well. Two weeks of frustrating hell and angry boss because I chose to copy an example rather than type it out and possibly have caught the error if the code introspection had failed to popup like it does if one begins to add [Binda... or similar.
I'm really frustrated at documentation for readObject() writeObject() methods that make absolutely NO reference to the not-un-complex details that needs must be gotten right for serialization and deserialization... Only via third-party examples, forum replies, etc does anyone find anything-like that which should be in the internal documentation. I'm all the more frustrated at methods that throw NO ERROR when used incorrectly... I doubt very very much that anybody EVER wants to write a 'null' object and read a 'null' object.
Ah well. Over the last year and a half I've stopped expecting even a modicum of documentation that's of any help to anyone who does not already know all the methodology/technique/pitfalls..... it is usefully only as a memory aid when one has not memorized every detail of the API.
AIR far worse than AS3
Mobile FAR FAR worse than AIR.
I'm still confused. How is BitmapData a DisplayObject? The documentation says:
|Class||public class BitmapData|
Is the Implementation of IBitmapDrawable what causes it to be a DisplayObject, or does that arrow between BitmapData and Object not represent an entire inheritance tree, but instead just the Alpha and the Omega, the beginning and end, as it were?
Either way, by this point I had been using ByteArray(s) in my serializable value object, and I'm pretty certain that they are not displayobjects (If they are, then I REALLY don't know what I'm doing *chuckle*... I'm beginning to wonder.)
Ah yes, you are correct that BitmapData is not a DisplayObject. But did it serialize correctly? I don’t trust that anything in the flash.display package will. Almost everything in that package is backed by non-AS objects internal to the player.
I want to add to this post as I marked it as "The Answer" though it does not indeed contain the answer directly, for those who come looking for simliar solutions.
harUI prompted me to realize that my metadata term needed to be capitalized (RemoteClass instead of remoteClass). As the metadata tags may be user defined, the compiler throws no errors (or warnings *grumble*)
// [remoteClass(alias="PTotmImageVO")] incorrect
public class PTotmImageVO