Glyphstock. Aplicación cliente multiplataforma

(1)

T rabajo F in de G ra do

GRADO EN INGENIERÍA INFORMÁTICA

Glyphstock. Aplicación cliente multiplataforma

CELIA CARO GÓMEZ

Tutor

Gabriel Fontanet Nadal

Escola Politècnica Superior

Universitat de les Illes Balears

(2)

(3)

Gracias a todas las personas, que han aparecido en mi camino, por enseñarme algo por muy pequeño que sea. Gracias a Glyphstock, por confiar en mí y dejarme pertenecer actualmente a su plantilla de trabajadores. Gracias a mi familia, por creer en mí cuando yo no lo hice, por ser uno conmigo. Gracias a ti, Pepi, porque se que siempre estás conmigo.

"Que mi cuerpo no para de notar, que tu alma conmigo siempre está

y que nunca de mí se apartará.

Qué bonito sentir que estás aquí, junto a mí."

(4)

(5)

Í NDICE GENERAL

Índice general iii

Índice de figuras v

Acrónimos vii

Resumen xi

1 Introducción 1

1.1 Motivación . . . 1

1.2 GoodRobot . . . 1

1.3 El proyecto: Glyphstock . . . 2

1.3.1 El proceso de negocio . . . 2

1.3.2 Glyphstock, complementario al Servicio Cloud . . . 4

1.4 La aplicación cliente como objetivo . . . 5

1.4.1 Funcionalidades de GlyphstockApp . . . 6

2 Estado del arte 11 2.1 Tecnología anterior . . . 11

2.2 La nueva propuesta . . . 12

2.2.1 Polyonic, donde se unen Ionic y Electron . . . 12

3 Estructura de la aplicación cliente 17 3.1 Componentes . . . 17

3.2 Páginas . . . 21

3.3 Proveedores . . . 22

3.4 El controlador de la aplicación . . . 25

3.4.1 ipcMain . . . 26

3.4.2 ipcRenderer . . . 26

4 Principios a tener en cuenta antes del desarrollo 29 4.1 DRY - (Don’t repeat yourself ) . . . 29

4.2 Patrones de diseño . . . 29

4.2.1 El patrón de diseño:Singleton . . . 31

4.2.2 El patrón de diseño:Factory Method . . . 32

4.2.3 El patrón de diseño:Command . . . 33

4.3 El mal uso de la Herencia. Herencia vs Composición . . . 35

4.4 Filosofía KISS . . . 38

(6)

4.5 Documentación . . . 39

5 Módulos desarrollados de la aplicación cliente 41 5.1 Internacionalización de la aplicación . . . 41

5.2 Proveedores de datos del servidor . . . 42

5.3 Autenticación de usuario . . . 43

5.4 Subida de archivos . . . 45

5.4.1 Escritorio . . . 46

6 Conclusiones 51

Bibliografía 53

(7)

Í NDICE DE FIGURAS

1.1 Logo GoodRobot . . . 2

1.2 Logo Glyphstock . . . 3

1.3 Diagrama del proceso del servicio . . . 4

1.4 Diagrama general de la recopilación de archivos desde GlyphtockApp . . . 5

1.5 GlyphtockApp: Los archivadores . . . 7

1.6 GlyphtockApp: Las carpetas . . . 8

1.7 GlyphtockApp: Perfil de usuario . . . 8

1.8 GlyphtockApp: Búsqueda de archivadores . . . 9

1.9 GlyphtockApp: Subida de archivos . . . 10

2.1 Two-Way DataBinding . . . 14

2.2 Modelo de shell de aplicación . . . 16

3.1 Comunicación entre las partes de un componente. . . 18

3.2 Ejemplo de componente hijo y componente padre. . . 19

3.3 Comunicación entre proveedores y componentes. . . 24

3.4 Componentes de Electron. . . 25

3.5 Electron y sus dos tipos de procesos. . . 26

3.6 Comunicación entre ipcMain y ipcRenderer. . . 27

3.7 Tareas principales de los principales procesos de Electron. . . 27

4.1 Los 23 Patrones de Diseño Software (C)Creacional (S)Estructural (B)De comportamiento . . . 31

4.2 Ejemplo del patrón de diseñoSingleton . . . 32

4.3 Ejemplo del patrón de diseñoFactory Method. . . 33

4.4 Ejemplo del patrón de diseñoCommand. . . 34

4.5 Ejemplo de herencia sobre el tipo abstracto Bicicleta. . . 36

4.6 Herencia vs Composición . . . 38

5.1 Secciones de los archivos JSON que forman parte del sistema de traducción de la aplicación . . . 42

5.2 Comunicación entre componente y proveedor de datos. . . 43

5.3 Proceso de autenticación de usuario. . . 44

5.4 Página de subida/visualización de los archivos del archivador digital. . . . 45

5.5 Diagrama de flujo de la presubida de archivos arrastrados. . . 48

5.6 Diagrama de flujo de la subida de archivos almacenados en la base de datos local. . . 49

(8)

(9)

A ^CRÓNIMOS

GINF Grado en Ingeniería Informática.

Startup Término utilizado en el mundo empresarial aplicado a empresas que bus- can arrancar, emprender o montar un nuevo negocio. Generalmente se trata de empresas emergentes apoyadas en la tecnología.

TIC Tecnologías de la Información y Comunicación

spin-outs Es el proceso por el cual una empresa secciona parte de sus líneas de negocio o departamentos para la creación de una nueva empresa. Esto supone una nueva fuente de financiación para la empresa matriz.

ciberseguridad Área, relacionada con la informática y la telemática, enfocada a la protección de la infraestructura computacional, todo lo relacionado con esta y, especialmente, la información contenida en una computadora o circulante a través de las redes de computadoras.

óptico Disco óptico que almacena mayor información que los discos magnéticos. Los discos opticos pueden ser grabados mediante óptica digital o magneto-óptica digital. Son discos ópticos los CDs, DVDs, los Blu-ray, HD-DVD, etc. La informa- ción se almacena en el disco compacto o compact disc (CD) en forma digital (lógica binaria). Sobre una capa de vidrio y sustancias plásticas se graban, con un haz de láser, los agujeros o marcas que posteriormente detectará la unidad lectora. La lectora, mediante técnicas ópticas, con un rayo láser de baja potencia, garantiza que no va a sufrir ningún daño físico. Gracias a la precisión de esta técnica, se permiten disponer grandes cantidades de información en un espacio muy reducido.

briefing Documento conciso, claro y no extenso sobre el cliente.

cifrado Proceso por el que una información legible se transforma mediante un algorit- mo (llamado cifra) en información ilegible, llamada criptograma o secreto. Esta información ilegible se puede enviar a un destinatario con muchos menos riesgos de ser leída por terceras partes. El destinatario puede volver a hacer legible la información, descifrarla, introduciendo la clave del cifrado.

API Application Programming Interface— Interfaz de Programación de Aplicaciones

—

PyME Pequeña y Mediana Empresa.

(10)

cloud Paradigma que permite ofrecer servicios de computación a través de una red, que normalmente es Internet.

WORM Write Once Read Many— Escribe una vez y lee muchas veces — AES Advanced Encryption Standard— Estándar de Cifrado Avanzado —

Front-end Especialidad para el desarrollo de software, que trabaja la interfaz y hace que el usuario pueda interactuar con nuestra web o aplicación.

caché Habitualmente, se entiende caché como la memoria de acceso rápido de un procesador. En este documento, se habla de caché del navegador. Esta almacena todo tipo de datos — imágenes, descripciones, nombres, códigos, etc. — en el navegador y permite un acceso rápido con tiempos de lectura reducidos.

HTML HyperText Markup Language— lenguaje de marcas de hipertexto —

frameworks Entornos o marcos de trabajo tecnológico de asistencia definida, normalmente, con artefactos o módulos concretos de software, que puede servir de base para la organización y desarrollo de software. Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto.

