如何控制与Android MVP模式的ListView

我目前正在开发一个使用MVP模式的Android应用程序。

当我尝试开发一个Activity时,我应该使用一个ListView。 所以我使用适配器的ListView。 但是我听说Adapter与MVP Pattern的Presenter类似。

我想如果Apdater对Presenter很熟悉,那么我应该让Presenter更新ListView而不是Adapter。

当这种情况下,如何开发ListView? 只要使用适配器,并继续使用MVP模式?

感谢您的阅读。

Solutions Collecting From Web of "如何控制与Android MVP模式的ListView"

是的,适配器应该是MVP模式中的P组件。 实际上,ListViews几乎被写成MVP,getView()函数每次调用时都需要设置视图的所有值,这几乎就是演示者必须做的定义。 尽pipe以MVCtypes的方式使用它也很容易 – 只需在View上传递getView调用函数,并将其传递给视图即可。 所以,无论哪种方式将工作,只要select你的偏好。

如果你真的使用复杂列表行的MVP模型,我喜欢使行为一个自定义的复合视图,并在其上放置更多的描述性函数名称,而不是去listRow.findViewById(R.id.textView).setText(filename)我会去listRow.setFilename(文件名),让视图知道该怎么做。 这种模糊了MVP和MVC的边界,但是我发现它适配器的可读性很好的平衡,避免了一些纯MVC有时带来的尴尬。

适配器是视图的一部分。 事实上,所有的Android依赖应该是视图的一部分。 为了使适配器与您的模型隔离,您的演示者使用起来是一项艰巨的任务。 为此,我已经发布了一个名为PaperKnife的库。

您可以使用PaperKnife将适配器与模型和演示者层分离。 按照下面的步骤:

  1. 使用CellElement接口来抽象模型层。 你的视图层不需要知道你的模型。

  2. 创build一个类来为你的行视图提供信息。 您可以使用您的演示者。 实现CellDataProvider类并创build提供所有信息的方法。 使用@DataSource("DataId")注释您的提供者方法以执行映射。 你的数据方法接收你的模型类的实例。 例如:

     public class SamplePresenterImpl implements SamplePresenter, CellDataProvider { @DataSource("Title") public String getTitle(Item item) { return item.getTitle(); } // etc. } 
  3. 在您的适配器中创build一个ViewHolder并实现CellViewHolder接口。 创build方法来pipe理视图并使用DataTarget("DataId")

     static class ViewHolder extends CellViewHolder { @DataTarget("Title") public String setTitle(String title) { mTextViewTitle.setText(title); } } 
  4. 在适配器getView方法中执行映射:

     @Override public View getView(int position, View convertView, ViewGroup parent) { // etc. PaperKnife.map(mList.get(position)) .dataProvider(mCellDataProvider) .into(viewHolder); return convertView; } 

通过这种方式,您的视图层只需知道CellElement接口,并且演示者负责将数据提供给适配器。

如果在该活动中只有一个列表视图,则不需要编写单独的演示者,因为Adapter实际上是作为ListView的Presenter工作的。 但是,如果您有其他UI组件比ListView需要更新,那么您必须为这些UI组件编写一个单独的Presenter。

Android应用程序基本上是围绕模型 – 视图 – 控制器(MVC)build立的 – MVP听起来像是同样的事情,尽pipe我以前没有听说过这个术语。 活动充当了控制器的angular色,XML视图就是这样的(尽pipe你可以在活动中以编程的方式构build它们 – 在XML中执行它更容易和简单)以及你自己编写的模型。 所以是的,这个模型是非常实用的。

您可能没有听说过这个devise模型的一个可能的原因是Android框架迫使您将视图分开。 因为移动设备上的应用程序往往很小,所以人们并不倾向于使用全functionMVC; 他们倾向于视图和动作层,其中动作层完成模型(小)工作的很多部分。

如果您正在编写一个跨平台的应用程序,您可能需要查看四层方法:查看,操作,业务逻辑和模型。 视图和动作层将是平台特定的,而业务逻辑和模型不会改变。 基本上,您将主讲者和用户交互分离到“操作”层,该层称为业务逻辑层,以执行用户所需的操作。