CODEWITHSUNDEEP
androidmvpmosby
Alexandr
Alexandr

Reputation: 3969

Presenter/View/ViewState relationshipts

For example, I have EditProjectFragment which contains few elements:

Let's see:

  1. Project name will be restored by TextView itself
  2. Who must store project's color?
  3. Who must store spinner's value?

It seems to be ViewState's responsibility. For example, when user picks color, View calls presenter.onProjectColorPicked(color). Then, Presenter will call view.setProjectColor(color). Or View should update ViewState directly, without calling Presenter if it doesn't need?

Another example. User adds photo in EditNoteFragment. User picks photo(presenter.pickPhoto()) -> presenter.addPhoto(photo) called and notify View to add photo to ViewState&show it. Should View update Note object by itself? Should it be done by Presenter? In the first case it means that ViewState will provide methods like getNote()/setNote(note) that will be used by View. Should I duplicate Note-reference via updating it in View.setNote(note) method? The second case means that I probably should store Note object in Presenter and just update View without passing Note in it. But it looks like a wrong way.

In other words: what View must do without Presenter's help(add a photo to Note object?) and what things with it(button clicks etc)?

Upvotes: 3

Views: 149

Answers (1)

sockeqwe
sockeqwe

Reputation: 15929

Viewstate was meant to be used to represent different states from your View. I.e The view is displaying a loading indicator. so we could say that the view is in the "loading state". So whenever the "state" changes usually a presenter was involved because its the responsibility of the presenter to coordinate the views state. The question is: how do you define state? There is no silver bullet.

I don't think that it makes sense to play such a ping pong game like

  1. presenter.onProjectColorPicked(color)
  2. view.setProjectColor(color)

unless, you say that it goes down to the model (business logic) like this:

  1. View calls presenter.onProjectColorPicked(color)
  2. Presenter calls model.setColor(color)
  3. model informs presenter (via observer pattern) that the model has been changed
  4. Presenter calls view.setData(newModelWithChangedColor) containing the new color

In general: the view is just displaying (via presenter) what the current state of the "model" is.

ViewState is just a little helper to deal with screen orientation changes and process death in a slightly more convenient way (compared to traditional onSaveInstanceState(Bundle) implementations).

So ask yourself: What is the state of your "model". Usually, the view's state is the same as the state of the "model".

In the first example, it seems that it is an issue of color picker and spinner to not save the the picked things internally. Therefore, doing that manually in onSaveInstanceState() for the picker / spinner is the default way the android team recommends to go. So, if you just want to use the ViewState feature to not use onSaveInstanceState() because you find it more convenient to use ViewState then this is fine too, although it is not exactly what ViewState was meant for.

Upvotes: 2

Related Questions