shell de aplicación Una arquitectura de shell de aplicación (o shell de app) es una forma de crear unaProgressive Web Appque se carga al instante y de manera confiable en el dispositivo del usuario, en forma similar a lo que se puede ver en las apps nativas. La "shell"de app es la mínima cantidad de HTML, CSS y JavaScript requeridos para activar la interfaz de usuario, y cuando se almacena en caché sin conexión puede asegurar un rendimiento instantáneo y de alta confiabilidad para los usuarios en las visitas repetidas. De esta manera, la shell de la app no se carga desde la red en cada visita del usuario. Solo se carga el contenido necesario de la red.

AngularJS Es un framework de JavaScript de código abierto, mantenido por Google, que se utiliza para crear y mantener aplicaciones web de una sola página. Su objetivo es aumentar las aplicaciones basadas en navegador con capacidad de Modelo Vista Controlador (MVC), en un esfuerzo para hacer que el desarrollo y las pruebas sean más fáciles.

decorador Un decorador es una herramienta que se permite en algunos lenguajes de programación y que está disponible en AngularJS. Generalmente un decorador, es una implementación de un patrón de diseño de software que en sí sirve para extender una función mediante otra función, pero sin tocar aquella original, que se está extendiendo. En AngularJS, permite agregar funcionalidad extra a servicios que se hayan definido anteriormente. En tiempo de ejecución, se van a agregar propiedades o métodos a determinado servicio que se quiere extender.

SOLID En ingeniería de software, SOLID —Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion— Son principios de programación de software orientado a objetos.

(11)

ix

tokens Un token de sesión es un identificador único que está generado y enviado desde un servidor a un cliente para identificar la sesión de interacción actual. El cliente envía el token como una cookie HTTP y/o lo envía como parámetro en GET o POST. La razón para utilizar tokens de sesión es que el cliente sólo tiene que manejar el identificador — toda la información de sesión está almacenada en el servidor — enlazada a aquel identificador.

JSON Acrónimo deJavaScript Object Notation— Objeto de Notación Javascript —, es un formato de texto ligero para el intercambio de datos. JSON es un subcon- junto de la notación literal de objetos de JavaScript aunque hoy, debido a su amplia adopción como alternativa a XML, se considera un formato de lenguaje independiente.

aplicaciones híbridas Las aplicaciones móviles híbridas son una combinación de tec- nologías web como HTML, CSS y JavaScript, que no son ni aplicaciones móviles verdaderamente nativas, porque consisten en unWebViewejecutado dentro de un contenedor nativo, ni tampoco están basadas en Web, porque se empaque- tan como aplicaciones para distribución y tienen acceso a las APIs nativas del dispositivo.

metadatos Se refiere a un grupo de datos que describen el contenido informativo de un objeto.

SQLite SQLite es un sistema de gestión de bases de datos relacional. A diferencia de los sistemas de gestión de bases de datos cliente-servidor, el motor de SQLite no es un proceso independiente con el que el programa principal se comunica.

En lugar de eso, la biblioteca SQLite se enlaza con el programa pasando a ser parte integral del mismo. El programa utiliza la funcionalidad de SQLite a través de llamadas simples a subrutinas y funciones. El conjunto de la base de datos (definiciones, tablas, índices, y los propios datos), son guardados como un sólo fichero estándar en la máquina host.

(12)

(13)

R ^ESUMEN

A lo largo de mis estudios en la Universidad siempre tenía en mente cómo podría ser mi Trabajo de Fin de Grado, el tema a tratar y con quién lo realizaría. Tuve algunas ideas e incluso había hablado con algún profesor. Pero, finalmente, durante el verano anterior a mi último año académico empecé como estudiante en prácticas en Glyphstock. Allí mejoraba día tras día, mis habilidades y conocimientos informáticos, trabajando en el desarrollo de una aplicación cliente centrada en la subida de archivos y recuperación de estos mediante dispositivo físico, en una empresa que vende seguridad. Entonces, pensé que el Trabajo de Final de Grado podía abarcar la realización de la aplicación GlyphstockApp.

Mi objetivo principal durante el período de prácticas era implementar la subida de archivos, las gestiones de los archivadores, carpetas y recuperación, además de incorporar el diseño de una empresa externa a Glyphstock.

Este documento sigue la estructura habitual utilizada en los trabajos de fin de grado.

Así pues, mediante una introducción se expone el contexto empresarial en el que se ha desarrollado la aplicación, el tema del proyecto y los objetivos. En el siguiente punto se presenta el estado, en aquel entonces, de la aplicación antigua y la tecnología que se utilizó durante su nueva implementación. Después, en el apartado de estructura de la aplicación cliente se exponen las diferentes partes que forman la estructura del proyecto y el controlador de la aplicación. A continuación, se sigue informando al lector de algunos de los principios o patrones que se han seguido a lo largo de todo el desarrollo. Posteriormente, se inicia el apartado de descripción detallada de algunos de los módulos desarrollados y su funcionamiento general. Llegado a este punto, el lector tendrá en mente una idea de todo en lo que me he podido embarcar y lo que he podido aprender. Finalmente, se exponen las conclusiones a las que se ha llegado tras desarrollar y realizar el presente documento.

Aclarar al lector, que los textos de las figuras que aparecen en este documento se encuentran en español. Aunque, existen figuras que aparecen en inglés debido a que se ha querido conservar la oficialidad del origen el cual provienen. Por último, decir que no se han expuesto detalles del desarrollo en código por confidencialidad y porque me ha parecido más interesante exponer las herramientas, técnicas, formas y experiencias que han aparecido a lo largo del proyecto.

(14)

(15)

C

APÍTULO

1

I NTRODUCCIÓN

1.1 Motivación

Durante el penúltimo año de mis estudios de GINF en la Universidad, decidí comenzar mi primer contacto con el mundo laboral a través de la realización de unas prácticas en una empresa pequeña, una Startup llamadaGoodRobot, que se decidió arriesgar y embarcarse en una idea bastante interesante y hasta ahora no vista.

Nunca había tenido clara mi especialización, y la Universidad tampoco es que te aclare mucho las ideas. El mero hecho de que gran parte del sector de las Tecnologías de la Información y Comunicación (TIC) en las Islas Baleares se dedica al turismo y que esta empresa me ofrecía un revés, algo totalmente diferente, fue lo que me hizo decantarme por ella.

Mi periodo de prácticas ha sido completamente satisfactorio, he aprendido mucho como profesional y he crecido como persona. Aquí lo vuelvo a agradecer porque no siempre todo el mundo tiene esta gran oportunidad, e incluso de pertenecer actualmente a la plantilla de trabajadores.

1.2 GoodRobot

GoodRobot[1] es una empresa dedicada al desarrollo de nueva y alta tecnología en los campos de las Tecnologías de la Información y Comunicación (TIC), robótica y energía.

Su fortaleza principal es un equipo internacional de profesionales con el apoyo de innovadoras metodologías de I+D y transferencia de tecnología, desde lainnovación disruptiva[2] hasta el modelo comercial y el mercado.

Complementa estas actividades con contratos de investigación específicos con universidades y escuelas técnicas de toda Europa. Diseña y planifica todas sus propias empresas, que se transforman después de una validación exhaustiva enspin-outscon mayor valor agregado para los accionistas.

(16)

Figura 1.1: Logo GoodRobot Fuente: http://goodrobot.es/

Su portafolio de proyectos abarca desde ciberseguridad hasta energías renovables, con una característica común:

• Soluciones rentables, viables e innovadoras para nuevos nichos de mercado.

La trayectoria de las empresas exitosas del equipo fundador garantiza la calidad de las oportunidades comerciales generadas porGoodRobot. Además, su red comercial cubre la mayor parte de Europa (España, Alemania, Reino Unido e Italia) y EE. UU.

Una de las empresas de GoodRobot, en la que se va a centrar este trabajo, esGlyphs- tock. Una compañía que comparte nombre con su proyecto, el cual, ofrece el servicio del buen recaudo de los datos del usuario durante importantes períodos de tiempo.

