Introducción

Para el desarrollo de aplicaciones móviles es importante considerar el modelo de arquitectura, lo cual permitirá al desarrollador enfocar sus habilidades al objetivo de la aplicación y al público al que esta se orienta.

Implementar un modelo de arquitectura facilita el mantenimiento, agregar nuevas características, cambiar las existentes e incluso reestructurar toda la aplicación con un menor costo de recursos.

Una comprensión de la arquitectura para el desarrollo de aplicaciones inicia con una definición, sin embargo, es importante conocer las razones del porqué la arquitectura de software juega un rol importante en los proyectos de desarrollo y los beneficios de un buen diseño arquitectónico.

Asimismo, es relevante entender que tanto los clientes (interesados del desarrollo) como los miembros del equipo de desarrollo (desarrolladores) son impactados por la arquitectura de software de un sistema.

A continuación, se tratarán los modelos de arquitectura de software más utilizados en las aplicaciones móviles, así como sus características y sus propiedades.

Explicación

Modelos de arquitectura

De acuerdo con Da Costa, Misra y Soares (2019), el IEEE (Instituto de Ingenieros en Electricidad y Electrónica), en su estándar ISO/IEC/IEEE 2011, define a la arquitectura de software como: “Conceptos fundamentales o propiedades de un sistema en un entorno definido, concebido en elementos, las relaciones que existen entre ellos y los principios que guían su diseño y evolución”.

La definición de arquitectura de software provee los siguientes puntos:

• La arquitectura es una parte fundamental de un sistema de software.
• Un sistema de software está situado en un entorno y la arquitectura lo considera para operar.
• La arquitectura documenta y comunica las necesidades del sistema a los interesados del proyecto.
• Las vistas de la arquitectura cubren los intereses de los involucrados del proyecto.

La arquitectura de software de un programa, de un sistema informático, o bien, de una aplicación, es la estructura o estructuras del sistema, que comprenden los elementos del software, las propiedades externas visibles de esos elementos y las relaciones que hay entre ellos.

La arquitectura es una abstracción del sistema de software y la estructura del sistema de software consiste en los elementos que lo conforman. La arquitectura detalla la estructura de sus elementos y las relaciones de dichos elementos uno con otro, según Ingeno (2018).

Los beneficios de la arquitectura de software que destacan son los siguientes:

• Anticipa las cualidades del sistema de software.
• Facilita la comunicación con los interesados.
• Favorece la realización de cambios.
• Permite la creación de un modelo rentable para implementar en múltiples productos de software.
• Habilita los límites de la implementación, reduciendo la complejidad y minimiza los errores de desarrollo.
• Eficientiza costes y el esfuerzo de desarrollo.
• Sirve como recurso de capacitación para nuevos miembros en el equipo de desarrollo.

El arquitecto de software es el responsable de las decisiones técnicas, así como de la arquitectura y la documentación. Este rol realiza varias actividades y se espera que tenga el conocimiento en varios temas tanto técnicos como en temas referentes al liderazgo, la administración de proyectos, la mentoría a los miembros del equipo y en habilidades interpersonales, etc.

Los modelos de arquitectura de software son una de las herramientas más utilizadas para el diseño de arquitecturas. De acuerdo con Ingeno (2018), un modelo de arquitectura es una solución a un problema recurrente que es comprendido dentro de un contexto en particular. En otras palabras, cada modelo está conformado por un contexto, un problema y una solución.

El problema puede ser un reto para resolver, obtener una ventaja de una oportunidad o satisfacer uno o más atributos de calidad. Los modelos codifican el conocimiento y la experiencia en una solución que puede reutilizarse. Aplicar modelos de arquitectura al desarrollo simplifica el diseño y permite hacer uso de los beneficios de utilizar una que se ha probado, como mejorar la comunicación entre los colaboradores que están familiarizados con el uso del modelo.

