¿Qué patrones de diseño se usan en Android?

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

por ejemplo, en iOS Model-view-controller se usa ampliamente junto con delegación y otros patrones.

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

EDITAR

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

Intenté usar los patrones de diseño modelo-vista-controlador (MVC) y modelo-vista-presentador para hacer el desarrollo de Android. Mis hallazgos son modelo-vista-controlador funciona bien, pero hay un par de “problemas”. Todo se reduce a cómo percibes la clase de Activity Android. ¿Es un controlador o es una vista?

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

Esto significa que cuando está usando un patrón MVC, su controlador será realmente un controlador de pseudo-vista. Dado que se encarga de mostrar una ventana al usuario, con los componentes de vista adicionales que se le han agregado con setContentView, y también el manejo de eventos para al menos los diversos eventos del ciclo de vida de la actividad.

En MVC, se supone que el controlador es el principal punto de entrada. 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 rol de la vista en este patrón es:

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

Esto le permite implementar su modelo así:

Ver : contiene los componentes de la interfaz de usuario y maneja los eventos para ellos.

Presentador : esto controlará la comunicación entre su modelo y su vista, mírelo 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 conteo 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 debería ser básicamente tu modelo de dominio completo. Con suerte, también ayudará a que su modelo de dominio sea más “ajustado”, ya que no necesitará métodos especiales para tratar los casos mencionados anteriormente.

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

Pruébalo. Personalmente creo que es una gran opción para el desarrollo de Android.

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


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

Los patrones de diseño apuntan a describir un “truco” general que el progtwigdor podría implementar para manejar un conjunto particular de tareas de software recurrentes. Por ejemplo: en OOP, cuando existe la necesidad de que un objeto notifique un conjunto de otros objetos sobre 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á orientado a objetos, creo que tendrá dificultades para buscar un patrón de diseño de OOP único que NO se use en Android.

Los patrones arquitectónicos , por otro lado, no abordan tareas de software particulares: apuntan a proporcionar plantillas para la organización de 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 aclare: si alguna aplicación se utilizará para obtener datos de un servidor remoto y presentarlo al usuario de una manera estructurada, entonces MVC podría ser un buen candidato para su consideración. Tenga en cuenta que no dije nada sobre las tareas de software y el flujo de progtwigs 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 mencionas MVC en tu pregunta, supongo que los patrones arquitectónicos son lo que estás buscando.

Ingrese la descripción de la imagen aquí


Históricamente, Google no tenía pautas oficiales sobre las architectures de las aplicaciones, lo que (entre otras razones) provocaba un desorden 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 todavía no siguen las mejores prácticas de OOP y no muestran una clara organización lógica del código.

Pero hoy la situación es diferente: Google lanzó recientemente la biblioteca Data Binding , que está completamente integrada con Android Studio, e incluso implementó un conjunto de planos de architecture para aplicaciones de Android .

Hace dos años era muy difícil encontrar información sobre MVC o MVP en Android. Hoy, 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 es totalmente inútil porque los términos en sí son muy ambiguos, solo mira las respuestas a esta pregunta , y te darás cuenta de que diferentes personas pueden asociar estas abreviaturas con construcciones completamente diferentes.

Debido a que oficialmente se ha iniciado la búsqueda del mejor patrón arquitectónico para Android, creo que estamos a punto de ver que salgan a la luz varias ideas más. En este punto, es realmente imposible predecir qué patrones (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. Confío en decirlo porque la biblioteca de enlace de datos (en su implementación actual) proporciona ganancias de productividad a corto plazo y algún tipo de pauta arquitectónica, pero hará que el código no sea sostenible a largo plazo. Una vez que surjan los efectos a largo plazo de esta biblioteca, se abandonará.


Ahora, aunque hoy tenemos algún tipo de directrices y herramientas oficiales, personalmente no creo que estas pautas y herramientas sean las mejores opciones disponibles (y definitivamente no son las únicas). En mis aplicaciones uso mi propia implementación de una architecture 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 interfaz de usuario , 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 sigue los principios SOLIDOS , puede encontrar una descripción de uno en mi publicación sobre los patrones arquitectónicos MVC y MVP en Android .

Hay varios patrones utilizados en el marco de Android como:

  • El receptor de difusión usa el patrón Observer
  • La invocación del servicio Remoter usa el patrón Proxy
  • Ver y ver grupo utiliza patrón compuesto
  • El marco de medios usa el patrón de fachada

enter image description here

Cuando llego a esta publicación, realmente me ayuda a comprender los patrones con el ejemplo, así que hago una tabla debajo para ver claramente los patrones de diseño y su ejemplo en Android Framework

Espero que lo encuentres útil.

  • Algunos enlaces útiles para referencia:

https://www.raywenderlich.com/109843/common-design-patterns-for-android

code.tutsplus.com/articles/introduction-to-android-design-patterns–cms-20808

https://en.wikipedia.org/wiki/Design_Patterns

Aquí hay un excelente artículo sobre los patrones comunes de diseño para Android :

Patrones de creación:

  • 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 )

Las siguientes clases de Android utilizan patrones de diseño

1) View Holder usa Singleton Design Pattern

2) Intención utiliza el patrón de diseño de fábrica

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

4) Receptor de difusión utiliza el patrón de diseño del observador

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

6) Media FrameWork utiliza el patrón de diseño de fachadas

En el caso de Notificaciones , NotificationCompat.Builder utiliza el patrón de comstackción

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); 

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

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

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

Todos estos patrones, MVC, MVVM , MVP y Presentation Model , se pueden aplicar a las 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 de PresentationModel. Cuando aplicamos MVC, MVVM y Presentation Model 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 fácil para las pruebas unitarias.

Por el momento, sin un marco de terceros, generalmente tiene muchos códigos (como addXXListener (), findViewById (), etc.), que no agrega ningún valor comercial. Además, debe ejecutar pruebas de la unidad de Android en lugar de las pruebas JUnit normales, que tardan años en ejecutarse y hacen que las pruebas unitarias sean poco prácticas.

Por estos motivos, hace algunos años comenzamos un proyecto de código abierto, RoboBinding : un marco de modelo de presentación vinculante para la plataforma Android. RoboBinding te ayuda a escribir código de UI que es más fácil de leer, probar y mantener. RoboBinding elimina la necesidad de un código innecesario, como addXXListener , y cambia la lógica de la interfaz de usuario al modelo de presentación, que es un POJO y puede probarse mediante pruebas JUnit normales . RoboBinding viene con más de 300 pruebas JUnit para garantizar su calidad.

Me gustaría agregar un patrón de diseño que se haya aplicado en Android Framework. Este es el patrón Half Sync Half Async utilizado en la implementación de Asynctask. Ver mi discusión en

https://docs.google.com/document/d/1_zihWXAwgTAdJc013-bOLUHPMrjeUBZnDuPkzMxEEj0/edit?usp=sharing

En Android, el patrón “procesador de cola 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 Intents, inicia un hilo de trabajo y detiene el servicio según corresponda. Todas las solicitudes se manejan en un solo hilo de trabajo.

Binder utiliza el “Patrón observador” para las notificaciones del destinatario de la muerte.