Para entender qué es Glyphstock, quizás se ha hecho una definición muy escueta pero el lector podrá tomar mayor conciencia de lo que trata el proyecto en los siguientes capítulos.

1.3 El proyecto: Glyphstock

Glyphstock[3], un nuevo proyecto en el portafolio de GoodRobot, es el primer servicio de almacenamiento de datos en disco óptico. Estos discos se cifran y custodian indivi- dualmente durante los años que sea necesario, con disponibilidad para ser recuperados en cualquier momento. Todo gracias a un sistema robótico de alta seguridad certificada.

Glyphstockse ofrece a:

• Grandes empresas[4]

• PyME y autónomos[5]

• Particulares[6]

1.3.1 El proceso de negocio

Todo empieza, con elanálisis. Se cita a la empresa cliente, se cierra una reunión para tomar briefing[7] del cliente y se prepara una propuesta adaptada a sus necesidades.

Se atienden sus dudas y se le explica todo en detalle realizando una demostración en tiempo real. Previo análisis detallado de las necesidades de cada empresa, se le realiza un presupuesto. Si el usuario final es PyME, autónomo o particular este paso del proceso no es necesario.

(17)

1.3. El proyecto: Glyphstock

Figura 1.2: Logo Glyphstock Fuente: https://www.glyphstock.com/es/

Se procede a larecopilaciónde los archivos del cliente. El corazón del servicio es el archivo físico robotizadode medios ópticos desarrollado porGlyphstock. Los armarios de almacenaje de datos, que Glyphstock posee, albergan los medios ópticos de alta densidad, que a su vez contienen los datos a custodiar del servicioGlyphstock. La gran empresa, entidad cliente de Glyphstock, debe trasladar de forma ordenada los datos que desee preservar y para ello, si es necesario, se dispone de un servicio de recogida in situ. En los demás casos, se hace uso de laaplicación cliente.

A continuación, se lleva a cabo elcifrado de datos. Toda comunicación desde el cliente a la API de los dispositivos ópticos robotizados se realiza mediante canales de transporte de datos cifrados.Glyphstockofrece para datos masivos, la integración automatizada a medida de su servicio en procesos informáticos de la empresa cliente.

Por ejemplo, mediante el acceso de programas existentes, en las empresas cliente, a la API del almacén de los dispositivos ópticos robotizados. Para una cantidad menor de datos, todos los archivos pasan una fase previa al cifrado, la cual no se puede detallar en este documento. Una vez pasada esta fase, se cifran con los estándares más altos de cifrado de la industria y el usuario es capaz de descifrar sus propios datos gracias a la contraseña creada.

En el penúltimo paso del proceso,almacenajeoffline, entra en juego la esencia del servicio que es elarchivo físico robotizadode medios ópticos. El proceso de grabación, almacenajeoffliney recuperación de datos es automatizado y cabe la posibilidad, según la modalidad contratada, de guardar más de una copia de los datos en medios ópticos geográficamente deslocalizados.

Por último,la recuperación. Los archivos son recuperados en copias físicas, incluso se pueden hacer envíos a otras personas o entidades, con la garantía de que los datos

(18)

viajen cifrados y solo se puedan visualizar con la clave del cliente.

Figura 1.3: Diagrama del proceso del servicio Fuente: Propia

1.3.2 Glyphstock, complementario al Servicio Cloud

Glyphstockno es un serviciocloud, sino todo lo contrario, un serviciooff-line. Es un almacén de datos a largo plazo dónde se guardan y custodian los datos del cliente en soporte físico, fuera de línea y cifrados.Glyphstockes un producto complementario a la nube, no sustitutivo, ya que sigue siendo muy útil para todos los datos que están

“vivos” — alta frecuencia de lectura y escritura — la manipulación o consulta al instante.

No se debe olvidar que los servicioscloudson susceptibles de ataques y pérdidas de información, por esta razón Glyphstock es una buena opción.

EnGlyphstockse utiliza una tecnología óptica para el almacenaje seguro. Mediante el almacenaje óptico se garantiza la continuidad de los datos. Estos son grabados en láser y tienen una durabilidad superior a aquellos que se guardan en soportes magnéticos o digitales actuales. Si se quiere garantizar la perdurabilidad de los datos, estos, a día de hoy, se deben guardar en medios ópticos. No está de más saber que, los medios ópticos sonWrite Once Read Many— Escribe una vez y lee muchas veces

— (WORM), lo que garantiza que no sean manipulables ni borrables.

(19)

1.4. La aplicación cliente como objetivo

No existe ningún instante en el que los datos se encuentren desprotegidos. Los datos que se remiten están protegidos durante todo el proceso de almacenamiento.

Una vez se encuentran en el almacén definitivo permanecen grabados durante décadas en el medio más seguro que se puede ofrecer a día de hoy. Durante todo el proceso de traslado de datos, así como en el almacén definitivo y sus copias redundantes, se usan canales ytécnicas de cifrado AES de 256 bit[8], lo que garantiza la confidencialidad de los mismos.

1.4 La aplicación cliente como objetivo

Figura 1.4: Diagrama general de la recopilación de archivos desde GlyphtockApp Fuente: Propia

Una manera de transferir los datos y almacenarlos offline de forma confidencial y completamente segura es con una de las formas más demandadas hoy en día, una aplicación cliente. Por lo tanto, ese era el objetivo, desarrollar desde cero una aplica- ción que facilite al cliente la subida de archivos, la cual a partir de ahora se llamará GlyphstockApp.

Se aclara que no se realiza una especificación formal de requisitos por los siguientes motivos:

• El proyecto no ha seguido el modelo clásico de desarrollo basado en el proceso encascada[9]. Lo que se ha hecho, es un desarrollo de tipo incremental-ágil, sin adaptarse a ninguna metodología concreta — ya sea SCRUM, XP, etc. —, ya que solo existen cuatro desarrolladores en la empresa y tan solo uno de ellos dedicado alFront-end.

(20)

• Se ha preferido focalizar en la exposición de los módulos desarrollados en sí, como producto final, haciendo hincapié en sus principales aspectos.

Pese a los puntos anteriores, en este capítulo se expone la descripción de las diferentes funcionalidades deGlyphstockApp.

1.4.1 Funcionalidades de GlyphstockApp

Cada uno los módulos a implementar, debía contener su respectiva lógica con el fin de establecer una comunicación bidireccional con el servidor para proveer/enviar datos a/desde la aplicación. Estos módulos suelen ser llamadosservicios, proveedores o mó- dulos de lógica de negocioy, a parte de realizar lo que se ha comentado anteriormente, también interactúan con distintas partes de la aplicación, los llamadosComponentes.

En el capítulo 3, esto se explica en detalle.

A continuación, se listan los distintos módulos que debían de implementarse en la aplicación:

• Gestión de archivadores, grupos de archivadores y archivos.

• Gestión de contactos y recuperación de copias.

• Autenticación de usuario.

• Internacionalización, resumen de estadísticas y pedidos.

Para favorecer la lectura, se pueden visualizar algunas de las capturas de la aplicación.

Los archivadores.Un archivador tiene la función de almacenar archivos del usuario.

Es la representación digital del disco físico que el usuario tiene la opción de recuperar.

Un archivador tiene la opción de cerrarse, lo que esto indica que el usuario no podrá tener la opción de subir más archivos de los que ya contiene el archivador. Los archivadores que se encuentran cerrados son los que el usuario puede recuperar. Mientras el archivador permanece abierto, se puede modificar cualquier característica de este, como por ejemplo la información que lo define, borrar archivos, compartir/descompartir con otro usuario e incluso el mismo archivador puede eliminarse.

Las carpetas.Para que el lector entienda lo que es una carpeta, en el contexto de esta aplicación, primero es necesario explicar qué es una dirección de recuperación.

