问题
I'm currently developing an android app using MVP Pattern.
When I try to develop an Activity, I should use a ListView. So I'm using Adapter for ListView. But I heard Adapter is similar to Presenter on MVP Pattern.
I think if Apdater is smiliar to Presenter, then I should make Presenter for updating ListView instead of Adapter.
When this situation, how to develop ListView? Just use Adapter and keep using MVP Pattern?
Thanks for your reading.
回答1:
Yes, the Adapter should be the P component in an MVP pattern. In fact ListViews are pretty much written as MVP- the getView() function needs to set all the values of the view each time its called, that's almost the definition of what a presenter must do. Although it's also easy to use it in an MVC type way- simply have getView call functions on the View that pass it the model and do that work in the Views. So really either way will work, just pick your preference.
If you do use an MVP model with complex list rows, I like to make the rows a custom compound View and put more descriptive function names on it- so rather than going listRow.findViewById(R.id.textView).setText(filename) I'll go listRow.setFilename(filename) and let the view know what to do with that. That kind of blurs the bounds of MVP and MVC a bit, but I find it a good balance of readability of your adapter and avoiding some of the awkwardness pure MVC sometimes brings.
回答2:
Adapter is part of the view. In fact, all Android dependencies should be a part of the view. To keep the adapter isolated from your model and your presenter use to be a hard task. I have released a library called PaperKnife for this purpose.
You can use PaperKnife to decouple the adapter from the model and the presenter layer. Follow the next steps:
Abstract the model layer using
CellElement
interface. Your view layer does't need to know your model.Create a class to provide the information for your row view. You can use your presenter. Implements the class
CellDataProvider
and create methods to provide all the information. Annotate your provider methods with@DataSource("DataId")
to perform the mapping. Your data methods receive the instance of your model class. For example:public class SamplePresenterImpl implements SamplePresenter, CellDataProvider { @DataSource("Title") public String getTitle(Item item) { return item.getTitle(); } // etc. }
Create a
ViewHolder
in your adapter and implements theCellViewHolder
interface. Create methods to manage the views and useDataTarget("DataId")
static class ViewHolder extends CellViewHolder { @DataTarget("Title") public String setTitle(String title) { mTextViewTitle.setText(title); } }
Execute the mapping in your adapter
getView
method:@Override public View getView(int position, View convertView, ViewGroup parent) { // etc. PaperKnife.map(mList.get(position)) .dataProvider(mCellDataProvider) .into(viewHolder); return convertView; }
In this way your view layer just know the CellElement
interface, and your presenter is responsible to provide data to your adapter.
回答3:
If there is only a listview in that activity then there is no need to write a separate presenter because Adapter is actually working as Presenter for ListView. But if you have other UI components than ListView that need to be updated then you must need to write a separate Presenter for those UI components.
回答4:
Android applications are fundamentally built around Model-View-Controller (MVC) - MVP sounds like the same thing, although I've not heard the term before. Activities fill the role of Controller, XML Views are just that (although you can build them programmatically in the Activity - it's just easier and simpler to do it in XML), and the Model you write yourself. So yes, that model is quite practical.
A possible reason you may not have heard much about this design model is that the Android framework forces you to separate the view out. Because the application on mobile devices tend to be small, people don't tend to use full-on MVC; they tend toward view and action layers where the action layer does much of the model's (small) job.
If you are writing a cross platform app, you may want to look at a four-layer approach: View, Action, Business Logic, and Model. The View and Action layers would be platform specific, while the Business Logic and Model would not change. Basically, you split out the presenter and user interaction out to the Action layer, which calls the Business Logic layer to perform the action the user wants.
来源:https://stackoverflow.com/questions/24858050/how-to-control-listview-with-mvp-pattern-for-android