Patrón "Una actividad, múltiples vistas": Ventajas y desventajas
Este patrón es similar al patrón Main Servlet (el controlador frontal) que se utiliza para desarrollar aplicaciones web.
La idea principal de este patrón: tenemos una Actividad que gestiona múltiples vistas y esta actividad es responsable de representar el contenido actual. No todas las vistas necesitan funcional de la actividad (por ejemplo, los métodos del ciclo de vida) por lo que la pregunta principal es: si puedo ir sin actividad ¿por qué tengo que usarlo?
He encontrado las siguientes desventajas de usar este patrón:
-
La fuente oficial no recomienda sobrecargar una sola pantalla de actividad, pero no explican por qué.
-
No podemos utilizar
TabActivity,ListActivity,MapActivity. Pero hay algunos trucos para ir sin ellos. - Si diferentes pantallas tienen menú diferente es un problema para hacer que sin actividades.
- Es necesario mantener la historia por nosotros mismos. Pero no es tan difícil de desarrollar.
He encontrado las siguientes ventajas de usar este patrón:
- Es más rápido cambiar el contenido de la actividad actual que iniciar otra actividad
- Somos libres de manejar la historia como queremos
- Si sólo tenemos un contexto de actividad, es más sencillo encontrar y resolver problemas con pérdidas de memoria
¿Qué piensas de este patrón? ¿Podría proporcionar otras ventajas / desventajas?
No podemos utilizar TabActivity, ListAcivity, MapActivity. Pero hay algunos trucos para ir sin ellos.
Tienes que usar MapActivity si quieres usar MapView . Debe utilizar PreferenceActivity si desea utilizar XML de preferencia.
Es necesario mantener la historia por nosotros mismos. Pero no es tan difícil de desarrollar.
La dificultad en la gestión de su propia historia dependerá en gran medida de lo que la historia debe ser. La implementación del historial de un asistente simple será bastante fácil. Sin embargo, ese es un escenario particularmente simple. Hay una buena cantidad de código de gestión de historia en Android que tendría que volver a escribir para otros casos arbitrarios.
Usted también olvidó:
# 5. Usted será propenso a la memoria de la pérdida, porque usted olvidará limpiar la materia, y el androide no limpia la materia (puesto que asume que usted utilizará muchas actividades pequeñas, la manera que recomiendan).
# 6. Su administración de estado para los cambios de configuración (rotación, muelle, cambio de SIM, cambio de localidad, múltiples pantallas, escala de fuente) será más complicado porque ahora también tiene que averiguar qué material adicional (por ejemplo, historia) debe ser parte del estado , Y usted tiene que tratar con todos ellos a la vez en lugar de actividad-a-tiempo.
# 7. Tener múltiples puntos de entrada para su aplicación se vuelve más difícil (por ejemplo, varios iconos en el lanzador, widget de la aplicación que enlaza con alguna actividad distinta de la principal, respondiendo a etc.).
Es más rápido cambiar el contenido de la actividad actual que iniciar otra actividad
Para la mayoría de los dispositivos Android modernos, la diferencia de velocidad no será significativa para la mayoría de los usuarios, IMHO.
Si sólo tenemos un contexto de actividad, es más sencillo encontrar y resolver problemas con pérdidas de memoria
Excepto que todavía tienes más de "una actividad-contexto". Recuerde: su actividad, grande o pequeña, todavía está destruida y recreada en los cambios de configuración.
¿Qué piensas de este patrón?
La teoría de "la naturaleza de la empresa" de Coase dice que las empresas se expanden hasta que los costos de transacción para hacer las cosas internamente lleguen a ser más altos que los costos de transacción para que otras firmas hagan lo mismo.
La teoría de "la naturaleza de la actividad" de Murphy dice que la actividad se expande hasta que los costos de transacción de hacer las cosas internamente se vuelven más altos que los costos de transacción para que otras actividades hagan lo mismo. Los desarrolladores de Android tendrán tendencia hacia un modelo de "transacción de usuario" para las actividades; las cosas que están estrechamente acopladas (por ejemplo, los pasos de un asistente) tienden a ser manejadas en una sola actividad y las que tienen poca relación (por ejemplo, Vs. ajustes vs. ayuda vs.) tienden a ser manejados en distintas actividades.
Esto será horrible de mantener si se agrega nueva funcionalidad más adelante. También no estoy convencido de que será mucho más rápido que el usuario podría notar. Tener componentes como piezas más pequeñas que son más fáciles de cambiar o intercambiar es definitivamente el camino a seguir.