Una dirección de recuperación, es la dirección física de envío de la recuperación del archivador que se ha solicitado mediante la aplicación. Sabiendo esto, una carpeta es un agrupador de archivadores, que contiene las direcciones destino del envío de la re- cuperación de cualquiera de los archivadores que contiene esa carpeta. Es decir, todos los archivadores que pertenezcan a una misma carpeta tendrán las mismas direcciones de envío. Por lo tanto, en caso de que el usuario desee distribuir varias recuperaciones, una carpeta, antes de proceder a la recuperación, siempre tiene que tener asignadas las direcciones de envío. A la hora de la recuperación de un archivador no hace falta indicar o ingresar ninguna dirección nueva. Se hace esto, para poder tener mejor or- ganizados los archivadores y automatizadas las distribuciones de las recuperaciones en las distintas direcciones de envío asignadas. En caso de que el usuario no desee asignar ninguna dirección de recuperación a la carpeta, la recuperación será enviada a la dirección de recuperación que tiene asignada el usuario en su perfil.

(21)

Figura 1.5: GlyphtockApp: Los archivadores Fuente: Propia

Los contactos.Esta aplicación no pretende tener una agenda de contactos como la que podemos encontrar en el dispositivo móvil. Pero si es bastante útil cuando el propietario de un archivador desea compartir ese archivador con otros usuarios, para que estos también puedan subir sus archivos, y tener las direcciones de e-mail al instante.

Las direcciones.El usuario tiene que tener asignada una dirección de envío por defecto para cuando solicite las recuperaciones de los distintos archivadores. Puede existir más de una dirección pero en el momento de la recuperación se debe tener una asignada por defecto. Entonces, se debe realizar una gestión de las posibles direcciones de envío de la recuperación.

El perfil.El usuario también tiene que poder gestionar su cuenta. Por lo tanto, tiene que tener la posibilidad de editar su contraseña, nombre o idioma, características comunes que se pueden encontrar en otras famosas aplicaciones. El usuario puede tener acceso a un breve resumen informativo de todas las características y acciones que realiza en su cuenta, como el número de archivadores y carpetas creados, quota contratada, espacio utilizado y lista de transacciones de los pedidos de las recuperaciones, donde puede revisar el estado y el coste.

(22)

Figura 1.6: GlyphtockApp: Las carpetas Fuente: Propia

Figura 1.7: GlyphtockApp: Perfil de usuario Fuente: Propia

(23)

La búsqueda.Con el uso a largo plazo de la aplicación, el usuario puede acumular un número lo suficientemente elevado de archivadores como para no poder recordar en qué carpeta está almacenado el archivador al que intenta acceder, navegando por la página de inicio en la aplicación. He aquí la necesidad de una página de búsqueda de archivadores. Esta página de búsqueda muestra al usuario en todo momento, todos lo archivadores que estén relacionados con las entradas de los distintos filtros de búsque- da que existen en la página. Estos filtros son filtro por nombre, filtro por descripción, orden alfabético, orden cronológico y orden de cierre. También, puede ser cómodo para el usuario cambiar la vista de los archivadores entre lista y cuadrícula. En base razones de usabilidad, sobre el posicionamiento de botones en la interfaz, si el usuario desea proceder a solicitar alguna recuperación de algún o algunos archivadores, a través de la página de búsqueda también es posible.

Figura 1.8: GlyphtockApp: Búsqueda de archivadores Fuente: Propia

Los archivos.Una vez el usuario se posiciona dentro de la página de una archivador

(24)

determinado, este puede encontrarse con la interfaz de subida de subida de archivos.

Los archivos se pueden gestionar de manera que se pueden subir nuevos archivos o los ya subidos se pueden eliminar, pero nunca se puede modificar el contenido de los archivos. Esta página que muestra en detalle el contenido de un archivador es principalmente un visualizador de archivos subidos. El contenido de un archivador que se encuentra cerrado no se puede gestionar, es decir no se pueden ni subir más archivos ni eliminar, solo se puede navegar entre en contenido del visualizador de la lista de archivos y directorios del archivador.

Figura 1.9: GlyphtockApp: Subida de archivos Fuente: Propia

(25)

C

APÍTULO

2

E STADO DEL ARTE

En este capítulo se expone cuál era la situación inicial de la aplicación y qué factores eran los más importantes a la hora de resolver el problema planteado. Además, se exponen las diferentes tecnologías y herramientas que se han utilizado para llegar a la solución deseada.

2.1 Tecnología anterior

Cuando aterricé en la empresa/proyectoGlyphstock, esta ya tenía tres años de vida. En esos tres años se dio paso a la larga construcción del patentado sistema de archivos físicos robotizado, comentado en el Capítulo 1.3, la API de los robots de grabación y la aplicación cliente implementada en el lenguaje de programación Java. Los dos últimos módulos del proyecto requerían bastantes mejoras sobretodo por la evolución constante de la tecnología y por los nuevos requisitos de los inversores en el proyecto.

No se pueden explicar, en el documento presente, cada una de las mejoras realiza- das en cada uno de los módulos, ya que, la extensión de este sería excesiva. Por lo tanto, se va profundizar en el módulo del proyecto que abarca la aplicación cliente.

La aplicación cliente anterior, en Java, carecía de algunos aspectos tan fundamen- tales para su supervivencia hoy en día, que se tomó la decisión de que era más fácil y rápido implementar una nueva aplicación desde cero que mejorar la existente. Los motivos del cambio fueron los siguientes:

• Sin la Java Virtual Machine de Java, la aplicación no puede ser ejecutada.

• De ejecución lenta.

• La subida de archivos se cancelaba al cerrar la aplicación.

• Carente de nuevos requisitos exigidos por los inversores.

(26)

2.2 La nueva propuesta

Posiblemente, el equipo pudiera tener entre manos algunas soluciones alternativas, pero esto no se me expuso. Simplemente se me dijo que, se buscaba una aplicación universal. Esa era la nueva propuesta, implementar la aplicación una vez, mediante tecnologías web y desplegarla en todas partes. Pero... ¿cómo?. Una buena solución eraPolyonic. Cuando se trabaja en equipos pequeños que crean aplicaciones web y móviles, a los nuevos miembros del equipo les resulta difícil y lento captar las diferentes tecnologías para cada plataforma. Pero si no es suficiente se pueden plantear las siguientes preguntas:

• ¿Hay alguna forma de ejecutar esta aplicación móvil en el escritorio?

• ¿Se puede almacenar en la caché del navegador, información para trabajar de forma offline?

• ¿Se puede tener una aplicación universal que se pueda ejecutar en el escritorio, móvil y la web?

Estas preguntas demuestran las limitaciones del navegador para la edición y el almacenamiento en caché sin conexión y la sobrecarga de tener que aprender a tratar con numerosas librerías y frameworks para cada plataforma. Existe un paquete que se puede utilizar para desarrollar cualquier aplicación que se necesite y ese esPolyonic.

2.2.1 Polyonic, donde se unen Ionic y Electron

Polyonic es la combinación de Electron Framework[10] e Ionic Framework[11], un shell de aplicación[12] que es muy útil para crear aplicaciones web, aplicaciones web móviles progresivas, aplicaciones móviles nativas y aplicaciones de escritorio. Según la documentación oficial deIonic Framework Core Concepts:

Ionic currently requires Angular in order to work at its full potential. While you can still use the CSS portion of the framework, you’ll miss out on powerful UI interactions, gestures, animations, and other things. In the future, Ionic plans to become more agnostic in order to support a broader variety of JavaScript frameworks.

Por lo tanto, Ionic deja claro que actualmente requiereAngularJSpara sacar el mayor rendimiento. Por esta razón, a continuación se explica el papel que juega AngularJS en un proyecto deIonic Framework.

Ionic utiliza AngularJS con el fin de crear un marco de trabajo más adecuado para desarrollar aplicaciones ricas y robustas. Ionic no sólo se ve bien, sino que su arquitectura central es robusta y seria para el desarrollo de aplicaciones. Trabaja perfectamente con AngularJS. Básicamente, cuando se está usando Ionic, realmente se está construyendo una aplicación de AngularJS con un montón de módulos adicionales añadidos, por parte de Ionic, para facilitar la creación de aplicaciones móviles con Angular.

