Android Context lifecycle

Question

This has been bothering me for a while.

Simply put, can activity context be passed around without preventing the OS from destroying it when applicable?

Example:

An asynchronous request on a socket is made, attached to this is an hashmap where key=request_id and value=activity_context. Upon response, the id is linked to fetch the activity_context and a method in the activity is called (i.e. using interface, casting etc).

I am aware of storing weakreferences to the context, yet the android OS garbage collection is known to clean up weakreferences in cases where it is still 'alive' with increasing frequency.

Please feel free to request further information, I'd really like a conclusive answer on this.

http://android-developers.blogspot.in/2009/01/avoiding-memory-leaks.html. check this — Raghunandan, Jun 26 '13 at 15:57
How exactly are you thinking about to pass Context in a socket request? Remember that it is not Serializable. — Pozzo Apps, Jun 26 '13 at 16:01
I would recommend using other approaches to get information from the service(?) managing the socket to the UI layer, such as `LocalBroadcastManager`, a third-party event bus like Otto or greenrobot's EventBus, etc. — CommonsWare, Jun 26 '13 at 16:21

score 1 · Answer 1 · answered Jul 08 '13 at 09:50

Thank you for your response, it is MUCH appreciated!

In regards to your statement,

It cannot be the other way: you cannot prevent the destruction of an Activity. But if you keep a reference to such object, it won't be garbage collected while being of no real use to you. Simply put, a memory leak that you may want to avoid. Does this ever prevent a new a new activity with the same context being created? i.e. I do not want to return to the previous context.

In answer to your questions:

lifecycle of the socket: Activity related? one for whole app until process is killed or user logs out?
- the socket is linked to the app process, being initiated with user login and disconnected with user logoff (and app background... I know, customer request)
when the device configuration is changed and activity is recreated: do you want to receive response to the old request in new Activity?
- yes I do, although this is not a huge issue as of now as orientation changes are disabled with meta-tags such as android:configChanges="orientation|screenSize" and android:screenOrientation="nosensor"
when you finish the Activity (or user presses BACK) before the response is ready and then return to it after, do you expect to see it?
- Mmm... tricky, mostly not. I am using greenrobot's EventBus mentioned by @CommonsWare which allows sticky events. Example, user backrounds app while the login process is initiated, I need to capture the result to avoid repetitive login sessions

In regards to

Do you mean WeakReference's reference is nulled while there are strong references to the object? I don't think this can happen.

I apologise for this. I can't back it up at the moment, I just remember reading about this in a Google group. I will post here if I ever see it again.

score 0 · Answer 2 · answered Jun 26 '13 at 17:42

can activity context be passed around without preventing the OS from destroying it when applicable?

It cannot be the other way: you cannot prevent the destruction of an Activity. But if you keep a reference to such object, it won't be garbage collected while being of no real use to you. Simply put, a memory leak that you may want to avoid.

An asynchronous request on a socket is made, attached to this is an hashmap where key=request_id and value=activity_context. Upon response, the id is linked to fetch the activity_context and a method in the activity is called (ie using interface, casting etc).

There is nothing particularly wrong which such an approach, but to avoid leaks (and potential crashes caused by them) I suggest removing from the Map all requests related to Activity as it goes into destroyed state. If that's possible with your architecture, you can also cancel these request.

That said, it's probably better to follow CommonsWare's advise and use one of the approaches from his comment that are built for such use cases.

I could theorize here and eventually write a whole article on it here, so it would be best if you updated your question with the following information:

lifecycle of the socket: Activity related? one for whole app until process is killed or user logs out?
when the device configuration is changed and activity is recreated: do you want to receive response to the old request in new Activity?
when you finish the Activity (or user presses BACK) before the response is ready and then return to it after, do you expect to see it?

I am aware of storing weakreferences to the context

The problem with WeakReferences is that they do not help avoiding leaks. Yes, they help avoiding permanent leaks, where you would keep a bad reference indefinitely, but they do not prevent calls to already destroyed Activity.

the android OS garbage collection is known to clean up weakreferences in cases where it is still 'alive' with increasing frequency.

Do you mean WeakReference's reference is nulled while there are strong references to the object? I don't think this can happen.

Android Context lifecycle

2 Answers2