Dentro de los modelos de arquitectura más utilizados en la industria del desarrollo de software destacan solo por mencionar algunos: arquitectura de capas, arquitectura dirigida a eventos (EDA), Modelo Vista Controlador (MVC), Modelo Vista Presentador (MVP), Modelo Vista-Vista Modelo (MVVM) y arquitectura orientada al servicio (SOA).

Por otra parte, para el desarrollo de aplicaciones móviles, los modelos que más se ajustan a este tipo de desarrollo son MVP y MVVM, los cuales se describirán en los siguientes párrafos.

La aplicación de un modelo de arquitectura es de suma importancia para asegurar el éxito de un proyecto de desarrollo de software y para facilitar la comunicación entre las partes involucradas, por eso es importante que el desarrollador de aplicaciones móviles esté familiarizado con las diferentes arquitecturas.

Modelo Vista Presentador (MVP)

El Modelo Vista Presentador (MVP) es un modelo de arquitectura que se utiliza ampliamente para las interfaces de usuario. El modelo es particularmente bien implementado para aplicaciones web, aplicaciones de escritorio, pero destaca su uso en aplicaciones móviles.

El MVP provee una separación entre la lógica de la interfaz de usuario y la lógica de negocio. Se le llama lógica de negocio a la parte de un sistema que se encarga de codificar la operación habitual del mundo real, la que determina cómo la información puede crearse, procesarse y almacenarse. También es importante clarificar que el término en los modelos de arquitectura de UI (interfaz de usuario) incluye también la gestión de los eventos y las comunicaciones (Ingeno, 2018).

Figura 1. Componentes del modelo de arquitectura MVP.

Los principales componentes de este modelo son los siguientes:

1. Modelo (model): representa la lógica del negocio y la información; interactúa con la base de datos para obtener y actualizar información. El modelo recibe mensajes del presentador para actualizar y reportar cambios de estado en el mismo. No tiene interacciones directas con el componente vista, solo con el componente presentador.
2. Vista (view): es el componente responsable de mostrar la interfaz de usuario y la información a desplegar. Tan pronto como el usuario interactúa con la vista, esta enviará mensajes al presentador para interactuar con los eventos y la información procesada. Los presentadores están vagamente acoplados con las vistas a través de las llamadas interfaces de vista. Las vistas son más pasivas en este modelo y confían en el presentador para proveer de información a exhibir.
3. Presentador (presenter): es el componente intermedio entre los componentes de vista y modelo. Interactúa con ambos; cada vista tiene un presentador y la vista notifica al presentador de las acciones del usuario. El presentador actualiza el modelo y recibe los cambios de estado del modelo; una vez recibido este cambio, el presentador dará formato para que la vista muestre la información.

El presentador toma un rol activo en la lógica de presentación; encapsula la lógica de presentación, haciendo que las vistas tengan un rol más pasivo. Un presentador típicamente maneja una y solo una vista (Ingeno, 2018).

Modelo Vista-Vista Modelo (MVVM)

El Modelo Vista-Vista Modelo (MVVM) comparte similitudes con el MVP. Al igual que otros modelos, mantiene un paradigma SoC, siglas del inglés que significan separación de responsabilidades. Esto hace que una aplicación sea más fácil de mantener, extender y probar. El MVVM separa la interfaz de usuario del resto de la aplicación.

Figura 2. Componentes del modelo de arquitectura MVVM.

Este modelo fue propuesto por Microsoft con la salida de Windows 8 y su tienda de aplicaciones con el entorno de desarrollo Windows Presentation Foundation. Los principales componentes de este modelo son los siguientes:

1. Modelo (model): juega el mismo rol que el modelo MVP, representa el objeto dominio del negocio y la información. El modelo usa la base de datos para recuperar, registrar y actualizar la información. En las aplicaciones basadas en el MVVM puede tener un enlace directo con las propiedades del modelo, dando como resultado que los modelos generen notificaciones con el cambio de propiedad.
2. Vista (view): la vista es la responsable de la interfaz de usuario (UI), es la parte de la aplicación que es visible a los usuarios. En el modelo MVVM, la vista es activa. A diferencia de un rol pasivo, como en el modelo anterior, aquí el componente vista está al pendiente del modelo y del componente VistaModelo.
3. VistaModelo (ViewModel): este componente es muy similar al presentador en el modelo anterior, es el encargado de coordinar el flujo entre el componente modelo y el componente vista. Los componentes vistamodelos proveen datos a las vistas para mostrarse en pantalla y manipulados; también contienen la interacción lógica a comunicarse entre las vistas y los modelos.