AngularJS es unframeworkde JavaScript creado y mantenido por Google que es utilizado para la creación de aplicaciones web siguiendo el patrónModelo Vista Con- trolador, capacitado para extender los ficheros HTML añadiendo nuevas etiquetas y

(27)

2.2. La nueva propuesta

atributos que cumplirán con funciones específicas ya definidas o programadas por el desarrollador. Según se empieza con AngularJS, se aprenden diferentes conceptos como son módulos, controladores, directivas, filtros, etc. . . que permiten realizar muchas funcionalidades con un menor esfuerzo, así como organizar el código y poder mante- nerlo limpio y entendible. Se destaca la facilidad con la que se referencian los datos que se tienen en los modelos a las vistas, así como la organización del funcionamiento de cada vista con su propio controlador. Se puede separar el código en módulos para facilitar su organización e incluso poder exportarlo a otros proyectos.

Como se ha comentado, AngularJS es unframeworkque utiliza el patrón de diseño Modelo Vista Controlador. Un MVC, es un patrón de diseño que separa los datos, la lógica y las interfaces de usuario. Como su nombre indica, está separado en tres componentes: Modelo, Vista y Controlador. Está basado en la ideología de separación de conceptos y cumple perfectamente con los objetivos de los patrones de diseño que se comentan en el capítulo 4.2.

• Modelo:Es la capa encargada de los datos, es decir, la que se encarga de hacer peticiones a las bases de datos para enviar o recibir información. Estas bases de datos pueden estar alojadas de forma local en la aplicación o de forma remota en un servidor externo.

• Vista:Se trata del código que permite presentar los datos que el modelo proporciona. Se entiende que en una aplicación, es el código HTML que permite mostrar al usuario la salida de los datos procesados.

• Controlador:Es la capa que sirve de enlace entre la vista y el modelo. Envía ordenes al modelo para actualizar su estado, y a la vista correspondiente para cambiar su presentación.

En AngularJS, además ocurre que la iteracción entre la vista y el controlador se produce en los dos sentidos, el controlador muestra los datos en la vista y si en la vista hay un cambio de datos, se actualiza el modelo automáticamente. Lo que se viene a llamarMVVM— Modelo Vista Vista Modelo —. Esto se procude mediante los eventos de Angular llamadosEventBindingyPropertyBindingcomo se puede ver en la figura 3.1.

(28)

Este suceso es el famosoTwo-Way DataBindingen AngularJS.

Figura 2.1: Two-Way DataBinding

Fuente: http://www.w3big.com/es/angularjs2/angularjs2-architecture.html Uno de los principales valores de Angular es que abstrae al desarrollador de tener que implementar la lógica asociada a insertar y actualizar valores en el HTML y convertir las respuestas de usuario (inputs, clicks, etc) en acciones concretas. Escribir toda esa lógica a mano es tedioso y propenso a errores, y Angular lo resuelve gracias alTwo- Way DataBinding. Para exponer los diferentes tipos deDataBinding que existen en AngularJS, el lector se debe centrar en el siguiente ejemplo:

<div>{{contacto.nombre}}</div>

Actualmente, AngularJS dispone de 4 formas deDataBinding:

• Interpolación: (Hacia el DOM)Al hacercontacto.nombre, Angular se encarga de insertar el valor de esa propiedad entre las etiquetas<div>donde se ha definido.

Es decir, evalúacontacto.nombree introduce su resultado en el DOM.

• Property binding: (Hacia el DOM)Al hacer[opcion1]="textoOpcion1", Angular está pasando el objetotextoOpcion1del componente padre a la propiedadop- cion1del componente hijo, en este caso, por ejemplo, el componente es un menú.

Puede leer sobre el concepto de componente en capítulo 3.1.

(29)

2.2. La nueva propuesta

• Event binding: (Desde el DOM)Al hacer(click)="mostrarMensaje($event)", se indica a Angular que cuando se produzca un evento clicksobre esa etiqueta

<div>, llame al métodomostrarMensajedel componente, pasando como atributo el evento presente en ese contexto.

• Two-way binding: (Desde/Hacia el DOM)Un caso importante es elbindingbi- direccional, que combinaevent bindingyproperty binding. En este caso la pro- piedademaildel objetousuariose actualiza siusuario.emailse ve afectado por un evento de entrada de texto de la componenteinput. Así pues, siusuario.email cambia su valor, el texto que tiene la componenteinputen la interfaz se actualiza.

Una vez se ha puesto en contexto al lector de lo que es AngularJS y saber que es la base Ionic Framework, ya puede continuar con la exposición del proyecto.

Este proyecto, combina Electron con Ionic 3. Una aplicación que se puede ejecutar en escritorio (macOS, Windows y Linux), navegador o dispositivos móviles (iOS, Android y Windows Phone). Se puede usar esta aplicación para compilar y ejecutar en una o incluso todas estas plataformas. En el capítulo 3.4, se hablará del papel de Electron en esta aplicación.

Lasprogressive web apps— aplicaciones web progresivas —[13], es un término que se da a una nueva generación de aplicaciones que incrementan su funcionalidad, conforme las capacidades del dispositivo en el que se ejecutan, incrementan, de ahí la palabraprogresiva. La siguiente parte del nombreweb, hace referencia a que se construyen utilizando estándares de desarrollo web, algunos ya conocidos como HTML, CSS y JavaScript; y una nueva generación de APIs de JavaScript. La parte finalappes porque las Progressive Web Apps se comportan como aplicaciones web nativas, pero usan tecnologías web.

Por otro lado, una arquitectura deshell de aplicaciónes una forma de crear una aplicación web progresiva que se carga al instante y de manera confiable en el dispositivo del usuario, en forma similar a lo que se ve en las apps nativas. La shell de app es la mínima cantidad de HTML, CSS y JavaScript requeridos para activar la interfaz de usuario, y cuando se almacena en caché sin conexión puede asegurar un rendimiento instantáneo. De esta manera, la shell de la app no se carga desde la red en cada visita del usuario. Solo se carga el contenido necesario de la red.

(30)

Figura 2.2: Modelo de shell de aplicación

Fuente: https://developers.google.com/web/progressive-web-apps/

En otras palabras, la shell de app es similar al paquete de código que se publicaría en una tienda de apps al compilar una app nativa. Es el esqueleto de la interfaz de usuario y contiene los componentes principales necesarios para poner en marcha la app, pero no contiene los datos. Gracias al proyecto Polyonic nacióGlyphstockAppuna aplicación web de móvil y escritorio progresiva multiplataforma.

(31)

C

APÍTULO

3

E STRUCTURA DE L A APLICACIÓN CLIENTE

Este capítulo va a aclarar al lector cuál es la estructura del código del proyecto de la aplicación cliente, contando con la estructura base que AngularJS y el modelo de páginas de Ionic Framework aportan. Como se ha visto, AngularJS se basa en el patrón de diseñoMVCy además, la organización en módulos del código de un proyecto tiene muchas ventajas, y es beneficiosa para futuros cambios o nuevos requisitos, ya sean de diseño o funcionales, si el destino del código es crecer además de pasar por diferentes manos.

3.1 Componentes

Las aplicaciones web construidas con la ayuda de Angular están formadas por componentes. Un componente va a controlar un trozo de interfaz de usuario o vista, como se quiera llamar. Todo lo que se puede ver en pantalla está controlado y gestionado por este tipo de elementos.

Los componentes son pequeñas partes lógicas de la aplicación que representan un elemento o sección HTML. Este elemento o sección va a estar controlado por el controlador (lógica) del componente. La lógica de un componente, que se encuentra dentro de una clase, da soporte a una vista interactuando con ella a través de una API con propiedades y métodos.

Un componente hace de mediador o controlador entre la vista, a través de la plantilla otemplateHTML, y la lógica de la aplicación donde se incluye el modelo de datos.

(32)

Figura 3.1: Comunicación entre las partes de un componente.

Fuente: https://gustavodohara.com/blogangular/agregar-componente-una-pagina- modulo-angular/

