¿Qué patrones de arquitectura se usan en Android? [cerrado]

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 mucho junto con la delegación y otros patrones.

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

EDITAR

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

Intenté usar los patrones arquitectónicos model-view-controller (MVC) y model-view-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 Activityclase de Android . ¿Es un controlador o es una vista?

La Activityclase real no extiende la Viewclase de Android , pero sí maneja mostrar una ventana al usuario y también maneja los eventos de esa ventana (onCreate, onPause, etc.).

Esto significa que cuando está utilizando un patrón MVC, su controlador será en realidad un pseudocontrolador de vista. Dado que se trata de mostrar una ventana al usuario, con los componentes de vista adicionales que 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 al aplicarlo 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 considero 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
• Enrutamiento de 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 manejará 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 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 debería ser básicamente su 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 como se mencionó anteriormente.

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

Pruébalo. Personalmente, creo que encaja perfectamente con el desarrollo de Android.

Actualización noviembre 2018

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

Entonces, lancé un video curso completo sobre la arquitectura de aplicaciones de Android. Entonces, 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á buscando patrones arquitectónicos en lugar de patrones de diseño .

Los patrones de diseño tienen como objetivo describir un "truco" general que el programador podría implementar para manejar un conjunto particular de tareas recurrentes de software. Por ejemplo: en OOP, cuando existe la necesidad de que un objeto notifique a 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 único patrón de diseño OOP que NO se use en Android.

Los patrones arquitectónicos , por otro lado, no abordan tareas de software en particular; su objetivo es 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 aclare: si alguna aplicación se utilizará para obtener datos de un servidor remoto y presentarlos al usuario de manera estructurada, MVC podría ser un buen candidato para su consideración. Tenga en cuenta que no dije nada acerca de 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 son lo que está buscando.

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

Pero hoy la situación es diferente: Google lanzó recientemente la biblioteca Data Binding , 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, 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í mismos 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 al hecho de que se inició oficialmente la búsqueda del mejor patrón arquitectónico para Android, creo que estamos a punto de ver salir a la luz varias ideas más. 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 uno o dos años).

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 eso 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 mantenible 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 pautas y herramientas oficiales, yo 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 arquitectura MVC. Es simple, limpio, legible y comprobable, y no requiere ninguna biblioteca adicional.

Este MVC no solo es cosméticamente diferente de los demás, se basa en una 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.

Entonces, si está buscando un buen patrón arquitectónico para aplicaciones de Android que siga los principios de SOLID , puede encontrar una descripción de uno en mi publicación sobre los patrones arquitectónicos MVC y MVP en Android .

Cuando llego a esta publicación, realmente me ayuda a comprender los patrones con ejemplos, así que he hecho la tabla a continuación para ver claramente los patrones de diseño y su ejemplo en Android Framework

Espero que lo encuentren útil.

• Algunos enlaces útiles para referencia:
  

  1. Patrones de diseño comunes para Android con Kotlin

  2. Introducción a los patrones de diseño de Android

  3. Patrones de diseño

Hay varios patrones utilizados en el marco de Android como:

• El receptor de difusión utiliza el patrón Observador
• La invocación del servicio remoto utiliza el patrón Proxy
• Ver y ver grupo utiliza patrón compuesto
• El marco de medios usa el patrón Fachada

Aquí hay un gran artículo sobre Patrones de diseño comunes para Android :

Patrones de creación:

• Generador (por ejemplo, AlertDialog.Builder )
• Inyección de dependencia (p. Ej. Daga 2 )
• único

Patrones estructurales:

• Adaptador (por ejemplo, RecyclerView.Adapter )
• Fachada (por ejemplo, modernización )

Patrones de comportamiento:

• Comando (por ejemplo, EventBus )
• Observador (p . Ej., RxAndroid )
• Controlador de vista de modelo
• Vista de modelo Modelo de vista ( similar al patrón MVC anterior )

Las siguientes clases de Android usan patrones de diseño

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

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

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

4) El receptor de difusión utiliza un patrón de diseño de observador

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

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

En el caso de Notificaciones , el patrón deNotificationCompat.Builder usos utiliza

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 utiliza para mejorar el rendimiento de un ListView mientras se desplaza.

El patrón de diseño ViewHolder le permite acceder a cada vista de elementos 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á más fluido.

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 limpiar el código.

MVVM se origina en 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 mucho código (como addXXListener (), findViewById (), etc.), que no agrega ningún valor comercial. Además, debe ejecutar pruebas unitarias 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 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 código de interfaz de usuario 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 la interfaz de usuario al Modelo de presentación, que es un POJO y se puede probar a través de pruebas JUnit normales . RoboBinding en sí 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. Vea mi discusión en

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

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

Binder utiliza el "Patrón de observador" para las notificaciones de destinatarios de la muerte.