usando tipos software programar practicos patrones para mvc mega estandares ejemplos diseño aprende apps android design-patterns

tipos - ¿Qué patrones de diseño se utilizan en Android?



patrones en apps (12)

Estoy haciendo una pequeña investigación de plataformas móviles y me gustaría saber qué patrones de diseño se utilizan en Android.

por ejemplo, en iOS Model-view-controller es muy utilizado junto con la delegación y otros patrones.

¿Qué patrones y dónde, en particular, usa Android?

EDITAR

No estoy pidiendo patrones de diseño utilizados en el kernel, dalvik, etc., sino sobre patrones que un desarrollador de aplicaciones encontrará al desarrollar una aplicación.

Android también utiliza el patrón de diseño ViewHolder.

Se utiliza para mejorar el rendimiento de un ListView mientras se desplaza.

El patrón de diseño de ViewHolder le permite acceder a cada vista de elemento de la lista sin la necesidad de buscar, ahorrando valiosos ciclos de procesador. Específicamente, evita las llamadas frecuentes de findViewById () durante el desplazamiento de ListView, y eso lo hará sin problemas.

Aquí hay un gran artículo sobre raywenderlich.com/109843/common-design-patterns-for-android :

Patrones creacionales:

  • Constructor (por ejemplo, AlertDialog.Builder )
  • Inyección de dependencia (por ejemplo, Daga 2 )
  • Semifallo

Patrones estructurales:

  • Adaptador (por ejemplo, RecyclerView.Adapter )
  • Fachada (por ejemplo, Retrofit )

Patrones de comportamiento:

  • Comando (por ejemplo, EventBus )
  • Observador (por ejemplo, RxAndroid )
  • Controlador de vista de modelo
  • Model View ViewModel ( similar al patrón MVC anterior )

Binder usa el "Patrón de observador" para las notificaciones de Destinatarios de la Muerte.

En Android, el patrón del "procesador de colas de trabajo" se usa comúnmente para descargar tareas del hilo principal de una aplicación.

Ejemplo: El diseño de la clase IntentService.

IntentService recibe los intentos, inicia un subproceso de trabajo y detiene el servicio según corresponda. Todas las solicitudes se manejan en un solo subproceso de trabajo.

En el caso de las Notifications , NotificationCompat.Builder utiliza el patrón del generador.

me gusta,

mBuilder = new NotificationCompat.Builder(this) .setSmallIcon(R.drawable.ic_stat_notification) .setContentTitle(getString(R.string.notification)) .setContentText(getString(R.string.ping)) .setDefaults(Notification.DEFAULT_ALL);

Hay varios patrones utilizados en el marco de Android como:

  • El receptor de difusión utiliza el patrón Observer
  • La invocación del servicio Remoter utiliza un patrón de proxy
  • Grupo de vista y vista utiliza patrón compuesto
  • Marco de medios utiliza patrón de fachada

Intenté usar los patrones de diseño model–view–controller (MVC) y model–view–presenter para hacer el desarrollo de Android. Mis conclusiones son modelo-vista-controlador funciona bien, pero hay un par de "problemas". Todo se reduce a cómo percibe la clase de Activity Android. ¿Es un controlador, o es una vista?

La clase de Activity real no amplía la clase de View de Android, pero sí controla la visualización de una ventana para el usuario y también los eventos de esa ventana (onCreate, onPause, etc.).

Esto significa que, cuando está utilizando un patrón MVC, su controlador será en realidad un pseudo view-controller. Ya que está manejando mostrar una ventana al usuario, con los componentes de vista adicionales que le ha agregado con setContentView, y también manejar eventos para al menos los diversos eventos del ciclo de vida de la actividad.

En MVC, se supone que el controlador es el punto de entrada principal. Lo cual es un poco discutible si este es el caso cuando se aplica al desarrollo de Android, ya que la actividad es el punto de entrada natural de la mayoría de las aplicaciones.