Los componentes vistamodelos deben ser capaces de manejar las acciones del usuario y la entrada de datos enviada desde las vistas. El componente vistamodelo es el que contiene la navegación lógica para moverse a diferentes vistas (Ingeno, 2018).

Gracias a estos modelos de arquitectura, el desarrollador será capaz de comprender la lógica de los componentes de las aplicaciones nativas tanto para Android como para iOS, las cuales están basadas en los modelos que se mencionaron.

Componentes de una aplicación Android

A continuación, analizarás los componentes de una aplicación Android. Android está estructurado en forma de una pila de software, agrupando aplicaciones, sistema operativo, entorno para tiempo de ejecución, servicios, librerías, etc. La mejor manera de representar esto es mediante un diagrama (figura 3):

Figura 2. Capas del sistema operativo Android.

Cada una de las capas están integradas fuertemente y afinadas una con otra con la finalidad de proveer una óptima experiencia en el desarrollo y ejecución de las aplicaciones móviles.

La capa más profunda (base) de este modelo de la plataforma es el kernel (núcleo) de Linux, el cual permite administrar y controlar procesos de la memoria a bajo nivel, y asegura las funciones de seguridad clave. Es importante mencionar que al ser un kernel de código abierto permite a los fabricantes de equipos móviles desarrollar controladores de hardware (Android Developers, s.f.-a.).

Posteriormente, al kernel, en una capa superior se encuentra la llamada capa de abstracción de hardware, por sus siglas en inglés, HAL, es la encargada de generar una interfaz entre el hardware a la capa del entorno de aplicación de la API de Java. La capa siguiente, inmediata y superior está dividida en dos partes: las bibliotecas C/C++ nativas, y el tiempo de ejecución de Android se denominará ART, por sus siglas en inglés.

Cada aplicación de Android ejecuta sus propios procesos en una instancia propia. El ART está codificado para que de manera óptima minimice el uso de memoria; dentro de las funciones principales del ART se tiene la compilación ahead-of-time y just-in-time (compilaciones que maximizan el rendimiento antes de ejecutarse) y la recolección optimizada de elementos no utilizados (GC) según Android Developers (s.f.-b).

En esta capa también residen las bibliotecas nativas de C/C++. De acuerdo con Smyth (2021), muchos componentes hacen uso de bibliotecas nativas escritas en C y C++. Android proporciona un API del marco de trabajo de Java para vincular las bibliotecas de aplicaciones nativas a las aplicaciones. Existe una gran variedad de funciones, incluyendo los gráficos en 2D y 3D, capas de socket seguro, comunicaciones, administración de base de datos SQLite, reproducción de audio y video, entre muchas otras, y se encuentran dentro de las bibliotecas nativas de C/C++.

La penúltima capa es la del marco de trabajo de la API de Java; en el sitio de Android Developers (s.f.-a) se menciona que todo el conjunto de funciones del sistema operativo Android están disponibles mediante API escritas en Java.

Se puede decir que los cimientos de toda aplicación en Android radican en esta capa. Significa que lo necesario para desarrollar aplicaciones se encuentra aquí y puede reutilizar, intercambiar y reemplazar componentes. Todo bajo la premisa que toda aplicación es capaz de publicar sus capacidades y pueden ser encontradas y reutilizadas por otras aplicaciones.

En la última capa se incluyen, primeramente, el conjunto de aplicaciones centrales para realizar actividades esenciales que vienen instaladas por defecto en el sistema operativo. Dentro de estas aplicaciones se encuentran la mensajería SMS, calendarios, navegación en Internet, contactos, entre otros. Los desarrolladores pueden utilizar estas aplicaciones del sistema para agregar funcionalidades a las ya desarrolladas. También en esta capa se sitúan todas aquellas aplicaciones instaladas por el usuario final.

