La respuesta corta es no.
¿Vale la pena desarrollar uno? Depende de su presupuesto y la cantidad de riesgo que puede soportar al hacerlo. Me ENCANTARÍA colaborar en este marco, si suficientes mentes se pueden unir para diseñarlo y ponerlo en marcha.
La respuesta más larga tiene que ver con la arquitectura principal de Android y sus limitaciones de diseño. La abstracción de Android Activity es uno de los defectos fundamentales en el marco de presentación de Android y la causa de muchas limitaciones y la razón por la cual las aplicaciones de Android no pueden coincidir con la experiencia de usuario de sus contrapartes de iOS. La falla proviene de la suposición de que solo debe haber una Actividad en ejecución a la vez, y que esta Actividad debe estar vinculada a una sola vista. Esta suposición requiere un mecanismo fuera de límite (es decir: Intenciones) para la navegación y la coordinación entre otras Actividades. En un marco MVC adecuado, los controladores deberían poder gestionar múltiples vistas (es decir: cargarlas / descargarlas perezosamente si lo desean), así como ser estructuradas en jerarquías arbitrarias (controlador con controladores secundarios que a su vez tienen controladores secundarios, etc.). Las actividades de Android son de naturaleza única: solo puede tener una actividad ejecutándose a la vez.
- ¿Necesito saber alguna codificación para aprender a hacer aplicaciones Android?
- ¿Tengo que aprender programación de Android antes de Unity?
- Cómo saber cuándo es el momento de publicar una aplicación en la que has estado trabajando
- Cómo comenzar con el desarrollo de aplicaciones de Android con solo un conocimiento muy básico sobre programación
- ¿Cómo contrato a personas para desarrollar una aplicación de Android?
Los fragmentos se introdujeron como un truco para lidiar con esta limitación, y si observas la superposición de la superficie API entre Fragmentos y Actividades, tus campanas de arquitectura deberían sonar, lo que realmente era una falta de diseño y no deberían existir dos entidades separadas como esta. superposición en la funcionalidad. El hecho de que los Fragmentos tuvieron que ser introducidos como un concepto separado, con su propio conjunto de inconvenientes y limitaciones, es revelador y preocupante. Desafortunadamente, incluso los fragmentos en sí son limitados, ya que en esencia no pueden contener sub-fragmentos. Android 4.2 introdujo otro truco con Nested Fragments (http://developer.android.com/abo…), pero una gran limitación aquí es que los fragmentos anidados no pueden cargar vistas XML y en su lugar deben codificarse mediante programación (¿qué? ) Al final del día, no debería haber distinción arquitectónica entre un controlador secundario y un controlador raíz / primario, y por lo tanto un Fragmento y una Actividad. Esta es una abstracción rota. En Android, todo se basa en la suposición errónea de que solo puede tener una Actividad ejecutándose a la vez, por lo que no puede usarla para cumplir con todas las responsabilidades que los controladores reales en MVC deben realizar.
Para ver hasta dónde pueden llegar estas implicaciones, tenga en cuenta que los diálogos en Android también necesitan su propio mecanismo fuera del límite, las transiciones de pantalla personalizadas no se pueden controlar manualmente para decidir cómo deben transitar las vistas … olvida olvidarte de mostrar dos pantallas diferentes a la vez (tal vez de una manera parcialmente superpuesta donde tiene una pantalla deslizable hacia arriba y revela otra). O incluso algo tan básico como tener una pila de navegación con una barra de título que permanece estática en la pantalla a medida que cambia el resto de la pantalla y se sumerge dentro / fuera de la pila de navegación. Observe cómo las aplicaciones de Android que usan esta estructura de navegación se desvanecen en una nueva pantalla de una manera muy poco natural y use el mecanismo del SO fuera de la pantalla (ActionBar) para poder hacerlo. ¿Alguna vez ha intentado configurar estructuras de comunicación entre Actividades, donde una Actividad secundaria devuelve datos a su controlador principal? Mecanismo fuera de límite. Ah … y luego está la orientación del dispositivo que borra y vuelve a crear una instancia de Actividad cada vez. Cada uno de estos mecanismos rompe Android, porque Android en su núcleo no puede soportar MVC.
Para salir de estas limitaciones, alguien tendría que construir un marco MVC que aprovechara una sola Actividad para toda la aplicación, romper su conexión con cualquier vista en particular y usar Controladores adecuados para cargar / descargar vistas dinámicamente a medida que el usuario navega en toda la aplicación Esto es EXACTAMENTE lo que está sucediendo en el mundo web con las Aplicaciones de una sola página (SPA) donde solo tiene una página que se carga por adelantado y todo lo demás utiliza un marco MVC del lado del cliente (Angular, Ember, etc.) para cargar contenido dinámicamente a través de AJAX y el cliente lado de manipulación DOM.
SÍ, la arquitectura de presentación de Android está desactualizada y necesita un impulso / cambio significativo (como está sucediendo en el mundo web con SPA). Afortunadamente para Google, no tienen otros competidores competentes que los desafíen para llevar una mejor experiencia de usuario a las masas.
PD: Si alguien quiere colaborar en un marco de MVC de este tipo, no dude en enviarme un mensaje / comunicarse – mbradea__at__gmail_com. Me encantaría conversar al respecto y tengo muchas ideas sobre cómo hacerlo. 🙂