Un componente es definido usando el decorador@Component. Dentro del decorador@Component, se debe definir elselector, eltemplatey elstylerelacionados con el componente. Elselectores el identificador que va a representar el nombre de la directiva del componente, en otro componente diferente. Es decir, un componente puede integrarse dentro de otro componente, su componente padre, mediante suselector.

(33)

3.1. Componentes

Figura 3.2: Ejemplo de componente hijo y componente padre.

Fuente: https://medium.com/@yonem9/angular-c %C3 %B3mo-narices-se-anidan- componentes-3f4a7124d751

Como se puede ver en la figura 3.2, el componente padreproduct-list.component.ts ha integrado en sutemplateel componente hijostar.component.tscon su respectiva directiva que contiene su nombre de selector.product-list.component.hmtles eltemplatedel componente padre. Al integrar un componente hijo dentro de otro componente padre, el componente hijo aparecerá en la interfaz del componente padre manteniendo sus propias funcionalidades implementadas en su controlador,star.component.ts.

Eltemplatede un componente, es el fichero HTML en el cual, el desarrollador forma la estructura, en base a etiquetas HTML y directivas de AngularJS e Ionic, del componente. Viene a ser la vista del componente. Elstyle, simplemente es el archivo de extensiónCSSque permite customizar el componente al antojo del desarrollador.

Entonces, tal y como se ha comentado la definición básica de una componente queda de la siguiente forma enTypeScript:

import { Component } from ’@angular/core’;

@Component({

selector: ’menu’,

templateUrl: ’menu.component.html’, styleUrls: [’menu.component.css’]

})

export class MenuComponent { /* LÓGICA DEL CONTROLADOR */

}

A todo esto, el lector se puede preguntar cómo se produce la comunicación entre componentes padre y componentes hijo, ¿cómo es el flujo de datos entre componen-

(34)

tes?. Es habitual crear un componente por página. Es muy común que esa página se complique. Y la solución a la complejidad es la división en componentes y reparto de responsabilidades. Cuando los datos han de guardarse y recuperarse en componentes distintos; existen dos estrategias para lograrlo. Tener un único responsable o que cada componente se encargue de sus datos. La estrategia de un controlador y múltiples presentadores ha sido la estrategia usada en la aplicación para la mayor parte de las situaciones.

Se basa en que el componente contenedor o padre sea el guardián del acceso a los datos. Mientras que los componentes presentadores o hijos recibirán la información y notificarán los cambios al controlador de su componente padre. Para eso hay que usar dos decoradores de Angular:@Input()y@Output(). Para que una vista muestre datos tiene que usarinterpolación, concepto comentado en el capítulo 2.2.1, asociada a una propiedad pública de del controlador del componente. Se supone que el controlador es el responsable de su valor. Pero también puede recibirlo desde el exterior. La novedad es hacer que lo reciba vía HTML. Por lo tanto, para pasar el valor de una propiedad, que pertenece a un componente padre, a un componente hijo, se ha de empezar por decorar con@Input()la propiedad que se quiere usar, desde fuera. Por ejemplo:

@Component({

selector: ’lista’,

templateUrl: ’lista.component.html’, styleUrls: [’lista.component.css’]

})

export class ListaComponent {

@Input() public numberOfitems = 0;

@Input() public contacts: Contact[] = [];

}

Ahora se pueden enviar datos a el componente hijo desde el HTML de su consumidor, su componente padre. Mientras tanto, en eltemplatedel componente padre:

<lista

[numberOfitems]="list_size"

[values]="father_contacts" >

</lista>

Con esta directiva indicamos que queremos consumir un componente, que pasa a ser hijo del componente principal y que se le pasan los datos que se exponen. Se está usando al componente de nivel inferior como un presentador; mientras que el contenedor superior actúa como controlador. De esta forma es fácil y queda muy limpio el envío de datos hacia abajo. Pero, ¿y hacia arriba?.

Los componentes de nivel inferior no sólo se dedican a presentar datos. También pueden crearlos, modificarlos o eliminarlos. Aunque no directamente; para hacerlo comunican el cambio requerido al controlador de nivel superior. Por ejemplo, si suponemos que el componente hijo, hasta ahora era una lista de items, el mismo componente además de mostrar los nombres de los valores de los items, permite avisar al componente padre que debe de borrarlos. En eltemplatedel componente hijo:

(35)

3.2. Páginas

<td>{{ contact.name}}</td>

<td>{{ contact.email }}</td>

<td><button (click)="deleteContact(contact)">Delete</button></td>

</tr>

Claramente, el botón con el evento(click)="deleteContact(contact)"manifiesta una intención de borrar el registro. Pero el método del componente no actúa directamente con el array de datos.Recordar al lector, que el componente padre es el responsable o guardián de los datos.En su lugar, lo que hace es emitir un evento, confiando que alguien lo reciba y actúe en consecuencia. La emisión se realiza mediante el decorador

@Output() public delete, sobre una propiedad que es un emisor de eventos tipado,new EventEmitter<Contact>(). El métododeleteContact(contact), es llamado por la vista y usa dicho emisor, para emitir la señal hacia arriba.

@Component({

selector: ’lista’,

templateUrl: ’lista.component.html’, styleUrls: [’lista.component.css’]

})

export class ListaComponent {

@Input() public numberOfitems = 0;

@Input() public contacts: Contact[] = [];

@Output() public delete = new EventEmitter<Contact>();

public deleteContact(contact: Contact) { this.delete.emit(contact);

} }

Mientras tanto, en el controlador principal del componente padre, la vista se subscribe al evento(delete). La instrucción que se ejecuta hace uso del argumento recibido en el identificador$event, estándar de Angular.

<lista

[numberOfitems]="list_size"

[values]="father_contacts" >

(delete)="deleteContact($event)"

</lista>

Finalmente, en el componente padre ya se puede operar con los datos.

3.2 Páginas

Las páginas son una característica de Ionic Framework, ya que, AngularJS tiene el objetivo de trabajar constantemente sobre la misma página actualizando el estado de sus

(36)

componentes. Las páginas son las que hacen que la aplicación móvil se comporte como una aplicación móvil nativa. Ionic se encarga de registrar y mostrar páginas específicas basadas en URL. La navegación entre páginas se realiza mediante un objeto controlador, llamadoNavController, por lo que nunca hay que interactuar directamente con el sistema de navegación entre páginas. Cuando se hacepushen la pila, de la página a la que se quiere acceder, el sistema de navegación actualiza la URL para coincidir con la ruta a esta página.

Las URL ayudan a vincular piezas específicas de contenido como una ruta de nave- gación. La URL actual se actualiza a medida que se navega, pero usamos la acción push y pop para desplazarnos. Esto hace que sea mucho más fácil manejar una complicada navegación anidada.

Pero... ¿Qué es una página?. Una página es un componente. Si, un componente. En Ionic toda sección o trozo de código que conlleve HTML es un componente, ya que forma parte de la vista. Una página es un componente que engloba a otros componentes y como buen componente que es va a estar controlado por su controlador (lógica), valga la redundancia. La lógica de la página, que se encuentra dentro de su clase, da soporte a una vista interactuando con ella a través de una API con propiedades y métodos.

(Si el lector desea aclarar el concepto de componente, este se encuentra en la sección anterior.)

3.3 Proveedores

Con Ionic, cada aplicación web que se crea está compuesta de objetos que colaboran para hacer las cosas. Estos objetos necesitan ser instanciados e inyectados, mediante el servicioinyectordel propioframework, para que la aplicación funcione. El servicio inyectorcrea los objetos, llamados proveedores — para Ionic Framework — o servicios — Para AngularJS —. Los proveedores son objetos cuya API es definida por el desarrollador que escribe el servicio o utilidad de ese proveedor y desempeñan un papel importante a la hora de proporcionar información a la aplicación y realizar tareas.

Para dar una idea de los tipos de cosas que se pueden hacer con los proveedores de servicios, estos son algunos de los servicios que se han incorporado a GlyphstockApp:

