Módulos clave de un framework de desarrollo acelerado: herramientas para mejorar las capacidades del Framework base

Algunos de los módulos principales de un framework de desarrollo acelerado son aquellos que ofrecen herramientas para mejorar las capacidades del framework original. Por ejemplo, el framework original puede ser Android, iOS, Angular, etc., pero crear una propuesta tecnológica personalizada para la organización. En otro artículo ya hablamos sobre otros módulos importantes, aquellos que aportan herramientas para simplificar el trabajo del desarrollador , y definimos aspectos tan importantes para un framework como la separación de responsabilidades.

En este bloque encontraremos tres módulos diferentes: CORE, UI y COMMONS. A continuación mostraremos un ejemplo de implementación de estos tres módulos, que proporcionarán al equipo de desarrollo las capacidades clave necesarias para un Framework de desarrollo acelerado.

Módulo CORE. Epicentro habilitador del framework

La solución software o propuesta de arquitectura definida en este módulo es la base que cimienta las capacidades en que se basan los módulos anteriores para la generación de código automático. Este módulo proporciona la solución técnica sobre la que pivota el módulo de UI. Establece los mecanismos que habilitarán la comunicación entre los componentes visuales. Además, suplementa las capacidades del framework de base y las librerías complementarias que se cargan en las dependencias del proyecto.

Se recomienda limitar al máximo la propuesta de librerías de terceros utilizadas. Solo se debe de hacer uso de ellas cuando el desarrollo ad-hoc de dichas capacidades comporte un esfuerzo considerable. Además, habrá que asegurar que se tiene el control o garantía sobre la continuidad de las librerías, o que sean de código abierto.

En cuanto a la extensión de los componentes visuales del framework de base, se recomienda hacer uso de aquellos que sean realmente básicos. Elementos como menús, barras de acción o similares, pueden recibir comportamientos visuales distintos entre distintas versiones del SDK del fabricante. Esto podría generar comportamientos inesperados sobre la especificación identificada en el Sistema de Diseño.

Namespace o espacio de nombres para ubicar los aceleradores de software

El módulo CORE ofrecerá un espacio de nombres (namespace) específico donde se ubicarán los aceleradores de software para resolver necesidades clave a la corporación. Por lo general no estaránn relacionadas con la representación visual de los componentes, y se pueden destacar:

• Capacidades de multilenguaje.
• Aplicación del patrón de diseño en la capa de presentación (MVC, MVP, MVVM…) y el paradigma de comunicación entre las vistas y los modelos de datos (reactivo, imperativo, declarativo…).
• Aplicación de los patrones de software: Factory Pattern, Command Pattern, Adapter, etc.
• Capacidades se securización: ssl pinning, intercepción de comunicaciones, encriptación, etc.
• Mecanismos persistencia local y sus alternativas disponibles.
• Explotación de las librerías y procedimientos para el desarrollo de las pruebas unitarias, de interfaz, de integración, etc.
• Mecanismos para diferenciar distintas versiones de la aplicación por localización (distintos países/mercados).
• Mecanismo de inyección de dependencias sobre las clases oportunas.

Algunos ejemplos de espacios de nombres relacionados son:

• vass.core.network: permite out-of-the-box evitar ataques man-in-the-middle.
• vass.core.testing: aplica y exige un workflow sobre la librería Mockito.
• vass.core.persistence: diferencia, por ejemplo, entre distintos modos de persistencia local, en BBDD o en fichero (preferencias del sistema).
• vass.core.security: desarrolla soluciones a vulnerabilidades conocidas.
• vass.core.analytics: establece distintos mecanismos para monitorizar automáticamente las interacción que realizan los usuarios sobre las aplicaciones sin desarrollar código adicional.

Un patrón de comunicación muy efectivo (aplicable de igual manera con independencia de la plataforma: iOS, Android, Angular…) es MVVM. Su objetivo es facilitar la comunicación entre objetos de presentación. Su modelo es el uso de patrones de programación reactiva, basados en la actualización por suscripción al cambio del modelo de datos asociado y en el envío del estado de la vista al componente vista-modelo asociado.

Módulo UI. Catálogo de componentes del framework acelerador

El módulo de UI de un framework acelerador está formado por los componentes disponibles en su catálogo de componentes.

Aunque en artículos previos ya hemos definido el Catálogo de Componentes Básicos como piedra angular del desarrollo acelerado de interfaces de aplicaciones, es importante reseñar que dichos componentes deberán responder a especificaciones de arquitectura. También deberán de implementar interfaces estandarizadas de comunicación que les permitan establecer comunicaciones en los siguientes ámbitos:

Comunicación contextual

