Reactive MVP (Part 2) — Presenter
In Part 1 I’ve talked about the benefits of Reactive MVP. In this part I will show you how I’ve implemented Reactive Presenter.
Before we start, lets answer a question that is always on my mind when trying out new things — will I need a library and extend a bunch of classes to benefit from Reactive MVP? The answer is NO. It should be simple enough for everyone to put all pieces together and get going.
All Presenters at some point in their life need to be made aware of when the View becomes available and when it goes away. The most common way to do it is to have some methods in the Presenter that provide necessary information. If you choose to mimic Activity/Fragment life-cycle methods (onCreate, onResume, etc.) in your Presenter, you might run into problems if you want to use your presenter in a custom android.view.View as it doesn’t have such callbacks. Also, there is a high chance that you will never use most of those methods anyway. At the end of the day, the Presenter cares about two states — View is available and View is not available. In that case attach/detach combination works pretty well. Presenter would look like this:
And this is how you would call those methods from an Activity, a Fragment and an android.view.View:
What usually happens in onViewAttached? Here you get to set the View to the current state. If your Presenter survives configuration changes, then your View can continue from where it left off. This is also a good place to subscribe to Observables exposed by the View, e.g. button clicks, text changes, list item selections, etc., as well as data Observables.
What usually happens in onViewDetached? The most important thing you need to do here is to unsubscribe from Observables you subscribed to in onViewAttached method. If you don’t unsubscribe and your Presenter survives configuration changes, then you will leak your View (Activity). There is also danger of leaking your Presenter if you don’t unsubscribe from your data Observables. This sounds like a lot of boilerplate code needs to go into onViewDetached. Let’s add a method that will help us with that.
Thinking about unsubscribing before you even subscribe is a bit awkward. Kotlin allows for extension methods, let’s add one for Observable to make it more natural.
Another question that might come up is: why pass View to detach method? By that time the view is basically useless, so there is not much you can do with it. The main reason why I still do that is to restrict the API. I want my Presenter to be able to handle only one View at a time. I also want to enforce correct order of methods to call — you cannot call detach before you call attach.
It’s quite easy to test your Presenter, but it comes with a small price. You need to prepare (mock/stub) Observables that your Presenter is going to use. I’ll show you what I mean:
You can see that if you have a complex View, you will have to do a lot of ceremony to get your tests going.
Did I mention that you don’t need a library for any of this? Here is one anyway. Feel free to use it or copy it or do whatever you want with it.
Please let me know what you think in comments section below.
