How does robospice manage activity lifecycle?

Question

I'm looking for a technical answer to how the android robospice library manages activity lifecycle. From the getting started page:

https://github.com/octo-online/robospice/wiki/Starter-Guide

"As an inner class of your Activity (or other context), add a RequestlListener that will update your UI. Don't worry about memory leaks, RoboSpice manages your activity's life cycle."

My question is how does robospice automatically update the request listeners so that it still is able to call the correct listener with the correct context after a rotation and after the activity has been destroyed and recreated as a new instance?

I've been trying to reverse engineer the source code but haven't found an answer yet:

https://github.com/octo-online/robospice

Myna

Answer 1

@Take Chances Make Cha. What you are saying is just completely right. RS has been designed with this express need in mind : managing network requests and activities' life cycles.

@craigrs84. Basically, what happens with RS is that when a request is being processed, its listeners will be invoked as long as the associated activity is alive. If the activity is not alive anymore, all of its listeners are unplugged from RS, and they will not be notified.

The main purpose of RS is to make sure that there is no memory leak : your activity, if it has to die, will die and be garbage collected, RS doesn't hold any hard reference to it that would prevent garbage collection. That's really the core idea behind RoboSpice.

If you want a new instance of your activity to be replugged to a pending request (for instance you execute a request, then rotate the device and then get a new instance of your activity, and want that new instance to receive the result of the request executed by the previous instance), that's possible with RS.

In such a case, use the method spiceManager.addListenerIfPending in on start, right after the call to spiceManager.start(..). This will not execute a new request, but re-plug a new listener to a pending request. If no request is pending, then it will do nothing.

Pyrargyrite

So if you don't provide a requestCacheKey, and have multiple instances of the same Activity running at the same time, will addListenerIfPending still work correctly? Or is there not enough information in that case? This is probably an unlikely scenario but I'm curious. – Myna

@snicolas, I am curious, if you do not call shouldStop() (or the non-async method) doesn't the library call back to those listeners registered to Activities, Fragments, Services, etc? Without digging too much through the source and based on my early usage and testing of your library, I would get an exception when I received a callback to an Object that had "died". Also, the library is great, please keep up the good work! – Dorking

If you do not call shouldStop, then listeners will be triggered. This can cause crashes and memory leaks as often listeners are inner classes and hold a reference on an activity instance that would have been destroyed, and it can even crash if you do things like findViewById in your listeners. I think you got it, just wanted to make things clear. – Pyrargyrite

Oh, I just realize I completly misunderstood your answer. Sorry – Pyrargyrite

Thanks for the feedback! I just wanted to make sure I wasn't missing anything or misinforming anyone. All the best, and looking forward to the next release! – Dorking

Answer 2

The short answer, from my experience, is that it doesn't.

For example, if you don't call SpiceManager.shouldStop() and execute a request, the reference to the RequestListener is still retained and you may end up with a memory leak as it tries to update whatever is referenced within it if your Activity/Fragment/Service no longer exists.

Dorking

Sorry, but no, there is no memory leak in RS with listeners. They are removed and garbage collected right in shouldStop. – Pyrargyrite