In the MVP structure, which class is responsible for storing list items and how to notify about data changes in this

I am trying to reorganize one of my activity classes to implement mvp (using the mvp mosby library). I have a RecyclerView, and in this view there are some elements to which some changes apply to them during runtime. for example, I perform an I / O operation and change one line.

I think it's best to keep my subjects in the class of presenters; what is the best thing for? keep it in 1) the presenter or 2) activity or 3) save only the element related to viewing in the adapter and all other elements in the presenter.

activity now saves items directly and changes the line item in action, and then notifies the adapter. isn't it better to move this whole line in the adapter and notify the adapter in the adapter class? for example, I want to change the icon of a line. Where and which class is responsible for this? adapter? Events? Now I want to implement it like this in the adapter:

changeItemIcon(int position, int iconRes){ mImages.get(position).setICon(iconRes); notifyItemChanged(position); } 

I call this method by activity and the activity method from the host is called.

it's good? What is the best practice for this?

UPDATE

I also find this question ( Best way to update data using the RecyclerView adapter ) using the adapter method to modify the elements. but what about modifications? Do I need to store links to objects in my activity?

+5
source share
3 answers

for example, I want to change the icon of a line. Where and which class is responsible for this? adapter? activity?

I know this sounds a little strange, but changing an element is always the responsibility of your "business logic", even for "icons."

The workflow should be as follows (unidirectional data stream):

  • A view appears, tells the presenter to load a list of items
  • The facilitator loads the elements from the "business logic" and registers itself as an observer / listener / callback (whatever you call)
  • The presenter receives the result and points to the view to display the list (through RecyclerView and the corresponding adapter).

so far this is what you implemented, I think now it comes to the point that you want to change the element.

  1. The user clicks on an item in your RecyclerView, which then must cause the icon of that item to change. Therefore, View should call: presenter.changeItem()
  2. The host is just the person in the middle in this case and will call up the “business logic level” to indicate that the item should be changed to a new state (the icon has changed).
  3. The "business logic level" will change the state of the models (change the icon of the elements), and then notify its observers / listeners that the model has been changed.
  4. Since Presenter is still observing / listening to the business logic level (see clause 2.), Presenter will be notified (see clause 6.) with a new (updated) list of elements containing the updated element whose icon has been changed.
  5. Similar to step 3. Presenter will display a view to display a new (updated) list of elements (via RecyclerView and the corresponding adapter).

Do you see unidirectional data flow? It is very important. The invariance of FTW.

+5
source

MVP has two different options: passive and control controller. Depending on your taste, you can stick with one or mix them in your application.

If you choose a passive view, you need to hide the "Model from the view" and provide the data in the "Presenter" format, and then set the "View". In this case, you need to save the model link in Presenter. The view should display only data-data (adapter) for the purpose of displaying it.

If you stick with the Supervising Controller, you can enable View to directly bind data to the model and ask the model to follow some simple logic. The host should only care about complex logic, that is, about some operations that should include Services. In this case, you can provide Model (your elements) for View (activity) and allow it to interact with Model in a simple way.

PS: Please also check out our new MVP framework: Robo MVP at http://robo-creative.imtqy.com/mvp .

+3
source

I never used mosby, but I just read their docs (a good read by the way), and here is my understanding:

A recycler view usually consists of a view (android term) and an adapter. Both are linked within a fragment or activity. From an MVP / mosby point of view, this is the entire presentation layer. The presenter should only extract and transmit the displayed data from your service (model layer in mosby, “service level” or “business logic” in other terms), which, in turn, gets it from the DAO or repository (model level).

The docs say that the host processes only the state of the view, not the actual content. Your state "shows the list."

+1
source

All Articles