Debido a esto, personalmente encuentro que el patrón modelo-vista-presentador es perfecto para el desarrollo de Android. Dado que el papel de la vista en este patrón es:

  • Sirviendo como punto de entrada
  • Componentes de renderizado
  • Enrutar eventos de usuario al presentador

Esto le permite implementar su modelo así:

Vista : contiene los componentes de la interfaz de usuario y controla los eventos para ellos.

Presentador : esto manejará la comunicación entre su modelo y su vista, véalo como una puerta de entrada a su modelo. Es decir, si tiene un modelo de dominio complejo que representa, Dios sabe qué, y su vista solo necesita un subconjunto muy pequeño de este modelo, el trabajo de los presentadores es consultar el modelo y luego actualizar la vista. Por ejemplo, si tiene un modelo que contiene un párrafo de texto, un título y un recuento de palabras. Pero en una vista determinada, solo necesita mostrar el título en la vista. Luego, el presentador leerá los datos necesarios del modelo y actualizará la vista en consecuencia.

Modelo : este debe ser básicamente tu modelo de dominio completo. Esperamos que también ayude a que su modelo de dominio sea más "ajustado", ya que no necesitará métodos especiales para tratar los casos como se mencionó anteriormente.

Al desacoplar el modelo de la vista todos juntos (a través del uso del presentador), también resulta mucho más intuitivo probar su modelo. Puede tener pruebas de unidad para su modelo de dominio y pruebas de unidad para sus presentadores.

Pruébalo. Personalmente me parece un gran ajuste para el desarrollo de Android.

Las siguientes clases de Android utilizan patrones de diseño

1) El titular de la vista utiliza el patrón de diseño Singleton

2) La intención utiliza el patrón de diseño de fábrica.

3) El adaptador utiliza el patrón de diseño del adaptador

4) El receptor de transmisión utiliza el patrón de diseño del observador

5) La vista utiliza un patrón de diseño compuesto

6) Media FrameWork utiliza un patrón de diseño de fachada.

Todos estos patrones, MVC, MVVM , MVP y Presentation Model , pueden aplicarse a aplicaciones de Android, pero sin un marco de terceros, no es fácil obtener una estructura bien organizada y un código limpio.

MVVM se origina en PresentationModel. Cuando aplicamos MVC, MVVM y el Modelo de presentación a una aplicación de Android, lo que realmente queremos es tener un proyecto estructurado claro y, lo que es más importante, más sencillo para las pruebas unitarias.

En este momento, sin un marco de terceros, por lo general tiene mucho código (como addXXListener (), findViewById (), etc.), que no agrega ningún valor de negocio. Además, tiene que ejecutar pruebas de unidad de Android en lugar de las pruebas normales de JUnit, que tardan años en ejecutarse y hacen que las pruebas de unidad sean poco prácticas.

Por estas razones, hace algunos años comenzamos un proyecto de código abierto, RoboBinding : un marco de modelo de presentación de enlace de datos para la plataforma Android. RoboBinding lo ayuda a escribir un código UI que es más fácil de leer, probar y mantener. RoboBinding elimina la necesidad de código innecesario como addXXListener o algo así , y cambia la lógica de UI al Modelo de presentación, que es un POJO y se puede probar a través de las pruebas normales de JUnit . RoboBinding en sí viene con más de 300 pruebas de JUnit para garantizar su calidad.

Actualización noviembre 2018

Después de trabajar y bloguear sobre MVC y MVP en Android durante varios años (vea el cuerpo de la respuesta a continuación), decidí capturar mi conocimiento y comprensión de una forma más completa y fácil de digerir.

Entonces, lancé un curso de video completo sobre arquitectura de aplicaciones Android. Por lo tanto, si está interesado en dominar los patrones arquitectónicos más avanzados en el desarrollo de Android, consulte este curso completo aquí .

Esta respuesta se actualizó para seguir siendo relevante a partir de noviembre de 2016.

Parece que estás buscando patrones arquitectónicos en lugar de patrones de diseño .