Con base en la documentación de desarrollo oficial de Android (Android Developers, s.f.-a), los componentes de una aplicación de Android se pueden considerar bloques de creación y estos componentes son los siguientes:

1. Actividades: son los objetos que permiten al usuario interactuar con la aplicación. Se puede interpretar como cada una de las pantallas que tiene la aplicación. Cada una de esas actividades son independientes y otras aplicaciones pueden hacer uso de esas actividades individuales para realizar una tarea en específico.

   Por ejemplo, la aplicación de mensajería se puede considerar una actividad en la pantalla donde se enumera el listado de todos los mensajes, otra actividad en la pantalla donde el usuario redacta el mensaje para enviar y otra actividad para leer los mensajes de un usuario. Una aplicación externa puede acceder únicamente a la actividad de un nuevo mensaje para poder enviar ese mensaje sin acceder al resto del contenido de la aplicación.

2. Servicios: este componente de una aplicación permite tener la ejecución de esta en segundo plano. El servicio no provee una interfaz de usuario ni tampoco interacción con el usuario. Por ejemplo, se puede considerar una aplicación de reparto de comida, la cual, al realizar un pedido, dará el seguimiento al reparto, aun cuando el usuario pueda cambiar de aplicación, esta seguirá proporcionando las actualizaciones del pedido y el usuario puede retomar la interacción abriendo de nuevo la aplicación de reparto.

3. Receptores de emisiones: componente encargado de posibilitar que el sistema haga entrega de eventos a la aplicación, permitiendo que responda a los anuncios de emisión de todo el sistema. Los receptores de emisión son un punto de entrada adicional a las aplicaciones, permitiendo que el sistema pueda entregar incluso a las aplicaciones que no estén en ejecución.

   Como ejemplo, una aplicación puede programar una notificación sobre un evento futuro para informar al usuario; la aplicación no necesitará estar en ejecución y el receptor de emisiones preparará todo para hacer que se ejecute la alerta.

4. Proveedores de contenido: su principal misión es administrar la persistencia de datos, en otras palabras, permite que la aplicación almacene en el sistema de archivos, en una base de datos SQLite, en la web o en cualquier otra ubicación de almacenamiento persistente y gestionar el acceso a esos datos. Gracias al proveedor de contenidos, la aplicación puede almacenar, consultar y modificar los datos.

Cabe mencionar que la activación de los componentes antes mencionados se ejecuta por un mensaje asíncrono llamado intent. Los intents vinculan los componentes entre sí en tiempo de ejecución. Por último, es importante mencionar que existe un archivo de manifiesto, este permite establecer la existencia de los componentes (declaración), identifica los permisos de usuarios, establece el nivel mínimo de versión de API a aplicar, declara el uso de bibliotecas y las características de hardware y software que la aplicación usa o exige (Android Developers, s.f.-a).

Es importante conocer teóricamente estos apartados, ya que prepararán al desarrollador para conocer las bases de una aplicación.

Componentes de una aplicación iOS

Los componentes para la creación de aplicaciones en iOS son controlados por el entorno de programación UIKit, que es el encargado de gestionar los elementos más comunes en las interfaces de usuario. Este ecosistema permite tener una uniformidad de diseño. El UIKit define tres elementos principales:

• Barras: permiten a los usuarios un panel de navegación y ubicar en qué apartado están en la aplicación.
• Vistas: despliegan en pantalla el primer contenido que ven los usuarios, como el texto, gráficas, animaciones, elementos interactivos, etc.
• Controles: son los elementos que permiten iniciar acciones, como botones, switches, campos de texto, indicadores de progreso, etc.

El UIKit define la funcionalidad que la aplicación puede adoptar; a través de este entorno el desarrollador puede colocar las acciones que responderá al uso de gestos en la pantalla táctil, habilitar la capacidad de dibujar en pantalla, accesibilidad, imprimir, etc.

