Android: ¿Qué es mejor: múltiples actividades o cambiar de vista manualmente?

He desarrollado algunas aplicaciones para Android, y esta pregunta permanece siempre:

¿Cómo debo estructurar mi interfaz de usuario? ¿Debo iniciar actividad tras actividad y dejar el teléfono para hacer el botón "Atrás", o debo elegir una forma más optimizada, pero más compleja de implementar, con cambiar manualmente de Vista y luego hacer manualmente la funcionalidad del botón "Atrás"?

¿Cuál crees (o sabes) que es la mejor práctica?

Diría que múltiples actividades casi siempre tienen más sentido. Simplemente no creo que Android esté diseñado para cambiar constantemente sus propias vistas, te pierdes tanto. Tienes que implementar Back tú mismo, no obtienes ninguna transición entre actividades, tienes que implementar mucha lógica interna para reanudar una aplicación en el estado correcto. Si no divide su aplicación en Actividades, más adelante será mucho más difícil cambiar el flujo de su aplicación. También da como resultado una megaactividad que puede ser mucho más difícil de manejar que muchos fragmentos de código más pequeños.

Me cuesta imaginar que la velocidad es realmente un problema; si es así, entonces hay algún problema con la forma en que está inicializando cada actividad. Por ejemplo, solía intentar pasar objetos serializables entre actividades, y eso resultó ser increíblemente lento; cuando cambié a un método más rápido para pasar objetos, la velocidad de lanzamiento de Actividades aumentó enormemente.

Además, creo que es revelador que las pautas de Android para el diseño de actividades y tareas no mencionen en absoluto el cambio de vistas; se centra en un diseño de actividad como vista.

Me gustaría señalar algunos casos en los que una sola actividad podría tener un mejor diseño para una aplicación de Android que tiene más de una vista de pantalla completa:

• Si las pantallas de la aplicación están estrechamente acopladas y comparten un Objeto común en el que todas operan. En este caso, pasar el Objeto puede requerir un Paquete y puede ser propenso a errores, ya que habrá copias del mismo. Un buen ejemplo podría ser un mago . Sí, podría usar estática para acceder al objeto común, pero la estática puede ser peligrosa en Android (¡piense en cambios de configuración!)

• Si quieres animaciones realmente geniales entre pantallas. Tal vez quieras que un pájaro despegue en una pantalla y aterrice en otra. ¡Intente hacerlo cuando cada pantalla sea una actividad!

Por otro lado, si una de sus pantallas está diseñada para ser mostrada por cualquier número de otras aplicaciones, esa pantalla debería ser su propia Actividad.

ACTUALIZACIÓN Marzo de 2014:

En este punto, la pregunta debería incluir ahora la elección de Fragmentos. Creo que las Vistas son probablemente la opción menos probable de las 3: Actividad, Fragmento, Vista. Si desea implementar pantallas que hagan uso del botón Atrás, entonces debería ser Activties o Fragments porque ambos manejan el botón Atrás de forma nativa. Será necesario agregar fragmentos a la pila de actividades de FragmentManager para que funcione el botón Atrás. Sin embargo, administrar fragmentos, cuadros de diálogo y la pila de actividades puede ser un poco molesto.

ACTUALIZACIÓN Septiembre 2018:

Algunos desarrolladores de Google recomiendan aplicaciones de actividad única que utilizan el nuevo componente de arquitectura de navegación .

También tenga en cuenta que implementar su aplicación con múltiples Activitiesle dará al usuario una experiencia más coherente con la plataforma en su conjunto. Parte de la experiencia se moldeará mediante el uso de las aplicaciones integradas de Google, por lo que los usuarios probablemente tendrán más facilidad para usar su aplicación si se comporta de manera similar a las que ya están instaladas en el teléfono.

A diferencia de otros, utilizo una combinación de ambos, por ejemplo,
1. Hay un menú principal cuando se inicia la aplicación
2. Haces clic en buscar, te lleva a la actividad de búsqueda
3. Luego hay un botón de filtro, que simplemente cambia de vista y muestra filtra las opciones
4. Hay dos botones al final de la vista de filtro, presiona "Buscar" o "Cancelar" y regresa a la Vista de búsqueda nuevamente (sin cambiar de actividad)
5. Ahora, si el usuario vuelve a presionar el teléfono se le devuelve al menú principal en lugar de a las opciones de filtro de búsqueda. Lo que supongo que es el comportamiento correcto.

Úselo de la manera que el usuario se sienta natural. Y mantener todo en una sola actividad lo hará complejo.

Todo depende de la aplicación, lo que intentas lograr para lograr un mejor rendimiento, una interfaz de usuario más fluida. En mi humilde opinión, prefiero el segundo enfoque de controlar las actividades manualmente, incluso que es más complejo, como ha dicho. Este es un enfoque que he usado en mi proyecto de pestañas de Android, también es posible que desee echar un vistazo a una clase llamada ActivityGroup (no estoy seguro del paquete) que le permite tener múltiples actividades entre las que puede cambiar, lo bueno de esta clase es que sus actividades no se descargan cuando cambia, pero lo malo es que lleva más tiempo cargar su aplicación principal.

Solo es mi opinión.

El problema con el cambio de vistas, con el que me topé, también es causado por el recolector de basura. Parece que GC se activa cuando abandona la actividad y no la vista. Por lo tanto, cambiar pestañas con vistas secundarias bastante complejas, por ejemplo, conducirá casi inevitablemente a una excepción de desbordamiento de pila.

He experimentado tantos problemas con el diseño de múltiples actividades que lo desaconsejo enfáticamente, a menos que haya una buena razón para elegirlo.

Desventaja de múltiples actividades

Al utilizar múltiples actividades, es mucho más difícil refactorizar el código para devolver datos de la actividad.

Si llama a una 'subactividad', entonces la actividad principal puede morir. Pero nunca experimenta eso mientras depura en un dispositivo decente, por lo tanto, debe manejar siempre el estado de guardado y el estado de recuperación correcta. Eso es un dolor. Imagínese llamar a un método en una biblioteca (es decir, otra actividad), y debería asegurarse de que cuando ese método regrese, su aplicación debe poder recrear su estado completamente con todos los campos en todos los objetos en la VM (es decir, actividad. restoreIntance). Es una locura.

También al revés, cuando abre una subactividad, es posible que la VM se haya eliminado desde que se generó la subactividad por primera vez, como cuando la aplicación se minimiza mientras se muestra la subactividad.

Es mucho más limpio tener un solo lugar para almacenar el estado de la aplicación relevante y, en mi caso, la mayoría de las veces, si se mata la VM, quiero devolver al usuario a la pantalla principal y dejar que haga sus cosas nuevamente, porque no No gaste entre 30 y 50 horas codificando la funcionalidad de guardar / reanudar que el 0.1% de los usuarios experimentarán.

Alternativa

Fragmentos o simplemente administre sus vistas de actividad usted mismo. La gestión de las vistas manualmente requiere codificar alguna alternativa de cambio de vista a las actividades / fragmentos con transiciones si se desea.

Y no, no significa una megaactividad, como se sugiere en la respuesta aceptada, de ninguna otra manera que su única megaaplicación. Solo requiere un poco más de diseño de la base de código en piezas adecuadas, porque hay un poco más de trabajo en la gestión de vistas, aunque mucho menos en la gestión del estado de actividad y otras rarezas.

Posiblemente relevante: Reddit: es oficial: Google recomienda oficialmente la arquitectura de aplicaciones de actividad única