studio - mvp android ejemplo

Cómo controlar ListView con MVP Pattern para Android

Question

Actualmente estoy desarrollando una aplicación para Android usando MVP Pattern.

Cuando intento desarrollar una actividad, debo usar un ListView. Así que estoy usando el adaptador para ListView. Pero escuché que Adapter es similar a Presenter en MVP Pattern.

Creo que si Apdater es similar a Presenter, debería hacer Presenter para actualizar ListView en lugar de Adapter.

Cuando esta situación, ¿cómo desarrollar ListView? ¿Solo usa el adaptador y sigue usando MVP Pattern?

Gracias por su lectura

Answer 1

El adaptador es parte de la vista. De hecho, todas las dependencias de Android deben ser parte de la vista. Mantener el adaptador aislado de su modelo y su presentador suele ser una tarea difícil. He lanzado una biblioteca llamada PaperKnife para este propósito.

Puede usar PaperKnife para desacoplar el adaptador del modelo y la capa presentadora. Sigue los siguientes pasos:

1. CellElement capa del modelo utilizando la interfaz CellElement . Su capa de vista no necesita conocer su modelo.

2. Cree una clase para proporcionar la información para su vista de fila. Puede utilizar su presentador. Implementa la clase CellDataProvider y crea métodos para proporcionar toda la información. @DataSource("DataId") métodos de su proveedor con @DataSource("DataId") para realizar la asignación. Sus métodos de datos reciben la instancia de su clase de modelo. Por ejemplo:

   public class SamplePresenterImpl implements SamplePresenter, CellDataProvider {
   @DataSource("Title")
   public String getTitle(Item item) {
   return item.getTitle();
   }
   // etc.
   }

3. Cree un ViewHolder en su adaptador e implementa la interfaz CellViewHolder . Cree métodos para administrar las vistas y use DataTarget("DataId")

   static class ViewHolder extends CellViewHolder {
   @DataTarget("Title")
   public String setTitle(String title) {
   mTextViewTitle.setText(title);
   }
   }

4. Ejecute la asignación en su adaptador getView método getView :

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

De esta manera, su capa de vista solo conoce la interfaz de CellElement , y su presentador es responsable de proporcionar datos a su adaptador.

Answer 2

Las aplicaciones de Android se basan fundamentalmente en el Modelo-Vista-Controlador (MVC). MVP suena igual, aunque no he escuchado el término antes. Las actividades desempeñan el rol de Controlador, las vistas XML son solo eso (aunque puede compilarlas programáticamente en la Actividad, es más fácil y más simple hacerlo en XML) y el Modelo que usted mismo escribe. Así que sí, ese modelo es bastante práctico.

Una posible razón por la que puede no haber escuchado mucho sobre este modelo de diseño es que el marco de Android te obliga a separar la vista. Debido a que la aplicación en dispositivos móviles tiende a ser pequeña, las personas no tienden a usar MVC completo; tienden a capas de vista y acción donde la capa de acción realiza gran parte del trabajo (pequeño) del modelo.

Si está escribiendo una aplicación multiplataforma, es posible que desee ver un enfoque de cuatro capas: Vista, Acción, Lógica de negocios y Modelo. Las capas de vista y acción serían específicas de la plataforma, mientras que la lógica de negocios y el modelo no cambiarían. Básicamente, se divide la interacción entre el presentador y el usuario en la capa de Acción, que llama a la capa de lógica de negocios para realizar la acción que el usuario desea.

Answer 3

Sí, el adaptador debe ser el componente P en un patrón de MVP. De hecho, los ListViews se escriben prácticamente como MVP; la función getView () necesita establecer todos los valores de la vista cada vez que se llama, eso es casi la definición de lo que debe hacer un presentador. Aunque también es fácil de usar en una forma de tipo MVC, simplemente tiene funciones de llamada getView en la Vista que le pasan el modelo y hacen ese trabajo en las Vistas. Así que realmente de cualquier manera funcionará, simplemente elige tu preferencia.

Si utiliza un modelo MVP con filas de listas complejas, me gustaría hacer que las filas sean una Vista compuesta personalizada y poner más nombres de funciones descriptivas en ella, así que en lugar de ir a listRow.findViewById (R.id.textView) .setText (nombre de archivo) Iré a listRow.setFilename (nombre de archivo) y dejaré que la vista sepa qué hacer con eso. Eso confunde un poco los límites de MVP y MVC, pero me parece un buen equilibrio entre la capacidad de lectura de su adaptador y evitar algunas de las molestias que a veces trae el MVC puro.

Answer 4

Si solo hay una vista de lista en esa actividad, entonces no hay necesidad de escribir un presentador separado porque el Adaptador en realidad está funcionando como Presentador para ListView. Pero si tiene otros componentes de la interfaz de usuario que no sean ListView que deben actualizarse, debe escribir un Presenter separado para esos componentes de la interfaz de usuario.