-1

I'm trying to implement the MVP pattern in my app.

However There are some tasks I'm not sure how to do the right way.
Most of the examples only cover base and simple tasks where every interactor does only one task (e.g. fetch user list) - But, how should we implement it if the tasks are more complex

How should we treat those tasks:

  1. A complex data task, for example which involve 3 api calls - fetch users + fetch user likes + fetch user followers. Should it be done in a single interactor, or divided into 3 interactors?

  2. A task where a data needs to be stored somewhere, before moving from the presenter to its interactor.
    For example, A complex registration process - The user enters user name and address and press continue. After that there is a series of X popups where the user fills more data. Eventually - the user presses registration, and the presenter triggers its interactor.
    Now, where this registration data should be saved through the whole process until making the registration call? In the presenter? In the presenter's dedicated class? In the.. Interactor??

  3. Last thought - In all the examples I saw, the interactor has 1 to 1 relationship with its presenter.
    If a login presenter uses a login interactor to make a...login ofc. What happens if I need to make another login call in some other screen (I know its not common, but just to understand the main idea) - Then we will have another interactor doing the same thing as the previous. Should interactor has 1 to many relationship then?

I'll be glad to hear your opinions

Thanks!

dor506
  • 5,246
  • 9
  • 44
  • 79

2 Answers2

1

Answers to your questions:

  1. I recommend having a separate API layer to handle your background tasks. I recommend exposing each API call through RxJava, and ensuring that only the Presenter has access to the API. RxJava would do the heavy lifting of allowing you to combine the requests together in your application layer / presenters.
  2. Square recently did a talk on this and there solution. You can find a link to it here. Bottom line, it's not an easy problem to solve. If you are looking for a simple solution, my team and I created a concept called preferences. Each Preference represents a single piece of data that's stored in memory or persisted to disk using shared preferences. Here is an example of a library we used to do this. This library uses RxJava1, and we upgraded it privately to RxJava2, but you can get the point. Each piece of data is a dependency that we use Dependency Injection to pass between presenters / screens to get it where we need it.
  3. Can't answer this one. My team doesn't use Interactors. We use a separated API layer as I described in #1, and RxJava allows all of those calls to be extremely flexible and re-usable. You will drive yourself crazy if you are dogmatic about everything you read in blogs. A lot of the things I've read in blogs just aren't practical in principal. I recommend using common sense, and finding what works for your team.

Here is a short sell on MVI (Model View Intent). I highly recommend it:

My team recently tried adopting MVP about a year ago. It didn't take long for us to realize some shortcomings, and have issues similar to you. After some searching we moved to Model-View-Intent (MVI). It's very similar to MVP, but with a few key differences that make the code far more manageable and easier to standardize the code between developers, making it easier jump into other peoples code.

A few key differences: The View doesn't talk to the Presenter, instead the View emits events that the Presenter subscribes to, called Intents. The Presenter also talks to the View via strong View Model. If you draw it out, it ends up functioning very similarly to MVVM. You end up with a flow that looks like this:

  1. The Presenter subscribes to the View events / intents.
  2. The View emits events.
  3. The Presenter receives the events, reacts, and updates the model.
  4. The Model being updated triggers an update to the View
  5. Round and round it goes. (It ends up being a very circular loop of events if you draw it out)

Hannes Dorfmann has a few blog posts on MVI that I recommend. He provides some pretty complex examples. My team uses Kotlin, and that helps with this a LOT. We don't follow everything Hannes does, but we learned a lot from his blog posts / examples, and distilled into something that works REALLY well for our team.

  1. http://hannesdorfmann.com/android/model-view-intent
  2. http://hannesdorfmann.com/android/mosby3-mvi-1
  3. http://hannesdorfmann.com/android/mosby3-mvi-2
  4. http://hannesdorfmann.com/android/mosby3-mvi-3
  5. http://hannesdorfmann.com/android/mosby3-mvi-4
  6. http://hannesdorfmann.com/android/mosby3-mvi-5
  7. http://hannesdorfmann.com/android/mosby3-mvi-6
spierce7
  • 14,797
  • 13
  • 65
  • 106
0

@dor506 I had this confusions before I started working with MVP architecture

I had to follow lots of article, blogs and sample projects .above them this repo was my blueprint of learning MVP

follow this repo hope you will be pro on developing android app with MVP architecture

Wubbalubbadubdub
  • 2,415
  • 1
  • 24
  • 36