Where to Unbind the Presenter
I took many tries to find best MVP pattern for Android applications I wrote. One of the questions that came back several times was: When a presenter is allowed to change the UI? The goal of this article is more to show consequences on particular solution, rather then provide one correct answer.
The Options
What I usually see developers do, is binding (attaching) presenter with the view at onCreate() and unbinding (detaching) at onDestroy() callbacks. This is the most natural approach, because it gives control to presenter “from the beginning”, and some actions like navigation drawer setup requires to be invoked early in the lifecycle.
On the other hand, when you are interacting with objects that can survive configuration change (i.e. screen rotation) things might get complicated. You might find yourself in a situation when newly created activity’s onCreate() is called before onDestroy() of the dying one. Let’s take this code as an example:
Presenter is listening to changes from SingletonService which is one for the application. Listener registration called from onCreate() will be shortly followed by unregister call from onDestroy. This is something to watch out for.
When you feel that presenter should not change a view which is not visible, you might consider binding in onStart() and unbinding in onStop(). This is a better approach when you’re doing some work in background thread (read along for more). On the other hand you won’t know if the view being bound just came back from “stack” or it’s a “fresh” one, and needs extra setup from presenter.
To be sure that changes are safe to be made on view, which user is currently interacting with, it’s best to bind in onResume() and unbind in onPause(). Still, there are some scenarios, when you need to show changes in paused state - i.e. in split screen mode one of the applications is not focused, and user expects it to work normally.
Asynchronous
When you’re dealing with async work you need to take into consideration that user might background your app before the task is completed. You want to unbind the presenter in such cases to avoid memory leaks and crashes. This problem is more visible when combined with Fragment transactions.
With such code you will get a lot of IllegalStateException: Can not perform this action after onSaveInstanceState. Of course this can be avoided with commitAllowingStateLoss(), but in most cases you don’t really want to lose the state… I recommend this article, if you want to dive deeper.
And this is not only Fragments problem. If you modify View object after the activity’s onSaveInstanceState() was called, the changes will get lost after the process is killed.
You need to be aware that onSaveInstanceState() is called only when there’s a possibility that Android system might need to restore the UI state. I.e. when you are exiting the screen (by back button), the callback will not be triggered, and you will still need to unbind the presenter.
Conclusion
There’s no silver bullet. Each case requires analyses. But in general, when your application is doing only synchronous processing (user interaction has immediate UI change consequence) your best choice is to stick to onCreate() and onDestroy(). Otherwise, what I found works best is binding and unbinding in two places, while checking presenter state.
