For Mixbook.com, I have a Page class which manages an array of text and image items. When a user deletes an image item, the page component calls ImageItem.dispose(). Inside here, I clean up any listeners to the system manager, and explicitly dispose of the BitmapData that the item is using – which frees the memory of the bitmap immediately, instead of waiting till the next garbage sweep.

Another example of dispose(), is the LoadManager class that is used throughout Mixbook.com. This class essentially controls anything from preloading images, to loading stylesheets and fonts – where each type of loadable item has its own class. Based upon where the user is in the book, requests to load items are being either added or removed from the LoadManager class. When a load item is removed from the LoadManager, the LoadManager calls dispose() on the item, which cleans up any resources its using. Such as calling Loader.close().

So the dispose() method simply acts as an interface that the parent can use to say to its children, “Hey, I know the life of this object is finished, clean up any references/resources it’s using.”

@Larry, I think you got it :-). When B adds a listener to A, A is holding a reference to B. Because of this, B will not be garbage collected until A is removed from memory, or B removes its listener from A, or the only references to A are weak, which triggers A to be removed from memory.

Yes, you are right when you say that removing listeners is not necessary for memory leak prevention. As long as all the listeners you add to object A are weak.

Basically, if object B adds a listener to object A, the result is that A has a
reference to B. This means that B cannot be garbage collected, even if it is no
longer used.

Now, if B is otherwise a target for garbage collection, it is certainly no
longer interested in events from A.

So, it seems to me like the weak reference option is there to protect you from
not cleaning up. Instead of removing event listeners from B, you just
rely on the weak reference because you know that if object B is otherwise
a candidate for removal, it certainly isn’t interested in events anymore.

If my analysis is correct, the only time you need a strong reference to an
event listener is when you think that this single reference to your object
is the only thing keeping it from being kicked out. But how
often does that happen? If nobody has a reference to an object, that
object is doing nothing, so it won’t be missed.

Seems to me that weak references to event listeners should always
be safe. I’m not sure that removing listeners is necessary for memory
leak prevention.

Someone please correct me if I’m wrong.

Then in program add (something to the lines of) if(isset(limit)) ONLY DISPLAY FLIGHTS CONTAINING limit VALUE

Thats how I would do it (But I am a noob )

None the less, Beautiful!

The fact id that I convert an object to byte array but when i am trying to convert the byte array back to the object it’s not working properly.

It’s returning an object but it’s losing some properties.If you can kindly help me on that with some code.

you have been very helpful thanks for your time. thanks a lot.

Oh dear, I forgot to mention that you need to put the [RemoteClass] metatag in the ObjectState class. I’ve updated this post to reflect this.

If that doesn’t work, I would try opening up your debugger and making sure that the length of your returned byte array is larger than 0. Also, I’ve never tried this with an HTTPService, only Flash Remoting, so this might be the crux of the problem too.

Definitely try the [RemoteClass] metatag first though. I’m almost certain that’s the root of the problem.

Tell me what you come up with

I have tried the class MyCompContainer and the method retrievedMementoHandler but not been able to convert the byte array to objectstate type object.Please help.

Thanks and regards