iOS integra de manera firme otros marcos de trabajo como integradores para pagos electrónicos, kit de análisis biométricos y de salud, librerías para el acceso a base de datos, interacción con sensores o bien con elementos de hardware cámaras, giroscopios, etc.

Desarrollando la interfaz de usuario

Android Developers (s.f.-b), en su guía técnica de desarrollo, define que la interfaz de usuario es todo aquello que este puede ver y con lo que puede interactuar en ella. La interfaz del usuario tiene un gran peso en el desarrollo de la aplicación, ya que un buen diseño de interfaz de usuario permitirá hacer la experiencia de uso fluida y placentera, haciendo, por ende, que la aplicación sea funcional.

Para que una aplicación móvil cumpla con su objetivo, el cual es dar una respuesta fluida a la necesidad que tiene el usuario, un factor importante es la calidad de la experiencia de uso que se obtiene a través de la interacción con la interfaz de usuario (UI), experiencia fluida y operacional.

Algunas de las consideraciones para el diseño que se deben tomar en cuenta son las siguientes:

1. Experiencia visual y una interacción coherente a fin de garantizar una usabilidad intuitiva y coherente.
2. Funcionalidad: una aplicación deberá funcionar conforme al objetivo de esta.
3. Rendimiento y estabilidad: toda aplicación debe proporcionar un rendimiento, deben ser estables por sí mismas y la respuesta debe ser inmediata; esto se logra canalizar en mayor parte por la interfaz de usuario.
4. Privacidad y seguridad: esta característica no es exclusiva de la interfaz de usuario, sino es en sí de toda la aplicación, pero es muy importante resguardar los datos del usuario y su información personal, de acuerdo con un esquema de nivel de permisos.
5. Pantalla de inicio: la función de la pantalla de inicio da la impresión de que su aplicación es rápida y receptiva, al tiempo que permite que se cargue el contenido inicial de la aplicación.
6. Orientación adecuada: la aplicación debe iniciarse con la orientación actual del dispositivo. Si la aplicación solo se ejecuta en una orientación, siempre debe ejecutarse en la misma y permitir que las personas giren el dispositivo si es necesario.
7. Evita pedir información de configuración por adelantado: es importante tratar de configurar la aplicación con los ajustes de configuración predeterminados, ya que el usuario solo espera que la aplicación funcione. Si tiene que solicitar información de configuración, debe solicitarlo al usuario la primera vez que abra la aplicación y permitirle modificarla más tarde en la configuración de la aplicación.
8. Restaura el estado anterior: evita que los usuarios vuelvan sobre los pasos para llegar a la ubicación anterior en tu aplicación. Conserva y restaura el estado de la aplicación para que el usuario pueda continuar donde lo dejó.
9. Evita el reinicio: reiniciar lleva tiempo y hace que la aplicación sea poco confiable y difícil de usar. Si la aplicación tiene problemas de memoria u otros problemas que dificultan su ejecución, a menos que el sistema se haya iniciado recientemente, debe solucionar esos problemas.
10. Induce: una guía permite dar la bienvenida a nuevos usuarios y volver a conectarse con los que regresan. Una experiencia rápida, divertida y educativa ayuda a los usuarios a aprovechar al máximo su aplicación sin interferir.
11. Anticipa la necesidad de ayuda: se deben buscar, de manera proactiva, momentos en los que las personas puedan necesitar apoyo para operar. Permite que las personas tengan acceso a una manera fácil de resolver posibles dudas.
12. Aprendizaje divertido y reconocible: aprender haciendo es mucho más divertido y efectivo que leer una lista de instrucciones. Utiliza la animación y la interactividad para enseñar de forma gradual y el contexto.
13. Carga: cuando se carga la información de la aplicación y aparece una pantalla blanca o estática, puede hacer que parezca que la aplicación está congelada y hacer que los usuarios la abandonen. Deja claro que se está realizando una carga, muestra una ruleta de actividad que comunique que algo está sucediendo.
14. Muestra el contenido lo antes posible: es importante no hacer que las personas esperen a que se cargue todo el contenido antes de ver la pantalla que esperan, muestra la pantalla de inmediato y usa el texto de marcador de posición, gráficos o animaciones para identificar donde el contenido aún no está disponible.
15. Educa o entretén a la gente para enmascarar el tiempo de carga: considera mostrar sugerencias sobre el juego, secuencias de video entretenidas o gráficas de marcador de posición.
16. Modalidad: presenta contenido en un modo temporal que requiere una acción explícita para salir. Ayuda a las personas a concentrarse en una tarea autónoma o en un conjunto de opciones estrechamente relacionadas y ayuda a asegurarse de que las personas reciban información crítica y, si es necesario, actuar en consecuencia para centrar la atención de las personas en tomar una decisión o realizar una tarea que sea diferente a la actual.
17. Reserva las alertas para entregar información esencial e idealmente procesable: debido a que una alerta interrumpe la experiencia actual, ya que requiere de un toque para descartarla, es importante que las personas sientan que la intrusión está justificada.
18. Mantén las alertas modales simples, breves y con un enfoque limitado: ten cuidado de evitar crear una experiencia modal que se sienta como una aplicación dentro de una aplicación, ya que los usuarios pueden olvidar cómo volver a sus pasos hasta la tarea original.