Un componente básico deberá responder ante eventos del sistema y de componentes hermanos. Los componentes hermanos son los que se encuentran anidados en el mismo nivel de profundidad de la vista padre en la que se instancian: respondiendo a redimensionamientos de terceros, cambios de orientación, aplicación de efectos de accesibilidad, etc..

La implementación de estas capacidades suele emplear la extensión de las capacidades de las clases de más alto nivel de Vista (View). Se aprovechan de este modo algunos eventos de sistema que pueden ser aplicados de manera reactiva o a través de alguno de los métodos del ciclo de vida de la aplicación.

Comunicación vertical

Es conocida como la propagación de eventos a componentes de distinto nivel jerárquico, y puede ser bidireccional. Descendente cuando el evento se propaga hacia elementos hijos, o ascendente cuando el evento se produce en elementos anidados dentro del componente objeto de estudio y se debe propagar hacia su elemento padre (el que lo aloja).

La implementación de este tipo de comportamientos se realiza dentro de la clase correspondiente al componente, donde se decidirá el tipo de actuación que realizará según la naturaleza del componente. Por ejemplo, cuando un ítem de lista tiene a su vez un componente pulsable en su interior, éste debe de consumir el “evento touch” (no propagar al componente padre el evento). De este modo se podrá ejecutar el procedimiento asociado a la pulsación únicamente en el elemento anidado. En caso de que el elemento anidado no consumiese el “evento touch” y este llegase al elemento padre (el ítem de lista), se producirían simultáneamente ambas acciones: la correspondiente al elemento anidado y al elemento padre.

Comunicación comportamental

Los componentes visuales disponen de métodos que les permiten modificar su aspecto y contenido, disparar la ejecución de casos de uso y tomar acciones de control (code-behind). Existen tres ejecuciones principales en cuanto a su comportamiento:

• No-way: Cuando el componente no dispone de ningún tipo de interacción, es decir que su aspecto es estático y tampoco es capaz de transmitir ningún tipo de evento. Este tipo de componente tendrá una reutilización muy limitada.
• One-way: Cuando el componente tiene capacidad para poblar o modificar sus vistas a través de la información transmitida desde la clase encargada de orquestar la presentación. Estos componentes ofrecen información dinámica al usuario.
• Two-way: Además de las capacidades descritas en el punto anterior, estos componentes tienen la capacidad de generar eventos que permitirán disparar casos de uso. Dichos eventos podrán ir acompañados con los modelos de datos definidos (por ejemplo, con la selección realizada por el usuario), que aprovisionarán información a los métodos de operación y control de la aplicación.

Módulo COMMONS. Helpers suite para acelerar el desarrollo

Es muy frecuente que durante los desarrollos necesitemos realizar todo tipo de transformaciones de datos aplicando en repetidas ocasiones operaciones matemáticas, compresión de datos y trasformaciones sobre imágenes, validaciones de ciertas tipologías de información, captura de información, etc. Estas herramientas son por definición aceleradores del desarrollo. Suelen distribuirse en un mismo módulo en base a espacios de nombres cohesionados que facilitan el acceso a dichas funciones proporcionando herramientas para optimizar operaciones relacionadas por ejemplo:

• Tratamiento de imágenes: fuentes de selección (galería, cámara, sistema de archivos…), recortado de imágenes, compresión, filtros, escalado, transformaciones, OCR, optimización, saturación de color, etc.
• Operaciones de red: control de políticas de caché, control de conectividad, validación de certificados, activación y desactivación de las características de conectividad.
• Seguridad y encriptación: Funciones de encriptado y desencriptado y aplicación de mecanismos de seguridad de caja para la corrección de riesgos habituales, ofuscación, etc.
• Tratamiento de cadenas: Transformación de cadenas de texto y aplicación para visualización. Moneda (currency), Validaciones, formatos condicionales, visualización, etc.
• Operaciones sobre colecciones: ordenación, selección y optimización de memoria.
• Explotación optimizada de mecanismos vinculados al framework: notificaciones push, captura de eventos broadcast del sistema, accesibilidad, uso optimizado de sensórica, etc.

En esta serie de artículos hemos revisado las capacidades de los distintos módulos SETUP, TEMPLATES , CORE, UI y COMMONS, e identificado las dependencias que se crean en esta suite de herramientas y aceleradores software.

Para finalizar, es importante poner el énfasis en la sincronización de la propuesta técnica que los cohesiona y en el sistema de versionado que permita trazar y hacer convivir la evolución de cada una de las versiones de los módulos, así como trazar el plan de obsolescencia de aquellas capacidades que ya no deban coexistir en versiones posteriores.