Search code examples
android-lifecycleandroidrobospice

Is RoboSpice shouldStop() really needed?


I wonder if the shouldStop() method of SpiceManager is needed at all.. I got the idea that it is supposed to unbind the possible listeners from activity/fragment, but if the activity is going to be killed anyway, does it matter? Garbage collector will still clean the activity/fragment and the background services are still going to finish themselves separately. Or am I wrong here please? Does Android really leak when you forget some reference in a background thread?

There are some (misguiding) comments in the source code: for shouldStop() it says it will do the unbinding asynchronously, and for shouldStopandJoin() synchronously. But shouldStop calls shouldStopAndJoin, and shouldStopAndJoin comment is saying that it is mostly a testing method. So do we really need to call shouldStop in activity's onStop() callback?

I am asking this because I would like to have a spicemanager instance in Application context that has no special way of dealing with cleanup or stopping things. So I want to be sure there is no leaking or things like that. To be clear, not really in Application context, but a custom "controller" that is launched from app context and manages all background stuff like robospice requests or location stuff. I am trying to emulate MVC pattern where all the logic is really independent from activities and fragments which have only @Subscribe methods for changing the UI.

EDIT: Actually, if I call this from application context then it's different case than Activity or Fragment. Even if Activities or Fragments did leak, Application should not, right?

Thanks for any comments.


Solution

  • Does Android really leak when you forget some reference in a background thread?

    Yes, it does. That's precisely a very good way to create leaks.

    So do we really need to call shouldStop in activity's onStop() callback?

    Yes you do in order 1) to prevent leaks, 2) to prevent your callbacks from being triggered after the death of the launching context, which would cause a crash. But you are right, javadocs might lead to confusion. ShouldStopAndJoin is called for testing (see it as private + tests) and shouldStop is public.

    Even if Activities or Fragments did leak, Application should not, right?

    Right. When the application dies, it means the whole app process dies and there is no way anything can leak outside of a VM in Java. So, for application classes, there is no way to call shouldStop properly and it's not needed.