(en los siguientes items, las palabras que aparecen en negrita y en cursiva son objetos que representan a un proveedor en la aplicación)

• Datos:Se han utilizado los servicios de datos constantemente. Proporcionan los datos que la aplicación necesita para funcionar, sin que la aplicación tenga que preocuparse por cómo se obtienen esos datos — podrían almacenarse localmente o recuperarse de un servidor —. Si existen varios tipos de datos en la aplicación, incluso se pueden crear múltiples proveedores de datos, es decir:GroupProvider, TranslatorProvider, etc.

• Eventos:Este proveedor de servicio, se encarga de emitir los eventos que van sucediendo durante la ejecución de la aplicación, para ser posteriormente captu- rados y tratados por las respectivas páginas como es debido.

• Autho Autenticación:Este proveedor de servicio se encarga de mantener la sesión del usuario, actual de la aplicación, activa. Refresca lostokensde sesión,

(37)

3.3. Proveedores

ordena emitir un evento que se pueda producir a la hora del iniciar de sesión, como por ejemplo, que la contraseña o el nombre de usuario sean incorrectos, etc.

Pero... ¿cuál es el destino de la información de salida de cualquier proveedor?. Los proveedores, como se habrá podido observar, no requieren de vista pues solo manejan datos. Por lo tanto, ¿cuál es la parte, módulo o sección de la aplicación que hace de interfaz directa con el usuario? La vista, es decir, los componentes. Los proveedores se convertirán en objetos inyectados en los controladores de los componentes, donde la información será utilizada a voluntad de la página.

(38)

Figura 3.3: Comunicación entre proveedores y componentes.

Fuente: https://www.joshmorony.com/an-in-depth-explanation-of-providers-in-ionic- 2/

En AngularJS, los servicios son objetossingleton, inyectables porDependency In- jection, donde se define la lógica de negocio de la aplicación, con el objetivo de que sea reutilizable e independiente de las vistas. Un objetosingleton, es una instancia única de una clase, un patrón de diseño que permite restringir la creación de objetos pertenecientes a una clase. Gracias a este patrón de diseño, se garantiza que una clase sólo tenga una instancia y se proporciona un punto de acceso global a ella. Si se habla deDependency Injection, se puede decir brevemente que, también es un patrón de di- seño software y que trata de establecer la forma de cómo los componentes se apoderan o gestionan sus dependencias. Este patrón de diseño, no se va a exponer en detalle, ya que, el subsistema de inyectores que forman parte de AngularJS se encargan de crear componentes y resolver sus dependencias. Estos objetos, los servicios, permiten la obtención de información y tienen métodos que sirven para mantener los datos en el ciclo de vida de la aplicación, comunicándose a través de los controladores de una manera consistente.

(39)

3.4. El controlador de la aplicación

3.4 El controlador de la aplicación

Figura 3.4: Componentes de Electron.

Fuente: https://electronjs.org/

Electron es una librería de código abierto para crear aplicaciones de escritorio multiplataforma con HTML, CSS y JavaScript. Electron logra esto combinandoChromium

— proyecto de código abierto del navegador web de Google Chrome — yNode.jsen un solo tiempo de ejecución y las aplicaciones se pueden empaquetar para Mac, Windows y Linux.

Existen dos tipos de procesos disponibles en Electron. Son fundamentalmente diferentes e importantes de entender. En Electron, el proceso que ejecuta elscript maines llamado elproceso principal. Elscriptque corre en el proceso principal puede mostrar una GUI — Interfaz Gráfica de Usuario — creando páginas web. Una aplicación Electron siempre tiene un proceso principal, pero nunca más de uno.

Debido a que Electron usa Chromium para mostrar páginas web, la arquitectura multi-proceso de Chromium también es usada. Cada página web en Electron corre en su propio proceso, el cual es llamado el proceso renderizador.

En los navegadores normales, las páginas web generalmente se ejecutan en un espacio aislado y no se les permite el acceso a recursos nativos. Los usuarios de Elec- tron, sin embargo, tienen el poder de utilizar Node.js en las páginas web permitiendo interacciones inferiores de nivel de sistema operativo.

El proceso principal crea páginas web creando instancias del objetoBrowserWin- dow. Cada instancia de BrowserWindow ejecuta la página web en su propio proceso renderizador. Cuando una instancia de BrowserWindow es destruida, el proceso renderizador correspondiente también finaliza.

El proceso principal administra todas las páginas web y sus correspondientes procesos visualizadores. Cada proceso visualizador esta aislado y sólo se preocupa por la página web que se ejecuta en él.

(40)

En páginas web, llamar a APIs nativas relacionadas con la GUI no está permitido porque manejar recursos nativos de GUI en páginas web es bastante peligroso y es fácil que ocurran fugas de recursos. Si se desea realizar operaciones de GUI en una página web, el proceso renderizador de la página web debe comunicarse con el proceso principal para pedirle que realice esas operaciones.

Figura 3.5: Electron y sus dos tipos de procesos.

3.4.1 ipcMain

Se comunica de forma asíncrona desde el proceso principal a los procesos de renderizado. El móduloipcMaines una instancia de un objeto emisor de eventos. Cuando se utiliza en el proceso principal, maneja mensajes enviados al proceso de renderizado (página web). Los mensajes enviados desde el renderizador son emitidos a este módulo.

3.4.2 ipcRenderer

Se comunica de forma asíncrona desde un proceso de renderizado al proceso principal.

El móduloipcRendereres una instancia de un objeto emisor de eventos. Proporciona un par de métodos para enviar mensajes desde el proceso de renderizado (página web) al proceso principal.

(41)

3.4. El controlador de la aplicación

Figura 3.6: Comunicación entre ipcMain y ipcRenderer.

Figura 3.7: Tareas principales de los principales procesos de Electron.

(42)

(43)

C

APÍTULO

4

P RINCIPIOS A TENER EN CUENTA ANTES DEL DESARROLLO

Antes de mi periodo de prácticas en Glyphstock, no era consciente de algunos de los aspectos que he asimilado, en el equipo de desarrollo, durante la implementación de la aplicación y que han cambiado mi forma de pensar a la hora de programar. En este breve capítulo, se van a exponer algunos de los aspectos que se han tenido en cuenta antes del desarrollo de la aplicación, GlyphstockApp.

4.1 DRY - (Don’t repeat yourself )

Se conoce comúnmente con el acrónimo, DRY. El concepto, en sí mismo, se conoce desde hace mucho tiempo y se refiere a las partes más pequeñas de cualquier proyecto software.

Cuando se está construyendo un gran proyecto de software, generalmente el desarrollador puede llegar a sentirse abrumado por la complejidad general y los humanos no suelen ser buenos para manejar la complejidad; son buenos para encontrar soluciones creativas para problemas de un alcance específico. Una estrategia básica para reducir la complejidad es dividir un sistema en partes o módulos que son más útiles para lograr una funcionalidad específica.

El principio DRY establece que estos pequeños módulos solo pueden ser imple- mentados exactamente una vez en todo el sistema software.

4.2 Patrones de diseño

Un patrón de diseño es una forma reutilizable de resolver un problema común. Por muy específico que sea un problema al que se enfrente el desarrollador durante la implementación del software, probablemente que alguien se haya enfrentado a un problema tan similar en el pasado, que se pueda modelar de la misma manera.

(44)

Modelado se refiere a que la estructura de las clases que conforma la solución del problema puede estar ya inventada, porque se está resolviendo un problema común que otra gente ya ha solucionado antes. Si la forma de solucionar ese problema se puede extraer, explicar y reutilizar en múltiples ámbitos, entonces se está ante unpatrón de diseño de software.

Según el libroDesign Patterns: Elements of Reusable Object-Oriented Software[14], los patrones de diseño son descripciones de cómo interconectar clases y objetos de forma que puedan resolver un problema general de diseño dentro de un contexto determinado. Dicho de otra forma, son soluciones probadas y beneficiosas a problemas recurrentes que aparecen durante el diseño de un producto software. Existen tres tipos de patrones:

