Android Mvp, presenter

2
votes

I have read, and try to implement mvp pattern on Android for a while.. However, I never find an example that show activity's presenter, and fragment's presenter at the same time?

As both Activity and Fragment consider as view. And view is control by presenter.

Sometime activity is do nothing just for host fragment, but sometime it does many things such as contain many fragments and receive all input info from them and finally call restful service for save all data.

QUESTION

Since most of the time activity is just for host the fragment, does it really need to have presenter?

If not, when activity need to call rest api, how should they do. (according to map pettern)

If yes, don't you feel it's too overhead for create extra classes. Because most of the time, activity is for hosting fragment. Also, I really want to know how you guy name the class...

For example, currently I have AbcActivity.class, AbcFragment.class, AbcPresenter.class(For fragment), AbcContract.class (Contain view, presenter interface)... what next ?? AbcActivityPresenter ??

Sorry, for long typing, i'm ask from stack exchange app.

1
androidandroid-mvp
Yes, activity needs presenter as it has to pass user interaction(event) to presenter who is responsible to consume event and perform operation (Business Logic written in presenter). Creating extra class is not an overhead as if you write your code using standard design patterns it needs separate class to write code to make robust system as well increase code readability and reusability. For more see this blog- kjthumar.blogspot.de/2016/04/… - Keyur Thumar

1 Answers

0
votes

I have create a blog post about MVP http://www.nonvoid.com/model-view-presenter/

Yes,

  • The activity needs the presenter.
  • The fragment does not have a presenter.
  • The presenter tells the activity what to display but doesn't care about the implementation details.
  • There could be one, many or no fragments in an activity. The presenter doesn't care.

You'll see from my blog post that the "over head" is negligible compared to the added maintainability. The REST API calls should be encapsulated in the presenter.