Es importante tener en cuenta las sugerencias hechas para el diseño de la interfaz de usuario, ya que la filosofía de las aplicaciones móviles radica en la fluidez, funcionalidad y óptimo rendimiento. La exigencia de los usuarios móviles siempre estará enfocada en la rapidez y sencillez de las operaciones.

Cierre

Como profesional, debes encaminar tus desarrollos a una arquitectura de software, esto facilitará la actualización, mantenimiento y reestructura de la aplicación.

Los modelos vistos: MVC y MVVM, son los modelos de arquitectura más utilizados para desarrollos de cómputo móvil. Es importante considerar los tecnicismos y características de los sistemas operativos móviles para entender cómo estas características impactarán en el rendimiento de las aplicaciones.

Asimismo, deberás recordar la guía de buenas prácticas para diseñar interfaces, ya que se basan en la experiencia de millones de usuarios, han sido probadas y resultan funcionales. No obstante, en el proceso creativo, muchas otras opciones pueden salir para beneficiar la experiencia final del usuario.

Checkpoint

Asegúrate de:

• Aplicar el concepto de arquitectura de software para trasladarlo al desarrollo de aplicaciones móviles.
• Practicar cómo se estructuran los modelos MVP y MVVM para aplicarlos en los componentes de las aplicaciones.
• Detectar las capas del sistema operativo para ubicar la obtención de llamadas a hardware sistema.
• Integrar los componentes que se requieren para una aplicación en Android e iOS para entender las diferencias y cómo estas se adecuan a las arquitecturas de software.
• Aplicar las recomendaciones para el diseño de interfaces de usuario para contribuir en la generación de aplicaciones móviles ágiles y funcionales.

Bibliografía

• Android Developers. (s.f.-a). Arquitectura de la plataforma. Recuperado de https://developer.android.com/guide/platform
• Android Developers. (s.f.-b). Aspectos fundamentales de la aplicación. Recuperado de https://developer.android.com/guide/components/fundamentals?hl=es-419
• Da Costa, S., Misra, S., y Soares, M. (2019). A Systematic Mapping Study on Software Architectures Description Bases on ISO/IEC/IEEE 42010:2011. Recuperado de https://www.researchgate.net/publication/334086570_A_Systematic_Mapping_Study_on_Software_Architectures_Description_Based_on_ISOIECIEEE_420102011
• Ingeno, J. (2018). Software Architect’s Handbook. Reino Unido: Packt Publishing.
• Smyth, N. (2021). Android Studio 4.2 Development Essentials - Kotlin Edition. Reino Unido: Payload Media.