• Creacionales:Relativos a problemas relacionados con la creación de objetos.

• Estructurales:Relativos a problemas relacionados con las relaciones y dependencias estáticas entre clases y objetos.

• De Comportamiento:Relativos a problemas relacionados el comportamiento de clases y objetos en tiempo de ejecución.

Pero...¿Por qué son importantes los patrones de diseño?Los patrones de diseño, ayudan a resolver fácilmente ciertos problemas que se presentan a menudo en el diseño de software. Muchas veces, podría parecer contraproducente el uso de los patrones, ya que, aumenta el número de clases y de métodos del diseño. Sin embargo, está probado el beneficio que aporta el patrón al diseño (siempre que se usen los patrones adecuadamente) y por tanto, existen más pros que contras. Por ejemplo,el patrónStrategy, utilizado cuando se tienen varias versiones de un mismo método, hace que el desarrollador tenga que añadir una clase por cada versión del método, pero también provoca que existan menos estructuras de decisión y por tanto disminuye la complejidad del programa. Por lo tanto,se puede decir que los patrones de diseño son importantes porque ayudan a construir software más fácilmente y de mayor calidad.

(45)

4.2. Patrones de diseño

Figura 4.1: Los 23 Patrones de Diseño Software (C)Creacional (S)Estructural (B)De comportamiento

Fuente: https://www.d.umn.edu/ gshute/softeng/new/design_patterns/design_patterns.xhtml Existen unos veintitrés patrones de diseño de software. Muchos de ellos no se van a

exponer en este documento por motivos de extensión y no utilización en el desarrollo de la aplicación, pero si que se van a exponer los que se han utilizado. Los patrones de diseño de software que más se han utilizado en la aplicación, son los siguientes:

• Singleton pattern

• Factory method pattern

• Command pattern

En los subcapítulos siguientes se van a exponer los patrones utilizados.

4.2.1 El patrón de diseño:Singleton

• Propósito:Asegurar que una clase sólo tiene una instancia y proporcionar un punto global de acceso a ella.

• Motivación:Es importante que algunas clases tan solo tengan una sola instancia.

Por ejemplo, pueden haber varias impresoras en un sistema pero solo debería de existir una cola de impresión. ¿Cómo podemos asegurar que una clase tiene una sola instancia y que esa instancia es fácilmente accesible? Una buena solución, es hacer que la clase sea responsable de su instancia. La clase debe asegurarse de que no se puedan crear más instancias y debe proporcionar una forma de acceder a su instancia.

(46)

Figura 4.2: Ejemplo del patrón de diseñoSingleton Fuente: http://www.cs.unc.edu/ stotts/GOF/hires/pat3efso.htm

• Aplicabilidad:El patrónSingletonse debe usar cuando se producen los motivos siguientes,

1. Debe haber exactamente una única instancia de una clase y los clientes deben poder acceder desde un punto de acceso.

2. La instancia debería ser extensible mediante subclases y los clientes debe- rían poder usar una instancia sin modificar su código.

• Consecuencias:Los beneficios de este patrón son los siguientes,

1. Acceso controlado a la instancia:Debido a que la claseSingletonencapsula su instancia, puede tener un control de cuándo y cómo los clientes acceden a ella.

2. Reduce el número de variables:El patrónSingletonevita tener variables globales que sólo guardan instancias de clases.

3. Permite cambiar el número de instancias:Este patrón facilita que se aña- dan más instancias de la claseSingletonen caso de que ya no queramos solo una. Además, se puede controlar el número de instancias que se usan.

4.2.2 El patrón de diseño:Factory Method

• Propósito:Permite que una clase delegue en sus subclases la creación de objetos.

• Motivación:Es importante, definir una interfaz para crear un objeto, pero dejando en manos de las subclases la decisión de qué clase concreta instanciar. Por ejemplo, existe una tienda online donde se le ofrece al usuario tres métodos de pagos distintos: tarjeta, paypal o transferencia bancaria. La elección del método de pago siempre va a depender de la decisión en ese instante del usuario. Un buena solución, sería usar el patrónFactory Method, teniendo una interfazPago que hace al objeto que la implemente ser de tipoPago. Todos los métodos de pago, tarjeta, paypal o tranferencia bancaria serían objetos de tipoPago, ya que,

(47)

4.2. Patrones de diseño

implementaría esta interfaz. Entonces, basta con crear un objeto que simule el funcionamiento, de toda la vida, de una fábrica. Esta vez, un objeto de la clase PagoFactory que según el tipo de pago elegido, parámetro de la clase, sepa el método de pago (objeto de tipoPago) que se ha de crear y retornar. Para que el

Figura 4.3: Ejemplo del patrón de diseñoFactory Method

Fuente: http://www.dofactory.com/net/factory-method-design-pattern lector pueda relacionar con más facilidad la imagen con el ejemplo expuesto, se aclara que la interfazProductrepresenta a la interfazPago, la claseConcre- teProductrepresenta a cualquiera de los métodos de pago del ejemplo, la clase ConcreteCreatorrepresenta a la clasePagoFactory(la fábrica de tipos de pago) y la claseCreator, simplemente sería la clase que instancia el objeto que representa a la fábrica.

• Aplicabilidad:El patrónFactory Methodse debe usar cuando se tiene que crear la instancia de un objeto pero a priori no se sabe aún que tipo de objeto tiene que ser, generalmente, porque depende de alguna opción que seleccione el usuario en la aplicación o porque depende de una configuración que se hace en tiempo de despliegue de la aplicación.

1. Se gana en flexibilidad, pues crear los objetos dentro de una clase con un Factory Mehodes siempre más flexible que hacerlo directamente, debido a que se elimina la necesidad de atar la aplicación a clases de productos concretos.

2. Facilita futuras ampliaciones, puesto que se ofrece a las subclases la posibilidad de proporcionar una versión extendida de un objeto, con sólo aplicar en losConcreteProductla misma idea delFactory Mehod.

4.2.3 El patrón de diseño:Command

• Propósito:Encapsular una solicitud u orden como un objeto, no dejando parametrizar clientes con diferentes solicitudes.

(48)

• Motivación:A veces es necesario publicar solicitudes u ordenes a objetos sin que estos conozcan nada sobre la operación. Por ejemplo, las interfaces de usuario incluyen objetos como son los botones y menús, los cuales realizan una solicitud en respuesta a una entrada del usuario. La interfaz, no puede implementar la solicitud explícitamente en el botón o en el menú porque solo las aplicaciones que usan la interfaz saben que debería hacerse con cada objeto. El diseñador de la interfaz, como diseñador que es, no tiene forma de conocer el receptor de la solicitud o las operaciones que la llevarán a cabo.

El patrónCommand— orden — permite a los objetos de la interfaz hacer solicitudes de objetos de una aplicación no especificada convirtiendo la solicitud en un objeto.

Este objeto puede ser almacenado y movido como otros objetos. La clave de este patrón es unaclase abstractacommandque declara una interfaz para ejecutar operaciones. Por lo tanto, ese botón que pertenece ala interfaz, la que hemos hablado anteriormente en el ejemplo,lo único que sabe es que va a tratar con un objeto de tipo comando oCommand.

Figura 4.4: Ejemplo del patrón de diseñoCommand

Fuente: http://www.hsufengko.com/blog/command-design-pattern-example

• Aplicabilidad:Use el patrónCommandcuando se produzcan los motivos siguientes,

1. Parametrizar objetos con una acción para realizar.

2. Estructurar un sistema en torno a operaciones de alto nivel construidas en operaciones primitivas.

1. Desacoplamiento del objeto que invoca la operación del que conoce como realizarla.

2. Los objetosCommandpueden ser manipulados y extendidos como cualquier otro objeto.

3. Es fácil añadir nuevos objetosCommandporque no hace falta cambiar las clases existentes.

Glyphstock. Aplicación cliente multiplataforma

T rabajo F in de G ra do

GRADO EN INGENIERÍA INFORMÁTICA