Los patrones de diseño apuntan a describir un "truco" general que el programador podría implementar para manejar un conjunto particular de tareas de software recurrentes. Por ejemplo: en POO, cuando se necesita que un objeto notifique a un conjunto de otros objetos acerca de algunos eventos, se puede emplear el patrón de diseño del observador .

Dado que las aplicaciones de Android (y la mayoría de AOSP) están escritas en Java, que está orientada a objetos, creo que le será difícil encontrar un solo patrón de diseño OOP que NO se use en Android.

Los patrones arquitectónicos , por otro lado, no abordan tareas de software particulares, sino que tienen como objetivo proporcionar plantillas para la organización del software en función de los casos de uso del componente de software en cuestión.

Suena un poco complicado, pero espero que un ejemplo se aclare: si alguna aplicación se utilizará para obtener datos de un servidor remoto y presentarlos al usuario de manera estructurada, entonces MVC puede ser un buen candidato para su consideración. Tenga en cuenta que no dije nada sobre las tareas de software y el flujo de programas de la aplicación; simplemente lo describí desde el punto de vista del usuario y surgió un candidato para un patrón arquitectónico.

Como mencionó MVC en su pregunta, supongo que los patrones arquitectónicos es lo que está buscando.

Históricamente, Google no había directrices oficiales sobre las arquitecturas de las aplicaciones, lo que (entre otras razones) llevó a un desastre total en el código fuente de las aplicaciones de Android. De hecho, incluso hoy en día la mayoría de las aplicaciones que veo aún no siguen las mejores prácticas de OOP y no muestran una organización lógica clara del código.

Pero hoy en día, la situación es diferente: Google lanzó recientemente la MVC , que está totalmente integrada con Android Studio e, incluso, lanzó un conjunto de planos de arquitectura para aplicaciones de Android .

Hace dos años era muy difícil encontrar información sobre MVC o MVP en Android. Hoy en día, MVC, MVP y MVVM se han convertido en "palabras de moda" en la comunidad de Android, y estamos rodeados de innumerables expertos que constantemente intentan convencernos de que MVx es mejor que MVy. En mi opinión, discutir si MVx es mejor que MVy no tiene ningún sentido porque los términos en sí mismos son muy ambiguos, solo mire las respuestas a esta pregunta y se dará cuenta de que diferentes personas pueden asociar estas abreviaturas con construcciones completamente diferentes.

Debido al hecho de que se ha iniciado oficialmente la búsqueda de un mejor patrón arquitectónico para Android, creo que estamos a punto de ver varias ideas más que salen a la luz. En este punto, es realmente imposible predecir qué patrón (o patrones) se convertirán en estándares de la industria en el futuro; tendremos que esperar y ver (supongo que es cuestión de un año o dos).

Sin embargo, hay una predicción que puedo hacer con un alto grado de confianza: el uso de la biblioteca de enlace de datos no se convertirá en un estándar de la industria. Estoy seguro de decir que debido a que la biblioteca Data Binding (en su implementación actual) proporciona ganancias de productividad a corto plazo y algún tipo de directriz arquitectónica, pero hará que el código no sea mantenible a largo plazo. Una vez que surjan los efectos a largo plazo de esta biblioteca, se abandonará.

Ahora, aunque tenemos algún tipo de guías y herramientas oficiales hoy, personalmente, no creo que estas guías y herramientas sean las mejores opciones disponibles (y definitivamente no son las únicas). En mis aplicaciones utilizo mi propia implementación de una arquitectura MVC. Es simple, limpio, legible y comprobable, y no requiere bibliotecas adicionales.

Este MVC no solo es cosméticamente diferente de los demás, sino que se basa en la teoría de que las Actividades en Android no son Elementos de UI , lo que tiene enormes implicaciones en la organización del código.

Por lo tanto, si está buscando un buen patrón arquitectónico para las aplicaciones de Android que siguen los principios de SOLID , puede encontrar una descripción de uno en mi publicación acerca de los SOLID .