MVP for Android Part 2 — Featuring Moxy

Welcome back for the second article in our Android development using MVP pattern series. Last time we spoke about a few simple but very important things. We covered:

• What MVP is
• Why you should use it
• What benefits it offers and what outcomes you can look forward to

Speaking from my personal perspective, and I imagine a lot of other developers would agree, taking the first steps towards learning a new programming language or technology are the hardest to take. For anyone choosing to branch out and upskill, it can be intimidating and frequently the hesitance to take the plunge is related to a fear of failure. And let’s be honest sometimes it’s also just down to pure laziness ;-).

But if you consider that first and foremost, the search for understanding is a good thing. Taking time to understand both the positive and negative elements of something new, taking the deep dive and searching for reviews from other developers and friends in the tech space will only make you a better and more informed professional in the long run. I also like to spend time reading comments, discussion threads, blog posts and watching video conferences to get an external perspective on the topic I am researching. Even after the research, sometimes it’s still difficult to understand the real benefits and capabilities of a specific technology because there is no specific qualitative data out there. And this means sometimes it’s possible to lose out on some very powerful new technology because we’re not able to find any evidence of its great working capacity. I think this is more than unfortunate, a new technology that could change the way of working for so many is lost and forgotten because it’s not given support and credibility amongst the general tech community.

And before you think I’m being critical of the extended community and I need to add that in the past I have been no exception. A couple years ago when I first came across patterns it would have been nice to have someone who spoke to me like I am trying to speak to you because I really wouldn’t give it the time of day. When I looked through the description of patterns, all I thought was that it sounded incredibly complicated, was suited only to huge projects and that I most certainly did not need it. Today I can say categorically: I was wrong! I’m happy to say that I am glad I saw sense now as opposed to in a couple years. So in this installment of the MVP in Android development series I’d like to tell you a little more of my story, where I found it and how I became familiar with its functionality.

As developers, we love all kinds of different libraries and we love writing code a lot less. So of course my first thought when deciding to use MVP was, where could I find libraries that could help me. . I was pretty sure I would find something and I was right, I found a library called Moxy. Moxy is an Android MVP helper library.

In this article I’ll be introducing you to Moxy library! I’ll go into detail about how it works and how it helps with MVP.

Moxy is multi-purposed:

• It disconnects all asynchronous operations from the View’s life cycle
• It stops the Presenter from being recreated during the re-creation of the View
• It ensures the re-created Views join the existing Presenter and does not create a new one
• It enables the View to show the current state of the Presenter
• Helps avoid boilerplate code

Moxy has several weighty advantages over other solutions:

• The Presenter is not recreated when you recreate an Activity
• It allows for full automatic View recreation
• The ability to change several Views from one Presenter

Moxy is very different from similar libraries. With the concept of MVP, it’s slightly modernized. Between View and Presenter a ViewState is wormed and it’s really is necessary. Moxy is responsible for ensuring that each View always looks exactly like the Presenter needs it to. ViewState stores a list of commands that have been transferred from Presenter to View. And when the “new” View joins Presenter, ViewState automatically applies it to all the commands Presenter gave it earlier. As such, no matter what happens with View through the fault of Android, View will remain in the correct state. To do this, you only need to get used to changing View exclusively with commands from Presenter. Note that this extends not only to Moxy but is also one of the basic rules of MVP.

Let’s say we are tasked with making an authorisation screen. How do we solve this problem with Moxy? First , we’ll need to write an interface for our View, in this interface we need to describe the capabilities that our view will implement. Let’s stop for a moment and think about what we need…

We’d probably need to show a progress view to the user while the network requests are in progress. This means we want View to have the ability of showing the progress of an action. Post the network call, the second thing that needs to be done is to hide the progress view. Then third, If something went wrong during the network request we would need to show the user an appropriate error message. And finally if everything is ok with the network call, we need to show the main screen of our application after signing in.

Let’s write some code 🙂

That wasn’t so hard was it? Now let’s write our Presenter code. Nothing special here, we just need the Presenter class extends MvpPresenter<View extends MvpView> class provided by Moxy and add our code for signing in.

And finally we need to write our code for View. In our example it will be a fragment, but it doesn’t matter. We need our Fragment extends MvpFragment or MvpAppCompatFragment and to implement the interface we wrote in our first step.

And that’s it. This is all the magic needed to make our app work with MVP. As we can see when our fragment starts, Moxy will inject presenter with the @InjectPresenter annotation. After that we can use our presenter for signing in. As usual this is a very simple example, but believe me, it really doesn’t become more complicated if you add more logic to your Presenter or View.

As a result, we have a library that solves all the problems in the life cycle. You’re able to always show the user the state that is relevant to him and you needn’t do anything superfluous at any point either. Just describe all the commands to View individually. And try avoid changing the View from the View itself. If you showed the dialogue with a command from Presenter, then when you close the dialog, there must be a command from Presenter. Otherwise, ViewState will show you the dialog after changing the configuration again.

Since I started working with Moxy I noticed there is some great functionality to play around with, so in the next installment of this series we’ll continue to get acquainted with this library, dig deeper into its functionalities. we’ll look at strategies for Moxy as well as how it is arranged and how it all works. And much more! See you soon for part 3.

If you missed part 1 you can find it here.

Sergey Trufanov

Previous story

Meet Nika, Guarantor of Quality and Ardent Foodie

Next story

Meet Sergey, an Android developer with vision