Antonio, thanks for the great post.
Soheil Malekzadeh

The problem of persisting state when the Activity gets destroyed in inherit to the MVP pattern, not a particular issue of this solution.

I would point here a difference between persist some state regarding the application or a particular screen.

  • Application state: You should have a proper persistence layer in your Model, either on the device (DB, shareprefs, etc) or via your backend. In this case, if the presenter gets recreated it wont be any issue, since the data is “saved”.
  • Screen state: Here we can include things like scroll position or text in fields in a long form. You should really consider whether it makes sense to bother about this, but in case it does, you could make use of onSaveInstanceState, which is what the system provides. You could do that via passing the call to the Presenter and let it handle (the problem of this approach is to have a Presenter with Android dependencies).

But as said, for my the Model should keep the state, letting the Presenter react to such state.

I hope it helps

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.