desarrollo de aplicaciones híbridas multiplataforma …...empírica de desarrollo utilizando la...

Desarrollo de aplicaciones híbridas multiplataforma con PhoneGap para

dispositivos HandHeld

Alumnos: Bender Gabriel Agustín – Chavez Alexis David

Tutor de Tesina: Lic. Marcelo Eleazar Gómez

Tesina presentada a la Facultad de Ingeniería de la Universidad Nacional de la

Patagonia San Juan Bosco como parte de los requisitos para la obtención del título de

Licenciado en Informática

Trelew, Noviembre de 2014

Facultad de Ingeniería – Sede Trelew

Universidad Nacional de la Patagonia San Juan Bosco

Desarrollo de aplicaciones híbridas multiplataforma con PhoneGap para dispositivos HandHeld

Bender Gabriel Agustín – Chavez Alexis David Pág. 1

Agradecimientos

Dedicamos esta Tesina principalmente a nuestras familias y amigos, quienes

nos apoyaron e impulsaron incansablemente a lo largo de estos años de carrera, a

nuestras novias, que nos dieron su comprensión y estímulo constantes, a todos los

compañeros con quienes compartimos tantas horas de estudio, a los profesores, que

sembraron en nosotros la semilla del conocimiento, a todas las personas que con sus

ideas y/o conocimientos colaboraron en este proyecto, y en particular a nuestro tutor,

Marcelo Eleazar Gómez, por todo el tiempo y esfuerzo que nos brindó, siendo

indispensable para la realización y conclusión de este trabajo.

Gabriel Agustín Bender, Alexis David Chavez



Resumen

Esta tesina tiene como finalidad central, analizar una herramienta de desarrollo de aplicaciones para dispositivos handheld (ver Glosario), denominada “PhoneGap”. Este análisis comprenderá tanto los aspectos teóricos de mayor relevancia, como así también, una prueba empírica de desarrollo utilizando la misma. A tal efecto se presentará previamente el estudio de los diversos paradigmas de programación. Nos referimos al “web”, al “nativo” y al “híbrido”. Siendo este último (el más reciente de los tres), una fusión entre los dos primeros.

También nos sumergiremos en el estudio del “estado del arte” en lo que a desarrollo para dispositivos móviles se refiere. Analizaremos las opciones existentes de mayor resonancia, observando sus características, ventajas y contraindicaciones, de donde surgirá el por qué de la elección de PhoneGap para su experimentación. Esta alternativa, sustentada sobre el paradigma “híbrido”, implicará también la investigación de lenguajes y tecnologías web subyacentes, así como el aprendizaje de buenas prácticas, y uso de librerías de apoyo sustentadas sobre las mismas.

En relación a la parte teórica de PhoneGap, analizaremos primeramente todos los aspectos básicos en relación a su instalación y configuración. También se mostrará cómo utilizar su interfaz de línea de comandos (CLI) y sus operaciones más importantes. Posteriormente se explorará la API (Application Programming Interface) de esta herramienta, con el fin de conocer sus capacidades, propiedades y tener un marco de referencia en cuanto a su aplicación. Se estudiará además la creación de plugins propios, que permitan resolver cuestiones no contempladas por la propia API.

En respuesta a la parte práctica, se propondrá un problema a resolver. El mismo consistirá en una aplicación a la que llamaremos “DigitalHC” , la cual gestionará una pequeña historia clínica de pacientes. Si bien el desarrollo inicialmente se hará utilizando la plataforma “Android” , también se probará la aplicación sobre las plataformas “BlackBerry” e “iOS” . Se pretende con esta experiencia, poder determinar a ciencia cierta las capacidades reales de PhoneGap, así como sus fortalezas y debilidades.

Finalmente y luego de todo el análisis, investigación y pruebas realizados, se expondrá un resumen en referencia al desarrollo llevado a cabo. Plasmaremos los resultados y conclusiones personales obtenidos a lo largo de la realización del proyecto. Formularemos los mismos con criterio y objetividad, con el fin de poder entregar al lector, la más clara, concisa y consistente opinión posible sobre este framework, el cual nos ha acompañado durante un buen tiempo.



Abstract

This dissertation has as central purpose, analyze an application development tool for handheld devices, called “PhoneGap”. This analysis will include both the theoretical aspects of greater relevance, as well as an empirical test of development using the same. For this purpose will be presented before, the study of the various programming paradigms. We refer to the “web”, the “native” and the “hybrid”. The latter being (the most recent of the three), a fusion between the first two.

Also we'll then dive into the study of the “state of the art” of that development for mobile devices. We will analyze the existing options of greater resonance, noting their features, benefits and contraindications, where will emerge by the choice of PhoneGap for its experimentation. This alternative, based on the “hybrid” paradigm, also involve the investigation of languages and technologies underlying web, as well as learning from good practices, and use of libraries of support based on the same.

As regards the theoretical part of PhoneGap, we will analyze firstly all the basic aspects as regards its installation and configuration. It will also be shown how to use its command-line interface (CLI) and their most important operations. Then explore the Application Programming Interface (API) of this tool, in order to know their capabilities, properties, and have a frame of reference with regard to its application. There will be studied also the creation of proper plugins, which allow to solve questions not contemplated by the proper API.

In answer to the practical part, there will be proposed a problem to be solved. The same will consist of an application to call that “DigitalHC” , which will manage a small medical history of patients. While initially the development is done using the platform “Android” , also will be tested the application on the platforms “BlackBerry” and “iOS” . The aim of this experience, be able to ascertain the actual capacity of PhoneGap, as well as their strengths and weaknesses.

Finally, after all the analysis, research and testing, will be shown a summary in reference to development carried out. We will formulate the same ones with criterion and objectivity, in order to be able to deliver the reader, the clearest, concise and consisting possible opinion about this framework, which has been with us for a good time.



Índice

Agradecimientos .................................................................................................................................. 1

Resumen ............................................................................................................................................... 3

Abstract ................................................................................................................................................ 5

Índice .................................................................................................................................................... 7

Objetivos ............................................................................................................................................ 15

Introducción ....................................................................................................................................... 17

1. PARADIGMAS NATIVO, WEB E HÍBRIDO ............................................................................. 19

1.1 Introducción.............................................................................................................................. 19

1.2 Aplicaciones Nativas ................................................................................................................ 20

1.2.1 Ventajas ............................................................................................................................. 21

1.2.2 Desventajas ........................................................................................................................ 21

1.3 Aplicaciones web para dispositivos móviles ............................................................................ 23

1.3.1 Ventajas ............................................................................................................................. 24

1.3.2 Desventajas ........................................................................................................................ 24

1.4 Aplicaciones Híbridas .............................................................................................................. 25

1.4.1 Ejemplos de aplicaciones híbridas ..................................................................................... 25

1.4.2 Ventajas ............................................................................................................................. 25

1.4.3 Desventajas ........................................................................................................................ 26

1.5 Cuentas de desarrollador en tiendas oficiales........................................................................... 27

1.6 Comparativas y Conclusiones .................................................................................................. 28

2. EXPLORANDO EL ESTADO DEL ARTE .................................................................................. 31

2.1 Introducción.............................................................................................................................. 31

2.2 Corona SDK ............................................................................................................................. 32

2.2.1 Ventajas ............................................................................................................................. 32

2.2.2 Desventajas ........................................................................................................................ 32

2.2.3 Acerca de Lua .................................................................................................................... 32

2.3 Lungojs ..................................................................................................................................... 33

2.3.1 Ventajas ............................................................................................................................. 33

2.3.2 Desventajas ........................................................................................................................ 33

2.4 Yui ............................................................................................................................................ 34

2.4.1 Ventajas ............................................................................................................................. 34

2.4.2 Desventajas ........................................................................................................................ 34



2.5 Sencha Touch ........................................................................................................................... 35

2.5.1 Ventajas ............................................................................................................................. 36

2.5.2 Desventajas ........................................................................................................................ 36

2.6 Jquery Mobile ........................................................................................................................... 37

2.6.1 Ventajas ............................................................................................................................. 37

2.6.2 Desventajas ........................................................................................................................ 37

2.7 Rhodes (Rhomobile)................................................................................................................. 39

2.7.1 Ventajas ............................................................................................................................. 40

2.7.2 Desventajas ........................................................................................................................ 40

2.8 Titanium Appcelerator ............................................................................................................. 41

2.8.1 Ventajas ............................................................................................................................. 42

2.8.2 Desventajas ........................................................................................................................ 42

2.9 PhoneGap ................................................................................................................................. 43

2.9.1 Mejoras a partir de la Versión 3.0 ......................................................................................... 44

2.9.2 Ventajas ............................................................................................................................. 44

2.9.3 Desventajas ........................................................................................................................ 45

2.10 Corolario de esta investigación .............................................................................................. 46

3. LENGUAJES Y TECNOLOGÍAS NECESARIOS ...................................................................... 47

3.1 Introducción.............................................................................................................................. 47

3.2 HTML5 ..................................................................................................................................... 48

3.2.1 Historia .............................................................................................................................. 48

3.2.2 Evolución de la Web .......................................................................................................... 50

3.2.3 Desarrollo de Aplicaciones Móviles con HTML5 ............................................................. 53

3.2.4 Aplicaciones Móviles Multiplataforma ............................................................................. 53

3.2.5 Mejoras aprovechables de HTML5 ................................................................................... 54

3.3 CSS3 ......................................................................................................................................... 57

3.3.1 Diseño adaptativo .............................................................................................................. 57

3.3.2 Mejoras aprovechables de CSS3 ....................................................................................... 58

3.4 JAVASCRIPT .......................................................................................................................... 62

4. PRESENTANDO PHONEGAP .................................................................................................... 65

4.1 Introducción.............................................................................................................................. 65

4.2 ¿Qué es PhoneGap? .................................................................................................................. 66

4.2.1 PhoneGap y el “webview” ................................................................................................. 67

4.2.2 Características principales ................................................................................................. 67



4.3 Instalando PhoneGap ................................................................................................................ 70

4.3.1 Prerrequisitos ..................................................................................................................... 71

4.3.1.1 Instalación de Apache ANT ........................................................................................ 71

4.3.1.2 Instalación de Java ...................................................................................................... 71

4.3.1.3 Instalación de Git ........................................................................................................ 71

4.3.1.4 Instalación del SDK de Android ................................................................................. 71

4.3.1.5 Instalación de GCC ..................................................................................................... 72

4.3.1.6 Instalación de NodeJs ................................................................................................. 72

4.3.2 Instalación de PhoneGap ................................................................................................... 72

4.3.2.1 Aclaración antes de continuar ..................................................................................... 73

4.4 Línea de comandos de PhoneGap ............................................................................................ 74

4.4.1 Creación de un proyecto .................................................................................................... 74

4.4.2 Añadir una plataforma ....................................................................................................... 75

4.4.3 Listar plataformas .............................................................................................................. 76

4.4.4 Remover plataformas ......................................................................................................... 77

4.4.5 Instalación de un plugin ..................................................................................................... 77

4.4.6 Listar Plugins ..................................................................................................................... 78

4.4.7 Remover plugins ................................................................................................................ 78

4.4.8 Compilación de la aplicación ............................................................................................. 79

4.4.8 Correr la aplicación ............................................................................................................ 79

4.4.9 Emular la aplicación .......................................................................................................... 80

4.5 Personalización de la plataforma .............................................................................................. 83

4.5.1 Usando “Merges” ............................................................................................................... 83

4.6 Scripts de compilación ............................................................................................................. 84

4.6.1 Usando hooks ..................................................................................................................... 85

5. LOS EVENTOS Y LA API DE PHONEGAP............................................................................... 87

5.1 Introducción.............................................................................................................................. 87

5.2 Eventos ..................................................................................................................................... 88

5.2.1 Onload y ready ................................................................................................................... 88

5.2.2 Deviceready ....................................................................................................................... 89

5.2.3 Captura de botones ............................................................................................................ 90

5.2.4 Pause y resume .................................................................................................................. 91

5.3 La API de PhoneGap ................................................................................................................ 92

5.3.1 Device-motion (Acelerómetro) .......................................................................................... 92



5.3.2 Camera (Cámara) ............................................................................................................... 94

5.3.3 Media-capture (Captura multimedia) ................................................................................ 98

5.3.4 Geolocation (Geolocalización) ........................................................................................ 102

5.3.5 Device-orientation (Brújula) ............................................................................................ 104

5.3.6 Contacts (Contactos) ........................................................................................................ 107

5.3.7 Device (Dispositivo) ........................................................................................................ 111

5.3.8 Media (Captura de audio) ................................................................................................ 111

5.3.9 Globalization (Globalización) ......................................................................................... 118

5.3.10 File (Archivo) ................................................................................................................ 126

5.3.11 File-transfer (Transferencia de archivos) ....................................................................... 130

5.3.12 InAppBrowser (Navegador embebido) .......................................................................... 134

5.3.13 Splashscreen (Pantalla de Bienvenida) .......................................................................... 137

5.3.14 Battery-status (Estado de batería) .................................................................................. 138

5.3.15 Network-information (Información sobre red) .............................................................. 139

5.3.16 Dialogs (Diálogos) ......................................................................................................... 140

5.3.17 Vibration (Vibración) .................................................................................................... 142

6. CREANDO UN PLUGIN ............................................................................................................ 143

6.1 Introducción............................................................................................................................ 143

6.2 Estructura de un plugin........................................................................................................... 144

6.3 Construcción de un plugin ...................................................................................................... 146

6.3.1 La interfaz JavaScript ...................................................................................................... 147

6.3.2 La interfaz nativa ............................................................................................................. 147

6.4 Implementando un plugin ....................................................................................................... 148

6.4.1 Interfaz JavaScript ........................................................................................................... 148

6.4.2 Interfaz nativa (Android) ................................................................................................. 148

6.4.3 Agregar referencia al plugin ............................................................................................ 150

6.5 Otros plugins para PhoneGap ................................................................................................. 151

7. DESARROLLO PROPUESTO ................................................................................................... 153

7.1 Introducción............................................................................................................................ 153

7.2 Problema propuesto ................................................................................................................ 154

7.2.1 Resumen ........................................................................................................................... 154

7.2.2 Enunciado ........................................................................................................................ 154

7.2.3 Datos básicos requeridos ................................................................................................. 155

7.3 Diseño de la solución ............................................................................................................. 157



7.3.1 Selección de método de persistencia de datos ................................................................. 157

7.3.2 Diseño de la base de datos para DigitalHC ..................................................................... 159

7.3.3 Diseño de la base de datos del servidor ........................................................................... 160

7.3.4 Estructura del código fuente ............................................................................................ 160

7.4 Explorando la aplicación ........................................................................................................ 165

7.4.1 Vista del emulador utilizado ............................................................................................ 165

7.4.2 Pantalla de bienvenida (splashscreen) ............................................................................. 166

7.4.1 Pantalla de presentación .................................................................................................. 166

7.4.2 Menú Pacientes ................................................................................................................ 167

7.4.3 Nuevo paciente ................................................................................................................ 167

7.4.4 Listado de paciente .......................................................................................................... 171

7.4.5 Tomar la foto de un paciente ........................................................................................... 171

7.4.6 Ver los datos de un paciente ............................................................................................ 172

7.4.7 Buscar un paciente ........................................................................................................... 173

7.4.8 Menú para la gestión del paciente ................................................................................... 173

7.4.9 Gestión de consultas ........................................................................................................ 175

7.4.10 Menú Reportes ............................................................................................................... 177

7.4.11 Generación de gráficos estadísticos ............................................................................... 178

7.4.12 Exportar a PDF .............................................................................................................. 179

7.4.13 Menú Tablas .................................................................................................................. 180

7.4.14 Salir del Sistema ............................................................................................................ 183

7.5 Explorando el servidor web .................................................................................................... 184

7.5.1 Ingreso a la aplicación web .............................................................................................. 185

7.5.2 Coordenadas del servidor ................................................................................................ 185

7.5.3 Listado de dispositivos localizados ................................................................................. 186

7.5.4 Ver el identificador del dispositivo .................................................................................. 187

7.5.5 Ver las coordenadas del dispositivo ................................................................................ 187

8. HERRAMIENTAS UTILIZADAS.............................................................................................. 189

8.1 Introducción............................................................................................................................ 189

8.2 jQuery Mobile ........................................................................................................................ 190

8.3 XUI ......................................................................................................................................... 191

8.4 jQuery ..................................................................................................................................... 192

8.5 jQuery Touch .......................................................................................................................... 193

8.6 jQuery bPopup ........................................................................................................................ 195



8.7 Fastclick.................................................................................................................................. 196

8.8 Topcoat ................................................................................................................................... 198

8.9 HighCharts.............................................................................................................................. 199

8.10 jsPDF .................................................................................................................................... 201

9. BUENAS PRÁCTICAS ............................................................................................................... 203

9.1 Introducción............................................................................................................................ 203

9.2 Cómo comenzar ...................................................................................................................... 204

9.2.1 Definición de la estructura base ....................................................................................... 205

9.3 Utilizar módulo “media queries” de CSS3 ............................................................................. 206

9.4 Optimizando uso de íconos mediante “Sprites” ..................................................................... 207

9.5 Reducir cantidad de capas ...................................................................................................... 208

9.6 Realizar animaciones con CSS3 ............................................................................................. 209

9.7 Precarga de archivos HTML .................................................................................................. 211

9.8 Mostrar símbolo de carga ....................................................................................................... 212

9.9 Otros consejos para una aplicación fluida .............................................................................. 213

10. PRUEBAS, RESULTADOS Y CONCLUSIONES .................................................................. 215

10.1 Introducción.......................................................................................................................... 215

10.2 Pruebas en Android .............................................................................................................. 216

10.2.1 Entornos de prueba ........................................................................................................ 216

10.2.1.1 Dispositivo físico .................................................................................................... 216

10.2.1.2 Google Chrome ....................................................................................................... 218

10.2.1.3 Emulador ................................................................................................................. 221

10.2.1.4 Resumen sobre entornos de prueba ......................................................................... 224

10.2.2 Pruebas y resultados obtenidos ...................................................................................... 224

10.3 Pruebas en iOS ..................................................................................................................... 227

10.3.1 Instalar Xcode IDE ........................................................................................................ 227

10.3.2 Creación de la aplicación ............................................................................................... 227

10.3.3 Creación de la plataforma iOS ....................................................................................... 227

10.3.4 Copiar código fuente e instalar plugins ......................................................................... 228

10.3.5 Abriendo el proyecto en Xcode ..................................................................................... 228

10.3.6 Emulación de la aplicación ............................................................................................ 229

10.4 Pruebas en BlackBerry 10 .................................................................................................... 233

10.4.1 Requerimientos básicos ................................................................................................. 233

10.4.2 Instalar SDK WebWorks para BB10 ............................................................................. 233



10.4.3 Instalar la máquina virtual de BB10 .............................................................................. 233

10.4.4 Instalar software de virtualización ................................................................................. 234

10.4.5 Configurar y ejecutar la máquina virtual ....................................................................... 234

10.4.6 Creación de la plataforma BB10 .................................................................................... 234

10.4.7 Compilación de la aplicación a BB10 ........................................................................... 234

10.4.8 Instalar la aplicación en el emulador ............................................................................. 234

10.4.9 Emulación de la aplicación ............................................................................................ 236

10.5 Resultados finales ................................................................................................................. 239

10.5.1 Líneas de código empleadas .......................................................................................... 239

10.5.2 Plugins de la API de PhoneGap utilizados .................................................................... 240

10.5.3 Plugins JavaScript utilizados ......................................................................................... 240

10.5.4 Plugins CSS utilizados ................................................................................................... 240

10.5.5 Tiempo estimado de desarrollo ...................................................................................... 240

10.6 Conclusiones ........................................................................................................................ 241

10.7 Trabajos futuros .................................................................................................................... 244

10.8 Reflexión final ...................................................................................................................... 245

Glosario ............................................................................................................................................ 247

Bibliografía ...................................................................................................................................... 253



Objetivos

Como objetivo de la presente Tesina de Grado de la Carrera Licenciatura en Informática, nos hemos planteado un desafío concreto: Investigar el estado del arte en el desarrollo de aplicaciones para dispositivos móviles, describir en profundidad y experimentar con una opción para desarrollo multiplataforma, utilizando herramientas de código abierto.

Si bien hemos descripto la idea principal. Es necesario empezar a dilucidar una serie de parámetros y restricciones que nosotros pretendemos sean cumplidos por la herramienta que seleccionaremos y que estudiaremos minuciosamente.

En primer lugar pretendemos poder generar aplicaciones de una manera rápida y sencilla, sin la necesidad de aprender nuevos lenguajes específicos del ámbito de la telefonía celular (JavaMe, Android SDK, Windows Mobile, etc.). Esto es, poder minimizar la curva de aprendizaje lo más posible, sin relegar expresividad, operatividad, eficiencia y amigabilidad en la aplicación desarrollada.

Otro punto clave tiene que ver con el desarrollo multiplataforma. La idea es gastar la mayor parte del tiempo en el diseño de la aplicación y codificarla una sola vez, minimizando el tiempo de implantación y adaptación. En este punto nos referimos a escribir una sola vez el programa y poder distribuirlo luego de manera transparente o semi-transparente para ser instalado en diferentes plataformas. Este sea quizás uno de los puntos clave de esta tesina, dado que, en la actualidad existen muchos sistemas operativos para teléfonos móviles y todos presentan un gran mercado. Tener que reescribir en el código nativo de cada uno de esos sistemas operativos parece una carga bastante pesada y quizás innecesaria.

Además de los puntos antes nombrados pensamos que es de sumo interés que la plataforma de desarrollo elegida cuente con un buen uso y aprovechamiento del hardware, dado que éste está presente con cada vez más potencia en los dispositivos móviles. Esta manipulación debe ser adecuada, sencilla y completa en lo posible.

Hasta el momento hemos hecho bastante hincapié en los aspectos técnicos deseados, pero no podemos dejar de lado un hecho muy importante a nuestro parecer, la herramienta o conjunto de herramientas que pretendemos encontrar, deben existir en el ámbito del código abierto y contar en lo posible con una amplia comunidad desarrolladora, algo que a todo programador siempre le importa a la hora de empezar a usar un nuevo lenguaje, plataforma o ambiente de programación.

Finalmente uno de los puntos también clave a nuestro entender en el desarrollo de este trabajo es la posibilidad de utilizar nuevas tecnologías de programación. En particular la batería de tecnologías de programación web como ser HTML5, CSS3 y JavaScript. En este punto, sería de nuestro mayor agrado poder conjugar nuestro proyecto con los lenguajes web nombrados anteriormente para podernos aggiornar y nutrirnos en referencia a dichas tecnologías que tan prometedoras se están presentando desde hace ya bastante tiempo y, que dan su primera explosión importante en varios años.



Introducción

Luego de planteados los objetivos ahora sí pondremos manos a la obra en la búsqueda de la herramienta que estudiaremos y que nos acompañará el resto de los capítulos. A modo de ayuda memoria listamos de forma sintética los puntos clave que inclinarán la balanza y, en último caso, determinarán la herramienta ganadora.

Los puntos a tener en cuenta son:

� Curva de aprendizaje achatada.

� Permitir generar aplicaciones multiplataforma .

� Uso completo y eficiente del hardware.

� Debe ser de uso libre .

� Contar con una comunidad “fuerte” de usuarios.

� Debe aprovechar el uso de las nuevas tecnologías web.

� Que favorezca el desarrollo de aplicaciones del tipo contable.

Con el fin de responder a esta necesidad que hemos descripto, nos sumergiremos un poco en el mundo de las aplicaciones para teléfonos móviles (celulares) y revisaremos su estado del arte. Téngase en cuenta que corre el año 2014. Por tal motivo estudiaremos tecnologías que tengan cierto grado de madurez y tengan vigencia en el corriente año.

En el próximo capítulo presentamos un análisis de los diferentes paradigmas de programación, para tener una visión inicial y global de las posibilidades para el desarrollo de aplicaciones para dispositivos móviles. Posteriormente se expondrán diferentes herramientas estudiadas para poder ponerlas en contraste. Dicho análisis no será exhaustivo pero nos dará a priori una idea de qué camino continuar, para luego sí, en los próximos capítulos dedicarle más tiempo y detalle a la herramienta elegida.



1. PARADIGMAS NATIVO, WEB E HÍBRIDO

1.1 Introducción

A la hora de desarrollar una aplicación para dispositivos móviles hay que tener en cuenta que ésta depende del sistema operativo de cada dispositivo y que cada una de las plataformas existentes (“iOS” , “Android” , “BlackBerry” , etc.) tiene sus particularidades. Contrario a lo que sucede con las páginas web, donde esto es mucho más transparente y resulta menos complicado realizar una aplicación, dado que las mismas se ejecutan en el navegador web de cada dispositivo y el mismo código web es ejecutado por todos los browsers y plataformas. Pero se resigna el acceso a muchas de las características del hardware del dispositivo. Existe otra alternativa que mezcla las dos opciones antes nombradas y presenta nuevas ventajas y desventajas. Resumiendo, es posible concluir que en la actualidad tenemos tres paradigmas para el desarrollo de aplicaciones para dispositivos móviles, las cuales son:

• Nativo.

• Web. • HÍbrido.

En 2012, Patricia Miralles sostiene “…el debate entre las aplicaciones nativas, aplicaciones web, o híbridas, parece no tener fin. Cada enfoque tiene sus ventajas y desventajas, el truco está en saber cuál es la ideal para cada caso antes de lanzar la aplicación o comenzar el desarrollo” (http://www.tucamon.es/).



1.2 Aplicaciones Nativas

Una aplicación nativa, consiste en una aplicación móvil desarrollada en el lenguaje específico para una plataforma. En otras palabras, si se desea que una aplicación funcione por ejemplo, en un “iPhone” , “Android” y “BlackBerry” , hay que desarrollar la misma aplicación en tres versiones distintas, una para cada plataforma.

Cada versión de esta aplicación se distribuye y comercializa a través de las tiendas online correspondientes: “Apple Store” (iOS), “Google Play” (Android), “App World” (BlackBerry) y “Windows Marketplace” (Windows Phone). Después de su descarga al dispositivo, esta aplicación se instala en el sistema de archivos correspondiente a cada dispositivo móvil.

Entonces, llegamos a la conclusión de que para cada plataforma hay que desarrollar una aplicación distinta, es decir que comparten la lógica, pero la codificación es completamente distinta en cada una. Por ejemplo, Para “Android” se programa en “Java” , para “iOS” en “Objetive-C” y para “Windows Phone” en “C#” .

Estas aplicaciones Nativas corren de forma muy eficiente sobre los dispositivos ya que sus componentes están diseñados de forma específica para cada sistema operativo. Además, pueden emplear todos los sensores y elementos del dispositivo: cámara, GPS, acelerómetro, agenda, etc. Esta es la diferencia fundamental con respecto a las aplicaciones web.

También se debe mencionar que el costo de este tipo de aplicación es un poco elevado debido a dos motivos: El primero, es porque hay un proceso de desarrollo separado (el código base y el conjunto de habilidades necesarias para cada plataforma). El segundo, es que los programadores son más difíciles de encontrar y más caros.

En la figura 1.1 correspondiente a la “arquitectura de una aplicación nativa”, se puede observar cómo se interactúa directamente con las API de una plataforma específica, es decir, el sistema operativo recibe una llamada en forma directa para ejecutar una funcionalidad propia del dispositivo, tal como se mencionó anteriormente.



Fig. 1.1 - Arquitectura de una aplicación nativa (fuente: www.geospatialtrainges.com, 2013)

1.2.1 Ventajas

• Posibilidad de utilizar todas funcionalidades del dispositivo: Cámara, GPS, contactos, acelerómetro, etc.

• Rendimiento: Es más rápida que una aplicación web o híbrida, puede interactuar con otras aplicaciones nativas y sacar mejor partido a los recursos del dispositivo. Hace un uso de CPU, memoria, y batería óptimo.

• Existe un sitio para compartir y comercializar las aplicaciones: AppleStore, Google Play, BlackberryAppWorld, Windows Marketplace, etc.

• Funciona en modo online y offline: Se puede utilizar sin la necesidad de una conexión a internet.

• Verificación y aceptación más rápido: Este proceso por parte de las distintas Store, suele ser más rápido que el de una aplicación híbrida.

• Almacenamiento local seguro.

1.2.2 Desventajas

• Costo: Es más alto en general, pero suele ser más barato si se precisa el desarrollo de la aplicación para una única plataforma.

• Tiempo de desarrollo elevado: Se tiene que desarrollar una aplicación para cada plataforma.

• Mayor costo de mantenimiento: Mantener varias versiones de la misma aplicación para distintas plataformas es costoso.



• Tiempo de aprobación: La aprobación de una nueva aplicación en el Apple Store puede llegar a tardar un par de semanas. En Google Play son 24h. Cualquier modificación, actualización o nueva funcionalidad de la aplicación tiene que pasar por el mismo sistema de aprobación. Esto es una desventaja respecto a las aplicaciones web.

• Costo adicional para una aplicación paga: Apple Store y Google Play cobran por cada aplicación disponible en su tienda 30% del precio de la aplicación. Así como un 30% de los ingresos obtenidos a través de la aplicación mediante in-app purchase (compras desde la propia aplicación). Otra desventaja respecto a las aplicaciones web.



1.3 Aplicaciones web para dispositivos móviles

Las Aplicaciones web o webApp para dispositivos móviles consisten en el desarrollo de páginas web que son optimizadas para ser visualizadas en las pantallas de dichos dispositivos y ser utilizadas en pantallas táctiles. Gracias al “Responsive Web Design” (diseño web adaptable) cualquier contenido web se adapta a las dimensiones de las distintas pantallas.

El usuario accede a estas aplicaciones mediante el navegador web de su dispositivo, aunque en función del dispositivo puede crear un enlace directo en su escritorio y acceder a ella como si se tratara de cualquier otra aplicación.

Las tecnologías utilizadas son las mismas que para un sitio web. Se utiliza HTML, CSS JavaScript como lenguajes de base de programación. Su funcionamiento es principalmente online pero pueden contar con caché local y almacenamiento de datos local para el funcionamiento en modo offline.

Estas aplicaciones no se distribuyen mediante tiendas oficiales, lo que permite liberarse de las tareas y limitaciones impuestas por estas. Como exponentes notables del uso de esta tecnología de desarrollo podemos mencionar por ejemplo: “Financial Times” (aplicación web con caché local), “Yahoo Mail” , entre otras.

La figura 1.2 representa la “arquitectura de una aplicación web”. Se puede observar cómo estas aplicaciones “basadas en HTML” se ejecutan dentro del navegador. En este caso, el acceso a los recursos del dispositivo es limitado, ofrecen menos funcionalidades que las aplicaciones nativas.

Fig. 1.2 - Arquitectura de una aplicación web (fuente: www.geospatialtrainges.com, 2013)



1.3.1 Ventajas

• Costo: Es mas barato dado que desarrolla una única aplicación para todos los sistemas operativos a diferencia de una aplicación nativa.

• Rapidez de desarrollo: Al desarrollar para todas las plataformas a la vez no se multiplica el tiempo de desarrollo.

• Compatibilidad: Se reutiliza casi en un 100% el mismo código fuente para todos los sistemas operativos de los dispositivos móviles. Se puede optimizar para las distintas resoluciones de las pantallas de los dispositivos móviles.

• Mantenimiento de un único código para todas las plataformas.

• Distribución: Se puede evitar la subida a los repositorios oficiales online. Simplemente se accede a la aplicación a través de una URL.

• Actualizaciones inmediatas: Las actualizaciones de la aplicación son inmediatas, a diferencia de unas semanas de espera de aprobación como en el caso de Apple Store.

• Posibilidad de SEO: (Search Engine Optimization) Para mejorar la visibilidad de un sitio web en los buscadores.

• Visibilidad: La URL de la aplicación web es fácil de compartir y puede redirigir el tráfico desde redes sociales, blogs, códigos QR y medios de publicidad.

1.3.2 Desventajas

• Baja integración con los componentes nativos del dispositivo: Las aplicaciones web, al ser ejecutadas en el navegador, sólo pueden acceder a determinados componentes y funcionalidades nativas del dispositivo, aunque las posibilidades evolucionan con rapidez.

• Diferencias entre dispositivos: El nivel de incorporación de los estándares en los navegadores de cada dispositivo es bastante heterogéneo. Es posible que se dedique más tiempo en testear y corregir problemas de una aplicación web debido al comportamiento distinto de los navegadores.

• Uso obligatorio de internet: Las páginas son alojadas en servidores web. Y aún usando una página offline esta tiene grandes limitaciones, como por ejemplo de almacenamiento.

• Baja fluidez: Una interfaz de usuario desarrollada en HTML5 no es tan fluida como una nativa.



1.4 Aplicaciones Híbridas

Las aplicaciones híbridas reúnen lo mejor de los dos modelos anteriores. Este tipo de aplicaciones se basa en el uso de tecnologías web y multiplataforma como HTML, JavaScript y CSS, que permiten acceder a buena parte del hardware y características de los dispositivos móviles. Buena parte de la infraestructura es tipo web, se ejecutan y utilizan el motor de navegación sin utilizar el navegador en sí mismo. La comunicación con los elementos del dispositivo se hace mediante comunicadores tales como PhoneGap.

1.4.1 Ejemplos de aplicaciones híbridas

• Instagram: Utiliza tecnología nativa para tomar, editar y publicar las fotos (incluso sin conexión a internet) y la tecnología web para desplegar las fotos y el perfil. Esto permite a los desarrolladores mejorar la lista de fotografías sin la necesidad de publicar una nueva versión. Si no hay conexión a internet la foto queda a la espera de ser subida una vez que haya conexión.

• Linked In: Híbrida para iOS y nativa para Android. • Facebook: Ha cambiado de una aplicación totalmente híbrida a una nativa con

funcionalidades híbridas.

El proceso de desarrollo para este tipo de aplicaciones es un poco más complicado respecto de las aplicaciones web. Si bien utiliza los mismos lenguajes de desarrollo, al igual que para las aplicaciones nativas el código una vez creado se debe compilar a un ejecutable. Este proceso debe repetirse para cada una de las plataformas deseadas, pero esto no conlleva necesariamente un gran esfuerzo para el desarrollador. Finalmente estos archivos pueden ser subidos para su distribución a la correspondiente App Store.

En 2013, la empresa ACCENSIT ADVISORS SL decía: “…la solución híbrida pretende aprovechar las capacidades de las aplicaciones nativas permitiendo la re-utilización de la mayor parte del código para todas las plataformas.” (http://www.accensit.com/)

1.4.2 Ventajas

• Fáciles de desarrollar: No se deben conocer lenguajes específicos, sino un par de tecnologías webs. Esto implica menos problemas para encontrar un desarrollador de aplicaciones.

• Se minimiza el código específico: La mayor parte del código puede utilizarse para todas las plataformas. Sólo se utiliza código nativo para aquellos aspectos que lo requieran.

• Menor costo de desarrollo: Sobre todo si se requiere la aplicación en varias plataformas. • Menor costo de mantenimiento: al ser la mayor parte del código común a todas las

plataformas.



• Acceso al dispositivo: Una aplicación híbrida puede acceder a los recursos del dispositivo móvil prácticamente como una nativa.

• Distribución: Se hace mediante las distintas tiendas oficiales como las aplicaciones nativas.

• Funcionamiento offline: puede trabajar sin conexión a internet perfectamente y funcionar online cuando lo requiera.

1.4.3 Desventajas

• Rendimiento menor: El rendimiento y la experiencia de usuario no pueden alcanzar los niveles de una aplicación 100% nativa Sin embargo herramientas de desarrollo para dispositivos móviles como PhoneGap, con sus continuas actualizaciones, buscan achicar esa pequeña brecha entre una aplicación híbrida y una nativa. Pero actualmente en dispositivos móviles denominados de gama media a alta, esta pequeña brecha prácticamente pasa desapercibida.

• Dificultad de publicación: Habitualmente los procesos de aprobación en las correspondientes App Stores para aplicaciones híbridas son más estrictos y pueden llegar a ser rechazadas si no queda clara la funcionalidad proporcionada mediante la carga de código remoto.

La figura 1.3 “arquitectura de las aplicaciones híbridas” representa cómo la combinación de los modelo nativo y web, constituyen el modelo híbrido, siendo PhoneGap en este caso el que permite la comunicación con los elementos del dispositivo.

Fig. 1.3 - Arquitectura de las aplicaciones híbridas (fuente: www.geospatialtrainges.com, 2013)



1.5 Cuentas de desarrollador en tiendas oficiales

Luego de presentar y explicar los tres modos de realizar aplicaciones para dispositivos móviles, ahora explicaremos en forma breve como es el sistema de monetización de las tiendas oficiales.

Cuando se desea publicar una aplicación en cualquiera de las tiendas oficiales, primero es necesario registrarse como desarrollador. Por ejemplo, en “Google Play” este procedimiento consiste en una cuota única de U$S 25, distinto a lo que ocurre en la tienda de “Apple” , donde publicar aplicaciones tiene un monto de U$S 99 por año. En cambio, en la “AppWorld” de “ BlackBerry”, la cuenta no tiene un costo por publicar aplicaciones, sólo tiene una comisión de un 30% por cada aplicación vendida, esto último sí coincide con el resto de las tiendas oficiales, donde el desarrollador sólo obtiene el 70% de ganancia por aplicación.

Algo preocupante ocurre en Argentina con las aplicaciones pagas para “Android” , esto se debe a que a partir del 27 de junio del 2013, los pagos de “Google Play” han sido vetados. Así lo ha comunicado Google a los desarrolladores argentinos, pudiéndose sólo desde ese momento publicar aplicaciones en forma gratuita



1.6 Comparativas y Conclusiones

En cuanto a las aplicaciones híbridas, en término de rendimiento o de experiencia de usuario están en disposición de alcanzar las mismas cotas que una aplicación 100% nativa. No sólo porque la tecnología (hardware) ha evolucionado desde los primeros frameworks, sino principalmente porque una aplicación híbrida puede incorporar, cuando sea recomendable, componentes nativos que se hagan cargo de funcionalidades específicas en las que prime el rendimiento o la imbricación con la plataforma.

Las ventajas de un desarrollo híbrido frente a uno 100% nativo son, por tanto:

• La experiencia de usuario se asemeja al nativo con un rendimiento óptimo • Menor tiempo de desarrollo y menores riesgos asociados con el lanzamiento de nuevas

aplicaciones. • Aprovechamiento del conocimiento y los recursos acumulados en el desarrollo con

tecnologías web. • Un núcleo de código común a todas las plataformas.

En la figura 1.4 se puede apreciar la “comparación híbrida y nativa”, tal como se viene

describiendo en este capítulo.

Fig. 1.4 - Comparación paradigma Híbrido/Nativo (fuente: www.ishamsaid.tumblr.com, 2013)

A su vez, las ventajas de una aplicación híbrida frente a una aplicación web enteramente creada con HTML5 son también contundentes:

• Posibilidad de instalar la aplicación en el dispositivo, lo que fomenta el uso habitual y habilita otras capacidades, como las notificaciones push.

• Posibilidad de hacer uso de las capacidades del sistema operativo (por ejemplo: acceso a la libreta de contactos) o del hardware subyacente (cámara, GPS, acelerómetro, etc.)

• Experiencia de usuario coherente con las prácticas habituales en cada plataforma.



• Posibilidad de uso sin conexión, cuando la funcionalidad lo permita. • Posibilidad de publicación y venta de la aplicación en las distintas “App Stores”.

Ante estos beneficios, no cabe considerar a las aplicaciones híbridas como una fórmula de

compromiso a medio camino entre las aplicaciones web y las 100% nativas, sino como una opción superior a ambas alternativas.

La figura 1.5 muestra como las aplicaciones nativas e híbridas poseen un mayor rendimiento frente a las aplicaciones web.

Fig. 1.5 - Comparativa paradigmas Web/Nativo/Híbrido (fuente: www.contunegocio.es, 2013)

A la hora de valorar por cuál tipo de tecnología apostar, hay que tener en cuenta diferentes

factores. Por ejemplo, las aplicaciones nativas reaccionan de un 10 a un 15% más rápido que las aplicaciones híbridas y además son más seguras. Por el contrario, el desarrollo híbrido es más económico si se crea un gran número de aplicaciones distintas para múltiples plataformas.

Un 6% de los desarrolladores están activamente creando aplicaciones híbridas. No obstante, la previsión según lo que señala un estudio de la consultora “Gartner” , es que el 50% de las aplicaciones para dispositivos móviles desarrolladas en 2015 serán híbridas, las cuales presentarán un interesante equilibrio entre desarrollo web basado en HTML5 y el potencial de las aplicaciones nativas (figura 1.6).

Las aplicaciones corporativas híbridas y web están experimentando un rápido crecimiento, lo cual puede estar señalando un movimiento hacia estos dos modelos de desarrollo para los próximos años.

El siguiente gráfico comparativo, describe el porcentaje de las aplicaciones nativas, webs e híbridas, según su categoría, usuario común y empresas.

En 2012, Ross Altman, Vicepresidente de Gartner dijo: “…las apps híbridas se desarrollarán para las aplicaciones móviles empresariales, mientras que las tecnologías web como



HTML5, serán de los lenguajes más utilizados para la creación de aplicaciones móviles en 2015” (www.gartner.com).

Fig. 1.6 - Naturaleza de las aplicaciones para el 2015 (fuente: www.gartner.com, 2012)



2. EXPLORANDO EL ESTADO DEL ARTE

2.1 Introducción

Las primeras herramientas para desarrollo de aplicaciones para dispositivos móviles que aparecieron en nuestra lista, son nombres muy conocidos y de amplia trayectoria en este campo. Podemos destacar las siguientes:

• Nokia QT SDK. • Java ME (Micro Edition) SDK.

• iPhone SDK. • iOS SDK. • Windows mobile SDK.

• Android SDK. • Samsung SDK

• BlackBerry SDK. Estas tecnologías fueron rápidamente descartadas debido a que no cumplían con la mayoría de las premisas planteadas. Entre ellas podemos destacar el hecho de no ser multiplataforma, requerir aprendizaje de lenguajes nuevos y diversos, y el hecho de no permitir el uso de las nuevas tecnologías Web.

Sin embargo se encontraron otras opciones de las cuales, se realizará el análisis y surgirá la tecnología que finalmente hemos escogido para desarrollar y desmenuzar a lo largo de los sucesivos capítulos.

A continuación presentamos las características de las plataformas de desarrollo estudiadas, sus beneficios y contraindicaciones. Al final del capítulo se llegará a una conclusión, el nombre de la opción elegida, y por supuesto el justificativo de la elección.

Desarrollo de aplicaciones híbridas multiplataforma con

Bender Gabriel Agustín – Chavez Alexis David

2.2 Corona SDK

Este framework está enfocado para elcomo para “Android” . Posee un crear juegos con tan sólo escribir unas pocas líneas de código. También se pueden crearaplicaciones en forma rápida y que sean multiplataforma con acceso a permitiendo de este modo poder manipular componentes de hardware como pueden ser, la cámara, GPS y acelerómetro.

2.2.1 Ventajas

• Integración automática con de clases y funciones para crear simples manipulaciones de la pantalla.

• Desarrollo Multiplataforma: Corona permite crear aplicaciones para plataforma Android tal como se menc

• Rendimiento: Corona está optimizado para hacer uso de las características de hardware de aceleración, dando como resultado un alto rendimiento en juegos y aplicaciones.

• Control del hardware del dispositivo: Posee componentes como cámara, acelerómetro,

• Fácil de aprender: Corona utiliza el lenguaje de programación Lua, que es potente y fácil de aprender.

2.2.2 Desventajas

• Como Ansca (compañía detrás de CoroAndroid, hay ciertas cosas que pueden no estar disponibles en la última versión del nativo. Sin embargo, la gente que se encuentra trabajando en Corona está agregando características de forma constante a m

• Sólo soporta las plataformas • Requiere aprender un nuevo lenguaje

2.2.3 Acerca de Lua

Lua es un lenguaje de scripting comúnmente utilizado para desarrollar juegos. Tiene una buena adopción por parte de la comunidad de desarrolladores sintaxis es parecida a JavaScriptAdobe Flash).


Chavez Alexis David

está enfocado para el desarrollo de aplicaciones y juegos tanto para . Posee un SDK que tiene un motor de física muy avanzado, el cual permite

crear juegos con tan sólo escribir unas pocas líneas de código. También se pueden crearaplicaciones en forma rápida y que sean multiplataforma con acceso a APIpermitiendo de este modo poder manipular componentes de hardware como pueden ser, la cámara,

Integración automática con “OpenGL-ES”: No habrá necesidad de llamar a un sin número de clases y funciones para crear simples manipulaciones de la pantalla.Desarrollo Multiplataforma: Corona permite crear aplicaciones para iOS (iPhone

tal como se mencionó en la presentación de este framework

Rendimiento: Corona está optimizado para hacer uso de las características de hardware de aceleración, dando como resultado un alto rendimiento en juegos y aplicaciones.

Control del hardware del dispositivo: Posee controles nativos para el acceso al dispositivo y componentes como cámara, acelerómetro, GPS, etc. Fácil de aprender: Corona utiliza el lenguaje de programación Lua, que es potente y fácil de

(compañía detrás de Corona) no es oficialmente parte ni de , hay ciertas cosas que pueden no estar disponibles en la última versión del

nativo. Sin embargo, la gente que se encuentra trabajando en Corona está agregando características de forma constante a medida que estén disponibles.

lo soporta las plataformas Android y IOS. Requiere aprender un nuevo lenguaje “Lua” .

Lua es un lenguaje de scripting comúnmente utilizado para desarrollar juegos. Tiene una a comunidad de desarrolladores y esto se debe, tal vez, a que su

JavaScript o ActionScript 3 (lenguaje de programación de la plataforma

para dispositivos HandHeld

Pág. 32

desarrollo de aplicaciones y juegos tanto para “iOS” que tiene un motor de física muy avanzado, el cual permite

crear juegos con tan sólo escribir unas pocas líneas de código. También se pueden crear API de otros frameworks

permitiendo de este modo poder manipular componentes de hardware como pueden ser, la cámara,

: No habrá necesidad de llamar a un sin número de clases y funciones para crear simples manipulaciones de la pantalla.

iOS (iPhone, iPad) y la framework.

Rendimiento: Corona está optimizado para hacer uso de las características de hardware de aceleración, dando como resultado un alto rendimiento en juegos y aplicaciones.

controles nativos para el acceso al dispositivo y

Fácil de aprender: Corona utiliza el lenguaje de programación Lua, que es potente y fácil de

no es oficialmente parte ni de Apple ni de , hay ciertas cosas que pueden no estar disponibles en la última versión del SDK

nativo. Sin embargo, la gente que se encuentra trabajando en Corona está agregando

Lua es un lenguaje de scripting comúnmente utilizado para desarrollar juegos. Tiene una y esto se debe, tal vez, a que su

(lenguaje de programación de la plataforma



2.3 Lungojs

Este es un framework JavaScript creado por “Tapquo” , una empresa española, con sede en Bilbao. Orientado a los desarrolladores que desean diseñar, crear y compartir aplicaciones a través de dispositivos. “Lungo” basa su filosofía en crear aplicaciones partiendo de la premisa de utilizar todo el potencial de los estándares más recientes de la Web (HTML5, CSS3 y JavaScript). A diferencia de otros, éste se centra en dispositivos móviles más recientes, no manteniendo retro compatibilidad para dispositivos que dentro de unos meses no tendrán demasiado uso. Esto lo hace bastante ligero y permite centrarse fácilmente en este tipo de desarrollo. La curva de aprendizaje es realmente rápida.

2.3.1 Ventajas

• Creación sencilla de aplicaciones web para dispositivos “iOS” (Apple), “Android” y “BlackBerry” .

• Desarrollo de aplicación HTML5 con estructura semántica en todo el proyecto, comenzando por la plantilla en HTML, apoyándose en los estilos CSS y terminando con su API JavaScript.

• Utiliza una librería para el manejo del “DOM” (Document Object Model) extremadamente ligera, llamada “QuoJS” (micro librería de JavaScript para móviles) también desarrollada por esta empresa española.

• Aprovecha las capacidades de los móviles actuales. • Implementación sencilla de características HTML5 como WebSQL, Orientación y Conexión. • Captura eventos táctiles como:

o Swipe (“deslizar” desplazamiento de derecha a izquierda o viceversa), o Tap (“tocar” la pantalla con un dedo y soltarla inmediatamente), o doble tap (tocar la pantalla dos veces).

• Puede extenderse la funcionalidad del framework mediante plugins, que en este entorno se llaman Sugars.

• Diseño totalmente personalizable.

• Permite distribuir las aplicaciones tanto en sitios web como en las distintas stores (Google Play, App Market, etc.).

2.3.2 Desventajas

• A pesar de ser muy parecido a “jQuery Mobile” , la cantidad de aplicaciones, plugins, y la participación de desarrolladores en foros, es infinitamente menor (está poco extendido).

• Su funcionamiento está limitado al navegador Google Chrome, en cambio en Internet Explorer y en Mozilla Firefox no ofrece un buen comportamiento.



2.4 Yui

La librería “YUI” (Yahoo User Interface) es un conjunto de utilidades y controles escritos en JavaScript que se utilizan para crear aplicaciones web dinámicas y complejas. Además, ésta librería incluye varias utilidades relacionadas con CSS, por lo que también se considera un framework CSS.

Yahoo distribuye gratuitamente esta librería en forma de software libre y bajo la licencia “BSD” (licencia de software otorgada para los sistemas BSD Berkeley Software Distribution), que permite utilizar YUI para proyectos de cualquier tipo, incluso comercial.

Lo mejor de YUI es que cuenta con el respaldo de Yahoo, ya que utiliza su librería en muchas de sus miles de millones de páginas vistas diariamente. Además, cuenta con una gran documentación que incluye cientos de ejemplos de uso.

YUI se ejecuta correctamente en todos los navegadores modernos e incluso en un navegador obsoleto.

2.4.1 Ventajas

• Funciona perfectamente para desarrollo web.

2.4.2 Desventajas

• No provee mecanismos de desarrollo híbrido.

• Baja integración con los componentes nativos del dispositivo. • Uso obligatorio de internet. • Baja fluidez.



2.5 Sencha Touch

Es un framework HTML5, basado en “Ext.js” (biblioteca de JavaScript desarrollada por Sencha), especialmente ideado para el desarrollo de aplicaciones web para entornos móviles que imitan la interfaz y experiencia de usuario de las aplicaciones nativas, diseñadas para ser fácilmente extensibles.

Inicialmente “Sencha” se desarrolló para navegadores basados en “webkit” , éste limitaba su uso sólo a dispositivos “iOS” , “Android” y “BlackBerry” pero desde la versión 2.2 se han deshecho de estas dependencias añadiendo “Windows Phone 8” al listado de dispositivos soportados.

Para facilitar el desarrollo de aplicaciones que ofrezcan una experiencia cercana a la de las nativas, se dispone de un amplio abanico de componentes visuales o widgets diseñados para su uso en dispositivos móviles que van más allá de componentes sencillos como botones o elementos de formulario.

Todos los elementos pueden ser fácilmente personalizables y extendidos para ajustarse mejor a las necesidades. También el “look & feel” (apariencia de las aplicaciones) de los componentes se adapta al tipo de dispositivo en el que se visualiza mediante la detección automática del mismo, junto con el consecuente uso de estilo CSS correspondiente.

Al momento de diseñar las vistas para una aplicación, la distribución de los componentes en las mismas se puede controlar asignando a los distintos contenedores, uno de los layouts que Sencha ofrece. La combinación de estos, junto con la posibilidad de anclar elementos a los extremos de la pantalla, permite posicionar los elementos que conforman la vista, de forma precisa.

Para completar la experiencia móvil, se proporciona la gestión de eventos específicos de entornos móviles y un sistema de animaciones poderoso que hace animaciones flexibles entre pantallas.

En cuanto a la arquitectura de las aplicaciones, se implementa el patrón Modelo Vista Controlador (MVC) para desvincular el código de los distintos ámbitos de la aplicación, mediante el uso de modelos, stores, controladores, vistas y profiles. Entonces decimos que:

• Los modelos son objetos simples que estructuran los datos de los que se alimenta la aplicación.

• Las stores serían comparables a una tabla de base de datos, donde cada registro es una instancia de un modelo. Se pueden alimentar de fuentes de datos internas, como el local storage del navegador o externas como “servicios REST” (Representational State Transfer, servicios web sin estado) o “servicios JSONP” (acrónicmo de JavaScript Object Notation with Padding), y abstraen al desarrollador de las funciones de bajo nivel para su sincronización.



• Los controladores se encargan de gestionar el flujo de la aplicación mediante rutas que soportan deep linking (enlaces profundo) y contienen toda la lógica de negocio de la aplicación.

• Las vistas se encargan de mostrar la información contenida en las stores y procesada por los controladores.

Finalmente, los profiles (perfiles) son elementos que permiten sobre escribir la implementación de los controladores y las vistas para los distintos dispositivos en los que se quiere desplegar la aplicación, consiguiendo de este modo adaptarse mejor a las características de cada dispositivo, como las distintas resoluciones de pantalla.

En cuanto a las API de Sencha, estas incluyen funciones que exponen al desarrollador los distintos sensores como el acelerómetro, cámara o GPS y servicios software como contactos, geolocalización o notificaciones. En este sentido, la versión 2.3, integra totalmente la conocida librería “Apache Cordova”.

2.5.1 Ventajas

• Permite crear aplicaciones complejas utilizando componentes predefinidos. • Evita el problema de tener que validar el código para que funcione bien en cada uno de los

navegadores (Firefox, IE, Safari, Opera etc.) al estar estandarizado. • Buen funcionamiento de las ventanas flotantes, superior a muchos otros frameworks. • Relación entre Cliente-Servidor balanceado: Se distribuye la carga de procesamiento entre

ellos, permitiendo que el servidor pueda atender más clientes al mismo tiempo, es decir, que se repartan el uso de recursos entre esas dos partes.

• Eficiencia de la red: Disminuye el tráfico en la red al contar las aplicaciones con la posibilidad de elegir qué datos desea transmitir al servidor y viceversa.

• Comunicación asíncrona: En este tipo de aplicación el motor de renderizado puede comunicarse con el servidor sin necesidad de estar sujeta a un clic o una acción del usuario, es decir, se puede cargar información sin que el cliente se dé cuenta.

• Hay una gran cantidad de componentes muy diversos, por lo que podemos crear el diseño de una web App de muchas formas diferentes con un código similar. Presenta un Soporte para geolocalización y mapas, incluyendo un componente que implementa el API de Google Maps.

2.5.2 Desventajas

• Al ser el primer framework que apareció, los errores o bugs presentes fueron corregidos sin poder apoyarse en otros.

• Es uno de los framewoks más pesados, es decir, que los recursos de sus aplicaciones ocupan más que los de la competencia, detalle por el cual, muchos usuarios pueden optar por la utilización de otras herramientas.

• Su principal inconveniente es que el mayor peso de las aplicaciones hace que sean lentas y se produzcan sobrecargas al usarlas.



2.6 Jquery Mobile

JQuery Mobile (JQM) es un usado por muchos desarrolladores de sitios webs, permite incrementar la velocidad de desarrollo, se agrega una capa más al jQuery tradicional, con ello se logra encapsular muchas tareas comunes que se realizan cuando se hace uso de

Con la aparición de “jQuery Mobile”de cada dispositivo y de este modo pueden dedicarse realmente a lo que importa.

JQM no sólo se trata de una capa para realizar código navegadores, sino un de conjunto de herramientas que simplifica el proceso de crear páginas para móviles, desde la escritura del propio código efectos dinámicos en los navegadores de manera automática. Además, muchos elementos del propio framework se los puede configurar directamente a través de atributos dispone de diversas herramientas de forma automática, sustituyendo de esta manera la floja apariencia de los elementos nativos de los navegadores de dispositivos móviles.

2.6.1 Ventajas

• Incluye, listos para usar, elementos como botones, barras de herramientas, formularios, listas y tipografías especialmente optimizadas y estilizadas para cuenta con un sistema de bloques ideal para construir plantillas.

• Permite construir aplicaciones aptas para todo tipo de plataformas casi sin esfuerzo, evitando preocupaciones por problemas de compatibilidad.

• Es muy fácil de aprender y utilizar. Si se tienen adecuados conocimientos de se pueden construir aplicaciones robustas en muy poco tiempo.

• El sitio web oficial cuenta con abundante

• Tiene soporte para “Ajax”• No requiere del uso de programas especiales, a diferencia de otras tecnologías, como

Flash, que exigen una aplicación para desarrollar sobre ellas.

• Soporte para los principales gestos

2.6.2 Desventajas

• Las funciones que ofrece son muchas, pero resvisual es estandarizado y no se integra con el de la plataforma. En algunos casos, no queda otra opción que usar JavaScriptdesarrollador.

• Como es necesario invocar a un archivo para utilizar sus funciones, ralentiza levemente la carga de la página.


Chavez Alexis David

es un Framework JavaScript basado en “jQuery”usado por muchos desarrolladores de sitios webs, permite incrementar la velocidad de desarrollo, se

tradicional, con ello se logra encapsular muchas tareas comunes que se realizan cuando se hace uso del lenguaje JavaScript.

“jQuery Mobile” , los desarrolladores se abstraen de la lógica específica de cada dispositivo y de este modo pueden dedicarse realmente a lo que importa.

lo se trata de una capa para realizar código JavaScript que funcione en todos los conjunto de herramientas que simplifica el proceso de crear páginas para

móviles, desde la escritura del propio código HTML, la maquetación con adores de manera automática. Además, muchos elementos del propio

se los puede configurar directamente a través de atributos HTML. En cuanto a dispone de diversas herramientas de forma automática, sustituyendo de esta manera la floja

encia de los elementos nativos de los navegadores de dispositivos móviles.

Incluye, listos para usar, elementos como botones, barras de herramientas, formularios, listas y tipografías especialmente optimizadas y estilizadas para aplicaciones móviles. Además, cuenta con un sistema de bloques ideal para construir plantillas. Permite construir aplicaciones aptas para todo tipo de plataformas casi sin esfuerzo, evitando preocupaciones por problemas de compatibilidad.

prender y utilizar. Si se tienen adecuados conocimientos de se pueden construir aplicaciones robustas en muy poco tiempo. El sitio web oficial cuenta con abundante documentación para aprender.

“Ajax” . programas especiales, a diferencia de otras tecnologías, como

, que exigen una aplicación para desarrollar sobre ellas.

Soporte para los principales gestos touch (gestos de toque).

Las funciones que ofrece son muchas, pero resultan difíciles de personalizar. Su aspecto visual es estandarizado y no se integra con el de la plataforma. En algunos casos, no queda

JavaScript simple para adaptar la aplicación a las necesidades de cada

ario invocar a un archivo para utilizar sus funciones, ralentiza levemente la


Pág. 37

“jQuery” . Es ampliamente usado por muchos desarrolladores de sitios webs, permite incrementar la velocidad de desarrollo, se

tradicional, con ello se logra encapsular muchas tareas comunes que

, los desarrolladores se abstraen de la lógica específica de cada dispositivo y de este modo pueden dedicarse realmente a lo que importa.

que funcione en todos los conjunto de herramientas que simplifica el proceso de crear páginas para

, la maquetación con CSS y la creación de adores de manera automática. Además, muchos elementos del propio

. En cuanto a CSS JQM dispone de diversas herramientas de forma automática, sustituyendo de esta manera la floja

encia de los elementos nativos de los navegadores de dispositivos móviles.

Incluye, listos para usar, elementos como botones, barras de herramientas, formularios, listas aplicaciones móviles. Además,

Permite construir aplicaciones aptas para todo tipo de plataformas casi sin esfuerzo, evitando

prender y utilizar. Si se tienen adecuados conocimientos de HTML y CSS,

para aprender.

programas especiales, a diferencia de otras tecnologías, como Adobe

ultan difíciles de personalizar. Su aspecto visual es estandarizado y no se integra con el de la plataforma. En algunos casos, no queda

simple para adaptar la aplicación a las necesidades de cada

ario invocar a un archivo para utilizar sus funciones, ralentiza levemente la



• Su manejo de CSS suele resultar innecesariamente complejo. A veces cuesta saber qué clases utilizar.

• No existen muchas plantillas prediseñadas sobre las cuales empezar a construir una aplicación.

• Obliga al desarrollador a adaptarse al estilo de programación (impone estilo).

• Obliga a tener todo el código HTML en un solo archivo. • Por sí solo, no permite generar aplicaciones, requiere usarse en conjunción con otra

tecnología.



2.7 Rhodes (Rhomobile)

Este es un framework de código abierto basado en en este capítulo, permite construir aplicaciones nativas para móviles con independencia del sistema operativo del dispositivo. Esto se logra utilizando esta plataforma intermedia para implementar una aplicación y una vez terminada, se exporta el código a la plataforma final donde será alojada, sea “iOS” , “Android” , “Windows Mobile” nativas se agilizan, ahorrando costos y tiempo de desarrollo, además al igual que los anteriores, aprovecha las capacidades de los dispositivos.

“Rhomobile”, suite de Motorola Solutionstiene como principal objetivo ofrecer aplicaciones para móviles de manera rápida sin perder la calidad en la experiencia del usuario, solventando así uno de los mayores problemas en el mundo de las aplplataforma dota a las compañías de un aumento de la productividad en sus desarrollos y una fácil adaptación de los programadores web a este nuevo entorno, de este modo, se logra una aplicación para los dispositivos más fuertes del m

La arquitectura del frameworkframeworks MVC. La aplicación se construye principalmente en interfaces de usuario son en HTMLobserva en la figura 2.1.

Fig. 2.1 - Arquitectura de Rhodes

Rhodes implementa un Modelo Vista Controlador muy estructurado, siendo fácil de entender ya que ambas partes están muy bien del lenguaje Ruby). También admite conexiones con


Chavez Alexis David

(Rhomobile)

de código abierto basado en “Ruby” , y como se viene mencionando en este capítulo, permite construir aplicaciones nativas para móviles con independencia del sistema

. Esto se logra utilizando esta plataforma intermedia para implementar una aplicación y una vez terminada, se exporta el código a la plataforma final donde será alojada, sea

“Windows Mobile” o “Windows Phone”. Los desarrollos de aplicacionativas se agilizan, ahorrando costos y tiempo de desarrollo, además al igual que los anteriores, aprovecha las capacidades de los dispositivos.

Motorola Solutions, compañía que ha desarrollado este tiene como principal objetivo ofrecer “Rhodes” como plataforma intermedia para desarrollar aplicaciones para móviles de manera rápida sin perder la calidad en la experiencia del usuario, solventando así uno de los mayores problemas en el mundo de las aplicaciones móviles. Esta plataforma dota a las compañías de un aumento de la productividad en sus desarrollos y una fácil adaptación de los programadores web a este nuevo entorno, de este modo, se logra una aplicación para los dispositivos más fuertes del mercado.

framework es fácilmente entendible y no difiere en mucho a los de otros La aplicación se construye principalmente en “Ruby” y las planillas para las

HTML, de ahí el servidor integrado en la arquitectura, tal como se

Arquitectura de Rhodes (fuente: www.rhomobile.com

implementa un Modelo Vista Controlador muy estructurado, siendo fácil de entender ya que ambas partes están muy bien definidas al igual que ocurre con

. También admite conexiones con Rhosync mediante JSON


Pág. 39

, y como se viene mencionando en este capítulo, permite construir aplicaciones nativas para móviles con independencia del sistema

. Esto se logra utilizando esta plataforma intermedia para implementar una aplicación y una vez terminada, se exporta el código a la plataforma final donde será alojada, sea

. Los desarrollos de aplicaciones nativas se agilizan, ahorrando costos y tiempo de desarrollo, además al igual que los framworks

, compañía que ha desarrollado este framework, como plataforma intermedia para desarrollar

aplicaciones para móviles de manera rápida sin perder la calidad en la experiencia del usuario, icaciones móviles. Esta

plataforma dota a las compañías de un aumento de la productividad en sus desarrollos y una fácil adaptación de los programadores web a este nuevo entorno, de este modo, se logra una aplicación

es fácilmente entendible y no difiere en mucho a los de otros y las planillas para las

o en la arquitectura, tal como se

.com, 2012)

implementa un Modelo Vista Controlador muy estructurado, siendo fácil de definidas al igual que ocurre con “Rails” (framework

JSON y la sincronización de



datos locales. Se dispone del Object Relational Manager (ORM) llamado Rhom muy similar al registro activo en Rails que permite escribir consultas con independencia de la base de datos.

• RhoSync es un servidor de sincronización móvil independiente que mantiene los datos de aplicaciones empresariales actualizadas y disponibles en los teléfonos inteligentes de los usuarios.

• JSON (JavaScript Object Notation), es un formato ligero para el intercambio de datos.

2.7.1 Ventajas

• Funciona bajo el principio cliente-servidor.

• Puede escribir código del lado del servidor usando Ruby. • Muy potente gracias al lenguaje Ruby. • La lógica del cliente es independiente del servidor.

• Desarrollo web tradicional.

2.7.2 Desventajas

• El rendimiento es bajo. • No entrega el código nativo de las aplicaciones (dificulta la flexibilidad), sólo los paquetes

son nativos. • Requiere conocimientos del lenguaje Ruby.



2.8 Titanium Appcelerator

Titanium Appcelerator es una herramienta de código abierto creada por “Appcelerator Inc”. Lanzada en diciembre del 2008. Permite desarrollar aplicaciones para móviles sobre las plataformas “iOS” , “Android” y “BlackBerry” con tecnologías Web. Permite escribir una sola vez el código en JavaScript y transformarlo a código nativo. También provee soporte para “Ruby” , “PHP” y “Python”.

Para poder programar, este framework provee un entorno de desarrollo “Titanium Studio” . Este surge de la compra de “Aptana” (uno de los IDE más famosos de la comunidad de desarrolladores) por parte de Titanium. Ofrece un ambiente puramente nativo, permitiendo hasta publicar una aplicación desde el propio IDE sin pasar por “Xcode” en el caso de iOS.

Contrario a otros frameworks, éste genera aplicaciones nativas, por lo que se ejecutan con el desempeño y ventajas de estas. Básicamente, desde el ambiente de desarrollo se crea la interfaz gráfica y se programa el comportamiento en JavaScript, en base a esto el motor de Titanium genera un proyecto nativo que se puede compilar utilizando las herramientas correspondientes para generar los ejecutables para cada plataforma. Estos ejecutables tienen la particularidad de que serán aceptadas en el Apple Store sin problemas.

Una de las grandes ventajas de programar íntegramente con JavaScript es que los desarrolladores pueden aprovechar los conocimientos existentes con el lenguaje y aplicarlos para crear aplicaciones móviles nativas, usando para ello una librería que hace de puente entre la aplicación y los controles del sistema, esto significa que las ventanas y demás controles visuales (botones, listas, menús, etc.) son nativos. Cuando se añade un botón, se crea un botón del sistema y se añade a la vista, esto provoca que tanto el tiempo de renderizado y de respuesta del usuario sean más rápidos.



En este framework, a diferencia de PhoneGap, no hay DOM ¿Por qué?, esto se debe a que ya no se está en el mundo HTML por lo que no se pueden usar librerías como jQuery que sirven para manipularlo (librerías orientadas al DOM), ya que el contexto de ejecución es JavaScript puro, no dentro de un documento HTML.

2.8.1 Ventajas

• Multiplataforma Móvil y también de escritorio. • El mejor rendimiento en cuanto a su aspecto y controles nativos.

• Buenos ejemplos (el KitchenSink tiene prácticamente todo lo que se puede hacer). • Gratis para uso personal y comercial. Licencia Apache 2.

2.8.2 Desventajas

• Requiere Mac y Xcode para empaquetar aplicaciones iOS. • La comunidad de desarrollo no tiene la misma envergadura que la comunidad de

PhoneGap.

• Puede que algo que se desarrolle para iPhone no funcione para Android, y viceversa. Los desarrollos de las librerías JavaScript evolucionan por separado y hay que mirar bien qué se puede hacer y cómo.

• A diferencia de PhoneGap, que sólo tiene una librería JavaScript para acceder a las características especiales del sistema, Titanium necesita además, librerías para manejar los controles nativos y su disposición en la pantalla, por lo que el desarrollo en general es más costoso.



2.9 PhoneGap

PhoneGap es una herramienta de desarrollo “Open Source” creada por la empresa Nitobi que luego fue adquirida por Adobe. Está formado por una serie de utilidades que ayudan a implementar y generar aplicaciones nativas para múltiples plataformas a través de las últimas tecnologías Web, y como se ha mencionado antes, estas son: HTML5, CSS3 y JavaScript, que se ejecutan dentro de un webkit del dispositivo móvil.

La interfaz de usuario es creada utilizando las tres tecnologías mencionadas. La base de una aplicación es la vista en un navegador web que ocupa el 100% del dispositivo (ancho y alto). Dicha vista es la misma utilizada por el sistema operativo nativo. En iOS, esta es la clase UIWebView de Objetive C, en Android es android.webkit.WebView. De todas formas existen ciertas diferencias para la visualización web en las diferentes plataformas, lo que se debe tener en cuenta en el desarrollo de la interfaz de usuario.

PhoneGap provee una interfaz de programación de aplicaciones (API) que permite acceder a las funcionalidades del sistema operativo nativo a través de JavaScript. Las aplicaciones son desarrolladas utilizando dicho lenguaje y de este modo la API del framework maneja la comunicación con el sistema operativo.

Como función extra, el mecanismo de comunicación permite el desarrollo de plugins nativos. Estos permiten escribir clases propias y sus correspondientes interfaces JavaScript para ser usadas con las aplicaciones.

Es posible desarrollar aplicaciones para los siguientes sistemas operativos:

• Android.

• iOS6 e iOS7. • Windows Phone 7 y 8. • BlackBerry OS y BlackBerry 10.

• Web OS. • Symbiam.

• Tizen • Bada, • Ubuntu Phone,

• Firefox Os

PhoneGap soporta la manipulación del DOM así que las interfaces de la aplicación se pueden hacer con frameworks compatibles (como jQuery Mobile y Sencha Touch, entre otros). Provee varias librerías JavaScript desarrolladas en el lenguaje específico de cada plataforma y por



ello permite acceder a algunas características de cada plataforma como GPS, file system, base de datos, contactos, acelerómetro, etc. El desarrollo de aplicaciones es muy parecido al desarrollo de una página web debido que se requiere de HTML5, JavaScript y CSS3. Tiene la ventaja de que la aplicación entera se puede desarrollar usando la mayoría de los navegadores para ver la visualización de la aplicación sin usar el emulador de cada plataforma.

2.9.1 Mejoras a partir de la Versión 3.0

Los cambios más importantes comienzan a partir de la versión 3.0, con la habilidad de elegir un subconjunto de API para minimizar el tamaño de las aplicaciones. También con el añadido de nuevas funciones; un InAppBrowser (conocido formalmente como pluginChildBrowser) y un API de Globalización. Este último obtiene información y desarrolla operaciones específicas a la zona en donde se encuentra el usuario. El InAppBrowser es un navegador web que despliega la aplicación internamente. Otra mejora es la capacidad para instalar PhoneGap desde el “NPM” (Node Package Manager), lo cual evita la necesidad de tener que descargar el archivo ZIP cada vez que se libera una nueva versión del framework.

2.9.2 Ventajas

• Es Open Source.

• La arquitectura de la aplicación cliente puede utilizar un modelo de página única donde toda la lógica de la aplicación está en una única página HTML.

• Facilidad de programación en HTML y JavaScript. • Posee una amplia comunidad de desarrollo.

• Es el framework que más plataformas soporta.

• Soporte de plugins y código nativo. • Variedad de herramientas y extensiones dentro de la comunidad.

• Se puede usar el mismo Código Base, para las plataformas soportadas por el framework.

• En caso de que se deba implementar una aplicación simple que será ejecutada en diferentes plataformas, PhoneGap es una buena opción.

• Se requiere menos habilidades de implementación sobre aplicaciones para móviles dentro del equipo de desarrollo.

• La aplicación cliente del framework se comunica con una aplicación en el servidor para recibir/enviar datos. La aplicación en el servidor gestiona la lógica de negocio y se comunica con la base de datos.



2.9.3 Desventajas

• Muchas de las características de las plataformas podrán no estar disponibles vía PhoneGap.

• Limitaciones de algunas características de HTML5. • Menor rendimiento final: El rendimiento no es igual al de una aplicación nativa ya que se

necesita interpretar el HTML en el navegador de cada plataforma.

• Deja de ser multiplataforma en los casos donde se debe realizar una implementación nativa por una funcionalidad no disponible para determinada plataforma.

• Dado que PhoneGap está diseñado para soportar diferentes plataformas, no contará con las características nuevas de cada plataforma tan pronto como estas se publiquen.

• Debido a que éste implementa sus aplicaciones en JavaScript, HTML y CSS, existen potenciales problemas de compatibilidad con browsers de diferentes plataformas.



2.10 Corolario de esta investigación

Mucho antes de conocer la gran variedad de librerías y frameworks para móviles, nos habíamos planteado ciertos objetivos de lo que pretendíamos hallar con esta tesis a la hora de elegir una herramienta para investigar y realizar nuestra aplicación. Sin querer en su momento dijimos “¡usemos PhoneGap!”, por un anuncio que habíamos visto por ahí y sin conocer esta ni la gran variedad de alternativas que existían. Al ir investigando y metiéndonos más en el tema, pudimos concluir que nuestros objetivos estaban bien encaminados y con la tecnología correcta.

Mucha información en la Web remarca gran parte de nuestros objetivos, como atributos de PhoneGap como por ejemplo, curva de aprendizaje achatada (fácil de aprender), permitir generar aplicaciones multiplataforma (PhoneGap es un framework que permite generar aplicaciones para todas las plataformas existentes en la actualidad), ¡es gratuito! Además posee una fuerte comunidad desarrolladora e incluye el uso de tecnologías nuevas como HTML5, CSS3 y JavaScript. También es compatible con otros frameworks como jQuery Mobile, y Sencha Touch entre otros. Otro punto clave es que permite generar aplicaciones híbridas, paradigma que ya se ha instalado y que parece ser el futuro no muy lejano de las aplicaciones para dispositivos móviles. Finalmente todas estas características nos permitieron decidir que la herramienta a investigar será PHONEGAP.

A continuación exploramos un poco el mundo de las tecnologías Web, su historia, nuevas características y su provecho sobre las aplicaciones para dispositivos móviles.



3. LENGUAJES Y TECNOLOGÍAS NECESARIOS

3.1 Introducción

En este capítulo abordaremos un poco la rica historia del lenguaje de marcado de hipertexto, mejor conocido como “HTML” . Recorreremos el camino que ha seguido desde su creación hasta la actualidad para consolidarse en su versión “HTML5” .

También se hará una breve introducción respecto a la más reciente versión del estándar de hojas de estilo en cascada, “CSS3”. Y por supuesto no puede faltar una mención referida a “JavaScript”.

La idea principal de este extracto es relacionar estas tres tecnologías básicas sobre las que se sustenta el paradigma híbrido. Además se apunta a poner el foco en las mejoras implementadas por cada una de ellas y que facilitan el desarrollo de aplicaciones para dispositivos móviles.



3.2 HTML5

3.2.1 Historia

HTML5 no es una nueva versión del antiguo lenguaje de etiquetas, sino un nuevo concepto para la construcción de sitios web y aplicaciones en una era que combina dispositivos móviles, almacenamiento y uso de datos en la nube, como así también grandes trabajos en red.

Todo este camino de evolución comenzó hace muchos años con una simple versión de HTML, propuesta para crear la estructura básica dá páginas Web, organizar su contenido y compartir información. El lenguaje y la Web misma nacieron principalmente con la intención de comunicar información por medio de texto.

El limitado objetivo de HTML motivó a varias compañías a desarrollar nuevos lenguajes y programas para agregar características a la Web nunca antes implementadas. Estos desarrollos iniciales crecieron hasta convertirse en populares y poderosas herramientas. Simples juegos y pequeñas animaciones pronto se transformaron en sofisticadas aplicaciones, ofreciendo nuevas experiencias que cambiaron el concepto de la Web para siempre.

De las opciones propuestas, “Java” y “Flash” fueron las más exitosas; ambas fueron masivamente adoptadas y ampliamente consideradas como el futuro de internet. Sin embargo, a medida que el nivel de usuarios de internet se iba incrementando en forma masiva, sobre todo para el campo estratégico de negocios y la interacción social, estas dos tecnologías mencionadas probaron ser una sentencia de muerte debido a sus limitaciones frente a este crecimiento de la Web.

El mayor inconveniente de Java y Flash se puede describir como una falta de integración. Ambos fueron concebidos desde el principio como complementos (plug-ins). No existía comunicación e integración alguna entre aplicaciones y documentos.

La falta de integración resultó ser crítica y preparó el camino para la evolución de un lenguaje que comparte espacio en el documento con HTML y no está afectado por las limitaciones de los plugins, un lenguaje interpretado llamado JavaScript, el cual es incluido en los navegadores. Claramente era la manera de mejorar la experiencia de los usuarios y proveer funcionalidad para la Web. Sin embargo, después de algunos años de intentos fallidos para promoverlo y algunos malos usos, el mercado nunca lo adoptó plenamente y pronto su popularidad declinó. Los detractores tenían buenas razones para oponerse a su adopción. En ese momento, JavaScript no era capaz de reemplazar la funcionalidad de Flash o Java, a pesar de ser evidente que ambos limitaban el alcance de las aplicaciones y aislaban el contenido Web. Populares funciones como la reproducción de videos se estaban convirtiendo en una parte esencial de la Web y sólo eran efectivamente ofrecidas a través de estas tecnologías.

A pesar del suceso inicial, el uso de Java comenzó a declinar. La naturaleza compleja del lenguaje, su evolución lenta y la falta de integración disminuyeron su importancia hasta el punto en que en la actualidad, ya no es usado en aplicaciones web de importancia. Sin Java, el mercado volcó su atención a Flash. Pero el hecho de que Flash comparte las mismas características básicas que su competidor en la Web lo hace también susceptible de correr el mismo destino.



Mientras esta competencia se llevaba a cabo en voz baja, el software para acceder a la Web continuaba evolucionando. Junto con nuevas funciones y técnicas rápidas de acceso a la red, los navegadores también mejoraron gradualmente sus intérpretes JavaScript. Más potencia trajo más oportunidades y este lenguaje estaba listo para aprovecharlas.

En cierto punto durante este proceso, se hizo evidente para algunos desarrolladores que ni Java o Flash podrían proveer las herramientas que ellos necesitaban para crear las aplicaciones demandadas por un número creciente de usuarios. Estos desarrolladores, impulsados por las mejoras que proveían los navegadores, comenzaron a aplicar JavaScript de una manera revolucionaria. La innovación y los increíbles resultados obtenidos llamaron la atención de más programadores. Pronto lo que fue denominado la Web 2.0 nació y la percepción de JavaScript en la comunidad de programadores cambió radicalmente.

JavaScript era claramente el lenguaje que permitía a los desarrolladores innovar y hacer cosas que nadie había podido hacer antes en la Web. En los últimos años, programadores y diseñadores web alrededor del mundo surgieron con las más increíbles técnicas para superar las limitaciones de esta tecnología y sus iniciales deficiencias en portabilidad. Gracias a estas nuevas implementaciones, JavaScript, HTML y CSS se convirtieron pronto en la más perfecta combinación para la necesaria evolución de la Web.

HTML5 es, de hecho, una mejora de esta combinación, el pegamento que une todo. Propone estándares para cada aspecto de la Web y también un propósito claro para cada una de las tecnologías involucradas. A partir de ahora provee los elementos estructurales, CSS se centra en cómo volver esa estructura utilizable y atractiva a la vista, y JavaScript tiene todo el poder necesario para dar dinamismo y construir aplicaciones web completamente funcionales.

Las barreras entre sitios web y aplicaciones finalmente han desaparecido. Las tecnologías requeridas para el proceso de integración están listas. El futuro de la Web es prometedor y la evolución y combinación de estas tres tecnologías (HTML, CSS y JavaScript) en una poderosa especificación está volviendo a internet la plataforma líder de desarrollo. HTML5 indica claramente el camino.



3.2.2 Evolución de la Web

La web ha sufrido grandes cambios desde su nacimiento y no sólo en su formato, sino también en las formas de navegación. Tradicionalmente, para interactuar con los contenidos de la Web eran necesarios una pantalla, un teclado y un mouse.

Las pantallas táctiles actualmente en distintos dispositivos móviles como smartphones, tablets e incluso laptops han modificado la forma en la que el usuario se relaciona con las páginas web. El hecho de poder interactuar con una interfaz usando solamente los dedos y a través de pantallas con diferentes formatos (vertical de un dispositivo móvil, horizontal de una laptop), ha implicado un buen número de desafíos en el campo del diseño.

Las innovaciones técnicas también han hecho posible que ahora se pueda acceder a internet no sólo desde los hogares u oficinas, sino desde cualquier lugar. Para pasar de su estado original a lo que es hoy, las distintas tecnologías tuvieron que evolucionar en función de los diversos usos que se le han ido dando a la Web, lo que fue permitiendo a los desarrolladores poder crear sitios y experiencias adaptadas a las nuevas necesidades.

Podemos estratificar la evolución de la Web en los siguientes tres puntos:

� Web 1.0: Siendo aquella donde sólo se colocaba información y el usuario no interactuaba, no había retroalimentación (páginas Web estáticas).

� Web 2.0: Denominada así a la Web que no sólo informa sino que permite la interacción del usuario, también es multimedia y las comunidades se forman a partir de conversaciones. En ella se creó la figura del “Prosumidor” (Prosumer) que es la persona que no sólo consume contenido sino que también lo produce. Facilita la convergencia entre los medios de comunicación y los contenidos. Algunos ejemplos clásicos son el podcasting, los blogs, etiquetas, marcadores sociales y votos realizados en la Web.

� Web 3.0: Llamada “Web semántica”. Simplemente es aquella donde el usuario define la información. Su principal activo son las bases de datos, las cuales se generan a partir de lo que acostumbramos a hacer en la Web. Ofrece contenidos relacionados con los gustos de cada uno. Pero ¿Qué significa “Web semántica”? La Web semántica es la idea de añadir metadatos semánticos a la World Wide Web. Esa información adicional (describiendo el contenido, el significado y la relación de los datos) debe ser dada de manera formal, de modo que posibilite ser evaluada automáticamente por máquinas. El destino es mejorar la Web al ampliar la interoperabilidad entre los sistemas informáticos y reducir la mediación de operadores humanos necesaria.

A continuación presentamos en una línea de tiempo la evolución de la Web:



La Web 1.0

1991

1994

1995

1996

1997

1998

1999

Aparición de AJAX, tecnología

relacionada con un objeto de

programación llamado

XMLHttpRequest. Usada en

productos como Exchange 2000,

IE 5 y Outlook Web Access.

Nacimiento de JavaScript por

medio del programador de

Netscape Brendan Eich.

También nace CSS (Cascading

Style Sheets).

Se crea el borrador del estándar

HTML 3.0 propuesto por la

W3C.

A finales de 1994 se publica

HTML 2.

Se publica CSS2.

En abril de 1998 se publica la

especificación de HTML 4.0 y en

diciembre de 1999 se presenta la

especificación de HTML 4.01.

Esta incluye mejoras a la versión

anterior.

Se publica el estándar HTML 3.2.

Se desarrolla XML (Extensible

Markup Language).

Berners-Lee fundó el Consorcio

World Wide Web (W3C).

Tim Berners-Lee publica por

primera vez HTML (Hyper Text

Markup Language).



La Web 2.0 y la Web 3.0

2000

2004

2005

2006

2008

2009

2010

2011

2012

XHTML (Extensible Hypertext

Markup Language) aparece como

el nuevo estándar de la Web. Miembros de las empresas Apple,

Mozilla y Opera fundan

WHATWG (Web Hypertext

Application Technology Working

Group) independientemente de la

W3C, y se proponen desarrollar

una nueva especificación

“HTML5”.

La W3C retoma la especificación

de la WHATWG y en el 2007 la

renombra como HTML5. Es por

eso que HTML5 está orientado al

desarrollo de aplicaciones en

Web.

Steve Jobs anuncia que no

incluirá flash en los dispositivos

Smart de Apple. Esto

desencadena que muchas

empresas se inclinen hacia

HTML5.

Disney compra la empresa

Rocket Pack por su motor de

juegos en HTML5.

Amazon crea una nueva

aplicación para leer libros en

HTML5 en modo offline desde el

browser.

En Junio Wix.com cuenta con

más de 1 millón de sitios en

HTML5 creados por usuarios.

Adopción formal del término

“AJAX” (Asynchronous JavaScript

And XML) establecido por Jesse

James Garrett, para una mejor

experiencia hacia el usuario con

un tiempo de carga más rápido.

El primer borrador de HTML5,

escrito por Ianhickson. Los

expertos dicen que HTML5 es

una tecnología en constante

evolución.

Nace Google Chrome, incluye

soporte para HTML5 y CSS3.

Firefox toma medidas para incluir

HTML5, posteriormente IE hace

lo mismo.

Youtube ofrece reproductor de

video HTML5.

Google abre su tienda en la Web

con HTML5, de aplicaciones para

dispositivos móviles con Android.

En septiembre el 34% de las 100

mejores webs son creadas en

HTML5.

Desde este año se habla del

Responsive Design, que ya no

sólo se refiere a adaptar los

diseños de las webs para

smartphones sino para el

creciente mundo de las tablets.



3.2.3 Desarrollo de Aplicaciones Móviles con HTML5

Como ya hemos mencionado, el estándar multimedia (video y audio, entre otros) y su interacción; esto significa que las aplicaciones web pueden desarrollarse con funcionalidades multimedia nativas, es decir, sinexterno. Como consecuencia de esto, las páginas o aplicaciones serán mucho más rápidas y con mayor calidad.

3.2.4 Aplicaciones Móviles Multiplataforma

Debido a las nuevas capacidades de interconexión con el (geolocalización, notificaciones, cámara, etc.), el desarrollo de aplicaciones para dispositivos móviles (figura 3.1). La principal ventaja es que se puede acceder desde cualquier dispostodas las versiones de la aplicación de acuerdo a la plataforma.

Fig

Ventajas de Desarrollo de Aplicaciones Móviles con HTML5

• Puede ser integrado con JavaScriptmultiplataforma.

• Código HTML limpio y consistente que se puede transferir a través de los múltiples entornos de forma predeterminada.

• Acceso a los componentes de audio y vídeo a través de s• Acceso a los componentes de interfaz de usuario avanzada.• Capacidades de almacenamiento fuera de línea y de servicios de geolocalización.


Chavez Alexis David

3.2.3 Desarrollo de Aplicaciones Móviles con HTML5

Como ya hemos mencionado, el estándar HTML5 está enfocado en mejorar los contenidos multimedia (video y audio, entre otros) y su interacción; esto significa que las aplicaciones web pueden desarrollarse con funcionalidades multimedia nativas, es decir, sin ningún módulo o externo. Como consecuencia de esto, las páginas o aplicaciones serán mucho más rápidas y con

3.2.4 Aplicaciones Móviles Multiplataforma

Debido a las nuevas capacidades de interconexión con el Hardware(geolocalización, notificaciones, cámara, etc.), HTML5 se presenta como una gran alternativa para el desarrollo de aplicaciones para dispositivos móviles (figura 3.1). La principal ventaja es que se puede acceder desde cualquier dispositivo y el usuario tendrá exactamente las mismas funciones en todas las versiones de la aplicación de acuerdo a la plataforma.

Fig. 3.1- HTML5 es multiplataforma

Ventajas de Desarrollo de Aplicaciones Móviles con HTML5

JavaScript y CSS3 para ofrecer desarrollo de aplicaciones móviles

limpio y consistente que se puede transferir a través de los múltiples entornos de forma predeterminada.

Acceso a los componentes de audio y vídeo a través de su código nativo.Acceso a los componentes de interfaz de usuario avanzada. Capacidades de almacenamiento fuera de línea y de servicios de geolocalización.


Pág. 53

está enfocado en mejorar los contenidos multimedia (video y audio, entre otros) y su interacción; esto significa que las aplicaciones web

ningún módulo o plugin externo. Como consecuencia de esto, las páginas o aplicaciones serán mucho más rápidas y con

Hardware de los dispositivos se presenta como una gran alternativa para

el desarrollo de aplicaciones para dispositivos móviles (figura 3.1). La principal ventaja es que se itivo y el usuario tendrá exactamente las mismas funciones en

para ofrecer desarrollo de aplicaciones móviles

limpio y consistente que se puede transferir a través de los múltiples

u código nativo.

Capacidades de almacenamiento fuera de línea y de servicios de geolocalización.



3.2.5 Mejoras aprovechables de HTML5

Una de las mejoras más importantes que ha traído HTML5 es la evolución de la “etiqueta input” . Tal es así que, si realmente se logra explorar al máximo estos input o cajas de texto, se puede obtener como resultado que la aplicación realmente parezca ser nativa.

El “input type search”, es un input enfocado a la búsqueda. Este input cuando se lo inserta en una página web, aparece la típica “X” para limpiar la búsqueda. En el contexto de las aplicaciones híbridas este trabajo hay que hacerlo a mano, porque dentro de los webview no aparece.

Como se observa en la figura 3.2, (izquierda) el teclado cambia y en vez de aparecer el botón de “go” o de “ir” (como cuando se busca en el navegador), se modifica el botón derecho de la parte inferior colocando “search”, o el símbolo de “enter” que es igual al nativo.

Con el “input type email”, figura 3.2 (centro), el teclado cambia en varios aspectos, por ejemplo, cuando se desea introducir un email, si o si se utilizará el símbolo “@” , entonces como primera impresión está claro que éste no puede faltar, porque no queda agradable ir a un botón secundario a buscar un “@” ya que sería una pérdida de tiempo.

El “input type url” figura 3.2 (derecha), se comporta muy parecido a lo que hace el input del “email” , sólo cambia un poco el teclado para enfocarlo a las terminaciones de páginas webs. Con esto se tiene un botón para seleccionar el “.com” y otro botón para la barra de separación.

<input type =“search”> <input type =“email”> <input type =“url”>

Fig. 3.2 – Tipos de inputs search, email y url (fuente: www.phonegapspain.com, 2013)



Si un usuario desea ingresar un número telefónico en una caja de texto, no se debe desplegar un teclado alfabético sino un teclado numérico, figura 3.5, esto lo realiza

Plataforma

Fig. 3.5 – Tipo de

En el caso que se desee ingresar un número en un determinado rango,

figura 3.6, es la solución permitiendo ingresar el tope mínimo y máximo permitidos.

Plataforma iOS

<input type=“number” min=“10” max=“

Fig. 3.6 – Tipo de input number


Chavez Alexis David

Si un usuario desea ingresar un número telefónico en una caja de texto, no se debe desplegar un teclado alfabético sino un teclado numérico, figura 3.5, esto lo realiza “input type tel”

Plataforma iOS Plataforma Android

<input type=“tel”>

Tipo de input tel (fuente: www.phonegapspain.com, 2013

En el caso que se desee ingresar un número en un determinado rango, es la solución permitiendo ingresar el tope mínimo y máximo permitidos.

Plataforma iOS Plataforma Android

<input type=“number” min=“10” max=“100”>

input number (fuente: www.phonegapspain.com


Pág. 55

Si un usuario desea ingresar un número telefónico en una caja de texto, no se debe desplegar “input type tel”.

Plataforma Android

, 2013)

En el caso que se desee ingresar un número en un determinado rango, “input type number” es la solución permitiendo ingresar el tope mínimo y máximo permitidos.

.com, 2013)



El “input type range”, actualmente es muy utilizado en tiendas online, por ejemplo, el típico filtro que se puede mover para buscar un precio. Las variables son: 3.7 se puede observar a dicha varipasando de 10 en 10 en positivo y de 10 en 10 en negativo, la segunda variable minimo valor que se tendrá, min=“1”

<input type =“range” step=“

Fig. 3.7 – Tipo de input range Antes de mencionar los input

que un usuario en un dispositivo móvil agregue una fecha, porque va a tener que insertar el año, mes y día, insertarlo uno por uno puede ser tedioso. En este caso del dispositivo enfocado a la lectura y/o escritura de una fecha o de una hora específica. En el caso del “Date” , se establece un mínimo y un máximo de fecha que se pueda introducir.

<input type=

Fig. 3.8 – Tipo de


Chavez Alexis David

, actualmente es muy utilizado en tiendas online, por ejemplo, el típico filtro que se puede mover para buscar un precio. Las variables son: step, en el ejemplo de la figura

puede observar a dicha variable con el valor step=“10” , lo que ocurre aquí pasando de 10 en 10 en positivo y de 10 en 10 en negativo, la segunda variable

min=“1” y el máximo max=“100” .

<input type =“range” step=“10” min=“1” max=“ 100”>

input range (fuente: www.phonegapspain.com

Antes de mencionar los input “Date” y “Time” figura 3.8 , cabe recordar que no es trivial que un usuario en un dispositivo móvil agregue una fecha, porque va a tener que insertar el año, mes y día, insertarlo uno por uno puede ser tedioso. En este caso HTML5 despliega el teclado nativo

a la lectura y/o escritura de una fecha o de una hora específica. En el caso se establece un mínimo y un máximo de fecha que se pueda introducir.

<input type=“date” min=“12/12/2000”>

Tipo de input date (fuente: www.phonegapspain.com


Pág. 56

, actualmente es muy utilizado en tiendas online, por ejemplo, el típico , en el ejemplo de la figura

, lo que ocurre aquí es que el input va pasando de 10 en 10 en positivo y de 10 en 10 en negativo, la segunda variable min indica el

100”>

.com, 2013)

, cabe recordar que no es trivial que un usuario en un dispositivo móvil agregue una fecha, porque va a tener que insertar el año,

despliega el teclado nativo a la lectura y/o escritura de una fecha o de una hora específica. En el caso

se establece un mínimo y un máximo de fecha que se pueda introducir.

.com, 2013)



3.3 CSS3

Es un lenguaje en cascada. No tiene orden y no tiene porqué tenerlo. Cada programador puede ir escribiendo estilos uno debajo de otro. Estos estilos se pueden dividir en uno o varios archivos.

CSS3 permite definir reglas y estilos de representación de cada aplicación que se desarrolle en diferentes dispositivos, pantallas de equipos de escritorio, laptops, y dispositivos móviles. Con estos estilos, por ejemplo, se le puede agregar color a un botón, redondearlo, darle sombra, etc.

La evolución de CSS a CSS3 se puede decir que fue obligada por la necesidad de dar soporte de transiciones como: desaparecer un elemento o hacer que aparezca poco a poco, etc. Otro motivo de esta evolución se debe a que empresas como Apple dejaron de dar soporte para Flash.

3.3.1 Diseño adaptativo

En la actualidad existe un nuevo término denominado “Responsive Web” (Web adaptativa). Plantea la solución a varios problemas, permitiendo que una aplicación, se pueda ver correctamente en todos los dispositivos móviles. Esto no quiere decir que se tenga que desarrollar una aplicación distinta para cada dispositivo o plataforma, sino que la Web detecta el ancho y alto de un dispositivo, si está rotado o no y si, por ejemplo, se tiene que desplegar una columna de los laterales.

Existe un módulo llamado “media queries” que es el que permite al contenido de una página o aplicación web adaptarse a condiciones como la resolución de pantalla. Se convirtió en un estándar recomendado por la W3C en junio del 2012 y es un principio básico de la tecnología de diseño web adaptativo.

En la figura 3.9 se puede observar los tipos de pantallas más comunes. Las media queries brindan las herramientas para poder adaptar la presentación de la aplicación tomando un CSS en concreto, según la resolución y orientación de la pantalla del dispositivo en cuestión.

Fig. 3.9 - Adaptación del contenido según la pantalla (fuente: www.blog.bitmarketing.es, 2013)



3.3.2 Mejoras aprovechables de CSS3

Border-radius: En las versiones anteriores de CSS lograr hacer un borde redondeado de un botón o en una caja, era un gran trabajo y a la hora de probarlo en los navegadores no quedaba en todos ellos de la misma forma, es decir, en Internet Explorer se veía de una forma, en Firefox no andaba y en Opera quizás hacía cualquier cosa.

Como una gran evolución, CSS3 permite hacer los bordes redondeados “border-radius” figura 3.10, de una manera muy sencilla, simplemente se asigna el número de pixeles que tiene que tener el radio del border y listo. También existe otra variante donde se pueden utilizar los border particionados, es decir, que se pueda trabajar con un radio en el borde superior izquierdo, con un radio en el borde superior derecho distinto y lo mismo para los bordes inferiores, pudiéndose asignar un radio distinto a cada uno.

Fig. 3.10 - Ejemplo del uso de la propiedad border-radius

Shadow: Esta propiedad tiene cuatro variantes que son desplazamiento horizontal,

desplazamiento vertical, difuminado y color de la sombra. Su utilización consume bastante procesamiento y si se desplaza una sombra en un dispositivo móvil, va a quedar muy vistosa. Por este motivo es mejor no utilizarla o simplemente hacer una línea semitransparente en cualquier editor de imagen, exportarla y colocarla como borde, de este modo se soluciona el problema de renderizado del shadow.

El ejemplo siguiente que se observa en la figura 3.11 tiene 5 px (pixeles) de derecha, 9 px hacía abajo, 3 px de difuminado y el color a utilizar, en este caso es el negro.

Fig. 3.11 - Ejemplo del uso de la propiedad shadow

.nombreclase{ Box-shadow: 5px 9px 3px #000; } - Desplazamiento horizontal de la sombra - Desplazamiento vertical de la sombra - Difuminado

- Color de la sombra

.nombreclase{ Border-radius: 50px; }

.nombreclase{ Border-top-left-radius: 50px; Border-top-right-radius: 40px; Border-bottom-right-radius: 30px; Border-bottom-left-radius: 20px; }



Backround-size: Este es un punto importante a la hora de colocar un fondo de pantalla a la aplicación, el cual ocasiona algunasun fondo de pantalla que se repita, no hay complicación alguna porque se tiene un ancho y un alto a repetir. El problema es cuando se diseña un fondo específico, sabiendo que existe una gran cantidad de resoluciones para que se ajuste el fondo de pantalla a la misma.

El background-size: autocolocar un ancho y alto determinado como en el siguiente ejemplo de la Figura 7.12, px respectivamente. En este caso si se rota el dispositivo, el fondo sigue siendo igual de grande. En el caso de que se necesite un ancho de parámetro se puede configurar en se le asigna de forma absoluta en lateral más grande del fondo al lateral más grande del dispositivo, en el ejemplo siguiente se tiene un fondo que es más ancho que alto, el problema que ocurre es que al no tener la misma proporción el dispositivo en vertical que en horizontal, se seguirá viendo una línea en blanco por no poder auto ajustarse.

Fig. 3.12 - Ejemplos de la propiedad El fondo de la pantalla se puede cambiar de dos formas, una es la explicada anteriormente

mediante media queries y la otra es mediante cuando el dispositivo ha rotado, esto se debe a que cambia la orientación. Como muestra el siguiente ejemplo, si el dispositivo se encuentra entre “portrait” (vista vertical), y se asigna un el fondo de pantalla, lo mismo para la orientación

Background

.nombreclaseBackground:url( images/fondo.jpg); }

Background-size: auto

.nombreclase{ Background:url( images/fondo.jpg); Background-size:auto }


Chavez Alexis David

Este es un punto importante a la hora de colocar un fondo de pantalla a la aplicación, el cual ocasiona algunas complicaciones a los programadores. Por ejemplo, si se coloca un fondo de pantalla que se repita, no hay complicación alguna porque se tiene un ancho y un alto a repetir. El problema es cuando se diseña un fondo específico, sabiendo que existe una gran antidad de resoluciones para que se ajuste el fondo de pantalla a la misma.

auto, mantiene el alto y ancho del dispositivo, también se le puede colocar un ancho y alto determinado como en el siguiente ejemplo de la Figura 7.12,

respectivamente. En este caso si se rota el dispositivo, el fondo sigue siendo igual de grande. En el caso de que se necesite un ancho de 275 px con un alto autoajustado, entonces el segundoparámetro se puede configurar en “auto” , de este modo se va autoajustar el alto frente al ancho que se le asigna de forma absoluta en pixeles. Por último el background-size: coverlateral más grande del fondo al lateral más grande del dispositivo, en el ejemplo siguiente se tiene

más ancho que alto, el problema que ocurre es que al no tener la misma proporción el dispositivo en vertical que en horizontal, se seguirá viendo una línea en blanco por no poder auto

Ejemplos de la propiedad background-size (fuente: www.phonegapspain

El fondo de la pantalla se puede cambiar de dos formas, una es la explicada anteriormente y la otra es mediante JavaScript, el cual consiste en obtener un valor

cuando el dispositivo ha rotado, esto se debe a que cambia la orientación. Como muestra el siguiente ejemplo, si el dispositivo se encuentra entre -90º y 90º entonces el dispositivo es

(vista vertical), y se asigna un CSS determinado al body, al headerel fondo de pantalla, lo mismo para la orientación “landscape” (vista horizontal).

Background-size: 275px 125px;

.nombreclase{ Background:url( images/fondo.jpg); Background-size:275px 125px

Background

.nombreclasebackground:url( images/fondo.jpg); Background}


Pág. 59

Este es un punto importante a la hora de colocar un fondo de pantalla a la complicaciones a los programadores. Por ejemplo, si se coloca

un fondo de pantalla que se repita, no hay complicación alguna porque se tiene un ancho y un alto a repetir. El problema es cuando se diseña un fondo específico, sabiendo que existe una gran

, mantiene el alto y ancho del dispositivo, también se le puede colocar un ancho y alto determinado como en el siguiente ejemplo de la Figura 7.12, 275 px y 125

respectivamente. En este caso si se rota el dispositivo, el fondo sigue siendo igual de grande. En con un alto autoajustado, entonces el segundo

va autoajustar el alto frente al ancho que size: cover, va a ajustar al

lateral más grande del fondo al lateral más grande del dispositivo, en el ejemplo siguiente se tiene más ancho que alto, el problema que ocurre es que al no tener la misma proporción

el dispositivo en vertical que en horizontal, se seguirá viendo una línea en blanco por no poder auto

phonegapspain.com, 2013)

El fondo de la pantalla se puede cambiar de dos formas, una es la explicada anteriormente , el cual consiste en obtener un valor

cuando el dispositivo ha rotado, esto se debe a que cambia la orientación. Como muestra el entonces el dispositivo está en

header o donde se encuentre (vista horizontal).

Background-size:cover

.nombreclase{ background:url( images/fondo.jpg);

Background-size: cover



Fig. 3.13 - Ejemplos de tipografías y el uso de font-face

Overflow: Esta propiedad permite hacer que no sólo el navegador tenga scroll sino que una capa la tenga por sí sola. Por ejemplo, si se tiene una capa rectangular dentro del body de una aplicación que no ocupa todo el alto, con un texto considerablemente grande como puede ser la descripción de un producto, entonces se puede conseguir que esa capa en si, tenga scroll sin tener que mover toda la aplicación. De este modo sólo se movería el contenido que se encuentra dentro de esa capa.

Una particularidad del overflow es que con su uso descrito anteriormente se evita perder la cabecera y el pie de página en el caso de que el contenido de la capa tenga un alto en pixeles mucho mayor que la del dispositivo mismo.

El Overflow no funciona en las versiones de “Android” inferiores a la 4.0 pero sí funciona perfectamente en las superiores a la 4.0. Sin embargo para llevar a cabo el uso de esta propiedad en versiones de inferiores a la 4.0, es necesario utilizar una librería llamada “Iscroll” , la cual permite tener dentro de una capa, todo el contenido que se desee por más largo que sea. También va a detectar que es más grande el contenido que el contenedor, permitiendo de este modo desplazar una capa que contiene todo el texto, dentro del contenedor.

@font-face{ font-family: “HelveticaNeueRegular”; url(“fonts/HelveticaNeueRegular.ttf”); format(“truetype”); } h1{ font-family: “HelveticaNeueRegular”; Font-size: 40px; Line-height: 80px; Color: #9ccbdb; Text-shadow: 0 1 px #4d4d4d; }



3.4 JAVASCRIPT

Es un lenguaje de programación orientado a objetos e interpretado, creado por “Brendan Eich” de “Netscape”. Inicialmente con el nombre de “Mocha”, el cual fue renombrado posteriormente a “LiveScript” , para finalmente quedar como JavaScript. Trajo consigo la gran particularidad de ejecutarse del lado del cliente (navegadores web) generando así una gran cantidad de beneficios subyacentes.

Prácticamente nació por la falta de velocidad de conexión que antes existía. Un ejemplo clásico de ello es que años atrás, a la hora de enviar un mail, primero había que incluir la dirección de correo de destino, seleccionar enviar, esperar que el servidor comprobara que la dirección ingresada estuviese bien confeccionada, validar la existencia del destinatario y, luego de esos pasos, finalmente enviar el email y posteriormente devolver la confirmación de que el correo había sido enviado. Este modo de operar era muy lento y poco eficiente. Fue en este terreno donde JavaScript empezó a tomar cuerpo, trabajando en el navegador web (el cliente) para realizar validaciones en el mismo y mejorar significativamente la interacción con el cliente, logrando páginas más dinámicas y respuestas más agiles.

JavaScript fue evolucionando con el tiempo y permitió la creación de un nuevo e importante concepto: “AJAX” , acrónimo de Asynchronous JavaScript And Xml (JavaScript asíncrono y XML), la cual es una técnica de desarrollo web para crear aplicaciones interactivas. Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador web de los usuarios mientras se mantiene la comunicación asíncrona con el servidor web en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas, mejorando la interactividad, velocidad y usabilidad en las aplicaciones.

Ajax es una tecnología asíncrona, en el sentido de que los datos adicionales se solicitan al servidor y se cargan en segundo plano sin interferir con la visualización ni con el comportamiento de la página, es decir de manera transparente para el usuario. JavaScript es el lenguaje en el que normalmente se efectúan las funciones de llamada de Ajax (figura 3.14), mientras que el acceso a los datos se realiza mediante “XMLHttpRequest”, objeto disponible en los navegadores actuales.

Fig. 3.14 - Diagrama básico AJAX



Websocket puede ser una variación o una alternativa a Ajax. Ofrece soporte para comunicaciones bidireccionales entre navegadores y servidores. La comunicación es realizada a través de conexiones TCP, sin enviar cabeceras HTTP, reduciendo de este modo la cantidad de datos transmitidos en cada llamada. Además la conexión es persistente, permitiendo a los servidores mantener a los navegadores permanentemente informados. Esto significa que no deberemos encargarnos de llamar al servidor a cada momento para obtener datos actualizados; en su lugar, el servidor mismo de forma automática nos enviará información acerca de la situación actual.

Websocket puede ser considerado por algunos como una mejora a la técnica Ajax, pero es en realidad una alternativa totalmente diferente de comunicaciones que permite la construcción de aplicaciones en tiempo real en una plataforma escalable (por ejemplo, videos juegos para múltiples jugadores, salas de chat, etc.).



4. PRESENTANDO PHONEGAP

4.1 Introducción

Ya hemos preparado el camino durante los capítulos predecesores, explicando los paradigmas actuales de desarrollo de aplicaciones móviles, investigando el estado del arte al respecto y explorando un poco las tecnologías en relación con el desarrollo web e híbrido. Es por eso que estamos en condiciones de adentrarnos con mayor profundidad en la herramienta que hemos elegido para su estudio.

En este capítulo conoceremos un poco más acerca de la historia de PhoneGap, sus orígenes y principales características. Describiremos los pasos a seguir para la instalación del mismo y sus principales comandos. Escrutaremos la estructura de este framework para entender su principio de funcionamiento y la filosofía de programación que propone. Esto es clave ya que, como todo framework, para poder aprovechar las ventajas del mismo, debemos entender cómo trabaja para adaptarnos a esta manera de hacer las cosas.

Cabe aclarar que la mayor parte del material presentado en este capítulo así como los ejemplos, fueron obtenidos de los sitios web: “http://docs.phonegap.com” y “http://cordova.apache.org”, en conjunción con las experiencias propias obtenidas del uso de PhoneGap.



4.2 ¿Qué es PhoneGap?

PhoneGap es un producto gratuito, open source (código abierto), que fue creado por una empresa canadiense llamada “Nitobi” , la cual hacía aplicaciones para dispositivos móviles para las plataformas “iOS” y “Android” . Esta empresa se dio cuenta de que el problema de la compatibilidad entre plataformas distintas era muy complicado de resolver utilizando tecnologías clásicas nativas. Entonces Nitobi desarrollo un producto para permitir la creación de aplicaciones nativas y luego poder distribuirlas en las tiendas de aplicaciones como “App Store” o “Google Play”, y todo esto utilizando un mismo código fuente. Así es como nace PhoneGap.

Nitobi en octubre del 2011 fue adquirida por la empresa “Adobe”, por lo tanto el proyecto PhoneGap pasó a estar dentro de sus productos. Con buen criterio, este donó PhoneGap a la fundación Apache (conocida fundación del mundo de código abierto y más que nada del mundo de los proyectos web), por lo que en la actualidad también es conocido con el nombre de “Apache Cordova” (aunque popularmente, dentro de la comunidad, los desarrolladores lo siguen denominando indistintamente con el nombre de PhoneGap).

PhoneGap es un conjunto de cosas. Por un lado es una librería de JavaScript que incorpora una API (Interfaz de Programación de Aplicaciones) disponible por encima de lo que HTML5 nos ofrece. Además es una librería nativa (escrita en el lenguaje nativo de cada una de las plataformas en la que es compatible), que permite hacer de puente entre JavaScript y ciertas funcionalidades a las que no tendríamos acceso desde el contexto web. Además es una herramienta que nos ayuda a compilar nuestra aplicación en distintas plataformas. Todo esto es parte de este framework gratuito y open source.

El proceso de desarrollo de una nueva aplicación normalmente implica codificarla utilizando JavaScript, CSS3, HTML5, imágenes u otros recursos usados en tecnologías web. Luego se compila mediante alguna de las opciones disponibles (punto que será tratado más adelante) obteniendo el instalable para la plataforma deseada. De esta manera este paquete podrá ser usado para instalarlo en equipos reales y/o distribuirlo a través de tiendas como App Store, Google Play, o bien, para permitir su descarga desde un sitio web.

Como hemos mencionado, con PhoneGap creamos aplicaciones para múltiples plataformas, utilizando el mismo código fuente (mismo código JavaScript, HTML5 y CSS3). Cabe destacar que esta herramienta utiliza los últimos estándares de HTML5 e implementa aquellos que aún no están disponibles para los navegadores web, como por ejemplo un estándar para acceder a la cámara de fotos. Es decir, cuando realizamos una aplicación con PhoneGap tendremos disponibles las correspondientes librerías de JavaScript que solventan las falencias que aún no están resueltas en HTML5 y que permiten mayor control y uso de los recursos del dispositivo.

Algo muy importante es que PhoneGap genera aplicaciones para dispositivos móviles de primera clase, esto significa que las aplicaciones que desarrollemos y compilemos, en teoría, no tendrán absolutamente nada que envidiarle a las aplicaciones desarrolladas totalmente con tecnologías nativas. Podemos decir que una aplicación PhoneGap a la vista del usuario es instalada, comprada y/o descargada en las tiendas como si fuera una aplicación nativa. De hecho lo es, y dependiendo de la interfaz gráfica que nosotros implementemos para nuestra aplicación, el usuario



podrá darse cuenta o no de que realmente el código subyacente está escrito basado en tecnologías web. Por lo tanto si usamos una librería que emule el “look and feel” de una interfaz nativa, el usuario verá por ejemplo una aplicación de iOS o Android como las que está acostumbrado a usar. Por supuesto tampoco estamos obligados a imitar ninguna interfaz ya que podemos desarrollar nuestro propio diseño con el estilo que deseemos.

4.2.1 PhoneGap y el “webview”

La idea en la que está basada la tecnología detrás de PhoneGap es más sencilla de lo que uno podría imaginarse. Todo consiste en generar un paquete nativo que abre un componente llamado webview a pantalla completa y navega una página web de manera local. Está presente en prácticamente todos los SDK (software development kit) para dispositivos móviles. A efectos prácticos, un webview no es más que un navegador sin controles de navegación que se gestiona desde el código de la aplicación y se puede incrustar dentro de aplicaciones nativas sin que la experiencia de usuario se vea disminuida.

De este modo, se puede concluir que las aplicaciones desarrolladas con PhoneGap son páginas web escritas en HTML5, JavaScript y CSS3, y ejecutadas dentro de una aplicación nativa, todo de manera transparente para el usuario. Es por lo dicho anteriormente que concluimos que las aplicaciones construidas con PhoneGap son esencialmente nativas, sin olvidar su parte web, que es sobre la cual los desarrolladores generamos el código con la lógica de la aplicación, obteniendo finalmente una mixtura a la que podemos clasificar como “aplicación híbrida” .

4.2.2 Características principales

PhoneGap no es una librería de interfaz de usuario, ni provee una función específica a tal efecto. Esta tarea es realizada manualmente mediante la utilización de HTML5, CSS3 u otras librerías que son compatibles con el framework (como jQuery Mobile o Sencha Touch entre otros). PhoneGap tampoco es un browser ni un motor de dibujado de páginas web. Lo que hace es utilizar el motor de renderización que cada una de las plataformas posee para mostrar la aplicación. Esto implica que podemos tener algunas diferencias de compatibilidad entre HTML5 y CSS3, y cada plataforma. Al respecto el sitio web http://www.mobilehtml5.org nos da cierta información de que cosas están disponibles o no en cada plataforma.

Otro aspecto importante es que a través de PhoneGap es posible desarrollar “plugins” para todo lo que no está implementado en HTML5. Esto nos da la posibilidad de crear nuestras propias librerías, con la desventaja de que debemos generar el código nativo para cada una de las plataformas que necesitemos. La ventaja es que la interfaz JavaScript es la misma sea cual sea la plataforma donde se ejecute la aplicación. Analizaremos el funcionamiento y la creación de plugins en lo sucesivo.

A colación de lo expuesto en el párrafo anterior, es importante mencionar que gran parte de las funcionalidades que provee PhoneGap están implementadas como plugins. Estos forman parte



de lo que se conoce como API de PhoneGap. Estas características forman parte de uno de los pilares del framework dado que, permite trascender la barrera de lo web para permitir la interacción directa con el dispositivo, creando un puente de interacción vía JavaScript, que permite interactuar con las funcionalidades del hardware del dispositivo tales como:

• Acelerómetro. • Cámara. • Brújula. • Estado de conexión. • Estado del dispositivo. • GPS. • Vibración y notificación.

Otra de de las cualidades que provee PhoneGap que no corresponde al hardware pero sí es

básico en cualquier dispositivo celular es poder hacer uso de la libreta de contactos que el usuario posea. Para llevar a cabo esto, nos provee las API necesarias para recuperar los contactos, actualizar su estado, crearlos e incluso eliminarlos. Dependiendo de la plataforma, el usuario recibirá algún pedido de permiso, para que la aplicación pueda acceder a esta información.

Llegado este punto es interesante repasar cómo ha cambiado la arquitectura de los plugins de PhoneGap. Cuando comenzamos a investigar esta herramienta se encontraba como última versión el release 2.6. Con el transcurrir de los meses se fueron liberando nuevas sub-versiones (2.7, 2.8, 2.9) con cada mes transcurrido. Es así que en poco más de tres meses (principios del julio de 2013) fue lanzada la versión 3.0. La misma trajo consigo muchos cambios. Figura 4.1. Entre ellos la manera en que las API eran concebidas. En la siguiente imagen se expresa esta nueva arquitectura.

Fig. 4.1 - Comparación de la arquitectura de los Plugins PhoneGap 2.x y 3.0

(fuente: www.activ.com.mx, 2013)

Como se puede observar en la imagen precedente, las versiones 2.x de PhoneGap (Cordova) contenían en su núcleo, las principales funciones de la API del framework y, por fuera del mismo, se agregaban los plugins propios del desarrollador. La última capa correspondía a la aplicación



misma y esta utilizaba las API y los plugins creados. A partir de la versión 3.0 esto cambio radicalmente. Las API se empezaron a concebir como plugins que el desarrollador podía incluir o no. Además las mismas se encuentran ahora al mismo nivel que los plugins creados por el desarrollador. Eliminando de esta manera del núcleo de PhoneGap las API, permitiendo de esta forma mayor flexibilidad al poder incluir sólo los componentes que realmente serán utilizados. Manteniendo el concepto de la capa superior representando a la aplicación en cuestión y, la misma, haciendo uso simplemente de plugins.

Sin lugar a dudas una de las características más importantes de PhoneGap es la línea de comandos. Si bien estuvo presente desde el principio, con el paso del tiempo fue mejorando y a partir de la versión 3.0 empezó a funcionar a través de la herramienta “NodeJs”, incorporando una gran cantidad de funcionalidades y flexibilidades que facilitan muchísimo la tarea de desarrollo. Podríamos decir que la línea de comandos o CLI (Commnand Line Interface) de PhoneGap es la columna vertebral del desarrollo de aplicaciones móviles. La misma permite la creación de un nuevo proyecto, su emulación, compilación, testeo, depuración (debugging), etc. Como consideramos que este es un tema que debe ser abordado primordialmente, será lo que nos ocupará en las posteriores líneas, donde explicaremos los requisitos para instalar PhoneGap y los principales comandos de la CLI que utilizaremos en el desarrollo de nuestra aplicación.



4.3 Instalando PhoneGap

Antes que nada presentaremos las plataformas para las cuales PhoneGap permite generar aplicaciones móviles. Entre paréntesis se muestra sobre qué plataformas de escritorio se puede trabajar.

• iOS (Mac). • Amazon Fire OS (Mac, Linux, Windows).

• Android (Mac, Linux, Windows). • BlackBerry 10 (Mac, Linux, Windows).

• Windows Phone 7 (Windows). • Windows Phone 8 (Windows).

• Windows 8 (Windows). • Firefox OS (Mac, Linux, Windows).

A continuación explicaremos todos los pasos requeridos para poder descargar e instalar todos los componentes necesarios para poder utilizar PhoneGap. Llegado este punto es importante y necesario aclarar sobre qué plataformas trabajaremos. En sintonía con la premisa planteada de utilizar tecnologías en el ámbito del código abierto, presentamos los sistemas operativos que utilizaremos:

• Ubuntu Linux , como sistema de escritorio.

• Android , como plataforma principal de instalación y testing de la aplicación.

Aclarado el punto anterior mostramos a continuación la lista de los prerrequisitos para poder realizar la instalación de PhoneGap correctamente.

� Instalación de Apache ANT.

� Instalación de Java.

� Instalación de Git.

� Instalación del SDK de Android.

� Instalación de compilador GCC.

� Instalación de NodeJs.



4.3.1 Prerrequisitos

4.3.1.1 Instalación de Apache ANT

Comenzaremos instalando ANT (Another Neat Tool) que es uno de los requisitos más sencillos de satisfacer. Haciendo uso de la shell escribimos:

$>sudo apt-get install ant

4.3.1.2 Instalación de Java

Proseguiremos con la instalación de la máquina virtual de java así como su kit de desarrollo ejecutando lo siguiente:

$>sudo apt-get install icedtea-7-plugin openjdk-7-jre openjdk-7-jdk

4.3.1.3 Instalación de Git

Con el fin de poder trabajar con NodeJs y el manejo de descargas de paquetes de PhoneGap, instalaremos “Git” como se muestra a continuación:

$>sudo apt-get install git

4.3.1.4 Instalación del SDK de Android

Hecho lo anterior proseguiremos con la instalación del SDK (software development kit) de Android. Aclaramos que este procedimiento debe repetirse por cada plataforma con la que se desee trabajar.

Lo primero que debemos hacer es descargar el SDK de Android, el cual se encuentra en el sitio web: “http://developer.android.com/sdk”. Luego hay que descomprimir el contenido en la siguiente carpeta (reemplazar usuario por su usuario Linux):

/home/usuario/sdk

Posteriormente agregamos las variables de entorno para que PhoneGap sepa dónde buscar

las herramientas del SDK. Crearemos a tal efecto la variable “ANDROID_HOME” con los paths (caminos) a los directorios “sdk” , “sdk/tools” y “sdk/platform-tools”.

Desde la shell ingresamos los siguientes comandos para tener acceso al archivo de configuración de nuestro usuario Linux:

$>cd ~ $>gedit .bash_profile



Una vez dentro del archivo oculto “.bash_profile”, ingresaremos las siguientes líneas y guardaremos los cambios:

export ANDROID_HOME=/home/usuario/sdk export PATH=$ANDROID_HOME/tools:$PATH export PATH=$ANDROID_HOME/platform-tools:$PATH

4.3.1.5 Instalación de GCC

Para poder instalar NodeJs, es necesario contar con GCC (GNU Compiler Collection). A tal efecto ejecutaremos el siguiente código:

sudo apt-get install build-essential

4.3.1.6 Instalación de NodeJs

Como último paso previo a la instalación de PhoneGap, es necesario descargar NodeJs desde el sitio web oficial “http://www.nodejs.org”. Una vez descargado, descomprimimos el paquete, y desde la shell nos posicionamos en el directorio y ejecutamos los siguientes comandos (el último requiere permisos de súper usuario):

$>./configure $>make $>sudo make install

Completados los pasos anteriores, podemos invocar a NodeJs mediante la línea de comandos

con “npm” (Node Package Manager), el cual es el manejador de paquetes de NodeJs. Esta herramienta nos facilitará los pasos siguientes.

4.3.2 Instalación de PhoneGap

Una vez instalado NodeJs, podemos usar su gestor de paquetes mediante el comando “npm” para poder instalar PhoneGap. Instalaremos también Apache Cordova para poder usar sus comandos. Por ese motivo desde la shell ejecutamos:

$>sudo npm install –g cordova $>sudo npm install –g phonegap

Mediante el argumento “-g” le decimos a npm que la instalación se realice globalmente para

que de ese modo, los comandos de cordova y phonegap estén disponibles para todos los usuarios desde la línea de comandos.



Finalmente para poder testear que todo ha ido bien podemos crear un proyecto con el nombre deseado.

$>phonegap create test

La respuesta de la shell debería ser similar a la siguiente: “[phonegap] missing library com.phonegap.helloworld/www/3.4.0 [phonegap]downloadinghttps://github.com/phonegap/phonegap-app-hello-world/archive/3.4.0.tar.gz... [phonegap] the options /home/usuario/Documents/test com.phonegap.helloworld HelloWorld [phonegap] created project at /home/usuario/Documents/test”

Para conocer qué versión de PhoneGap y Cordova tenemos, ejecutamos:

$>phonegap –v $>cordova –v

4.3.2.1 Aclaración antes de continuar

Dado que Apache Cordova es una distribución de código abierto de PhoneGap, y mantenida en paralelo con esta, se puede utilizar sin problemas en proyectos una u otra indistintamente. Dentro de un mismo proyecto se pueden ir alternando los comandos de ambas, sólo hay que estar seguro de estar trabajando con versiones con el mismo nivel de actualización.

A continuación mostramos los comandos más importantes que se deben conocer para poder desarrollar aplicaciones con PhoneGap. También analizaremos un poco la estructura de carpetas del framework.



4.4 Línea de comandos de PhoneGap

4.4.1 Creación de un proyecto

Para crear un nuevo proyecto primero debemos posicionarnos en el directorio de trabajo. El comando a ejecutar tiene la siguiente sintaxis:

$>phonegap create carpeta [id] [nombre]

Donde:

carpeta: Especifica el nombre del directorio para nuestro proyecto.

id: Identificador de la aplicación en formato de dominio inverso (opcional).

nombre: Es el nombre de la aplicación, este se mostrará al usuario (opcional).

Ejemplo:

$>phonegap create test com.test “primer test”

Como resultado de ejecutar la instrucción anterior, se generará la estructura de archivos tal como se observa en la siguiente la figura 4.2.

Fig. 4.2 - Principales carpetas de un proyecto PhoneGap

Por lo pronto, podemos adelantar que el directorio más importante y sobre el que más trabajaremos es “www” . Este albergará el código genérico de nuestra aplicación, es decir, todo el código HTML5, CSS3 y JavaScript, además de otros recursos que usemos.

En la siguiente figura vemos el detalle de cómo queda estructurada la carpeta “www” luego de aplicar el comando “cordova create”. Por defecto este crea todos los archivos y subdirectorios que se observan, y lo necesario para ejecutar la aplicación “HelloWorld” que PhoneGap instala por defecto.



Fig. 4.3 - Detalle de la carpeta www

De los directorios listados figura 4.3, los más trascendentes o mejor dicho, en los que escribiremos nuestra aplicación son: “css”, “img”, “js” y “res” , que albergan las hojas de estilo, las imágenes, los códigos JavaScript y los íconos de la aplicación respectivamente. Tanto el directorio “spec”, como los archivos “spec.html” e “icon.png” , pertenecen a la aplicación de muestra, por lo que pueden eliminarse.

El archivo config.xml contiene varios datos de configuración de la aplicación y no debe ser editado, al menos no por ahora. El fichero “index.html” es el punto de entrada a toda aplicación PhoneGap. En este caso contiene el código que permite la ejecución del programa de muestra “HelloWorld” . Cuando comencemos a codificar nuestra aplicación, sobre escribiremos este archivo con nuestro propio código de inicio.

4.4.2 Añadir una plataforma

Al momento de agregar una plataforma a nuestro proyecto, debemos posicionarnos dentro del directorio raíz del mismo. Luego se puede proceder a agregar la plataforma de destino para la aplicación a desarrollar. Este paso se debe repetir para cada una de las plataformas a implementar. En este ejemplo instalaremos la plataforma Android:

$>cordova platform add android

La ejecución del comando anterior generará dentro de la carpeta “platforms” (vista en la figura 4.4), el directorio “android” . Dentro del mismo se encuentra todo lo necesario para poder compilar nuestro proyecto a la plataforma Android.



El contenido de la carpeta “platform” NO debe ser modificado por nosotros. Se debe tener en cuenta que los archivos de esta carpeta son modificados con cada re-compilación.

A continuación se muestra en la figura 4.4, el resultado de la ejecución de este comando.

Fig. 4.4 - Contenido de la carpeta platform y su subcarpeta android luego de agregar esa plataforma

La figura 4.4 muestra cómo se agrega a la carpeta “platform” el subdirectorio “android” y dentro del mismo, una serie de archivos y carpetas. Nos interesa especialmente la carpeta “platforms/android/ant-build” la cual, luego de la compilación, nos entregará un paquete instalable para poder desplegar la aplicación desarrollada en un dispositivo.

4.4.3 Listar plataformas

Un comando muy útil a la hora de instalar plataformas es el que mostraremos a continuación. Nos permite no sólo saber qué plataformas se encuentran instaladas, sino además las que eventualmente podremos agregar:

$>cordova platform list

Si todo ha ido bien, este comando generará un texto similar al siguiente:

“Installed platforms: android 3.5.0 Available platforms: amazon-fireos, blackberry10, firefoxos, ubuntu”



Donde: Installed platforms: Se refiere a las plataformas instaladas. Available platforms: Son las plataformas disponibles para instalar.

4.4.4 Remover plataformas

Existe un comando para eliminar plataformas que hayamos agregado al proyecto y que por algún motivo deseemos quitar. La sintaxis es la siguiente:

$>cordova platform rm platform

La ejecución de este comando afectará directamente el contenido del directorio platform del proyecto, quitando del mismo la carpeta correspondiente a la plataforma elegida. Sólo se podrán eliminar las plataformas que aparezcan en el listado de plataformas instaladas (Installed platforms).

4.4.5 Instalación de un plugin

Hablábamos en la sección “Características principales” de cómo PhoneGap implementaba su API como plugins. Estos plugins también tienen su correspondiente comando de instalación:

$>cordova plugin add repositorio

Donde: repositorio: Puede ser un repositorio oficial de PhoneGap, un repositorio Git o bien una dirección local en la propia PC que contiene el código fuente del plugin.

A modo de ejemplo mostraremos como instalar el plugin oficial de PhoneGap correspondiente al manejo de los cuadros de diálogo (similares a alert, confirm, etc. en JavaScript):

$>cordova plugin add org.apache.cordova.dialogs

Si todo esta correcto, el resultado devuelto por la shell luego de la ejecución el comando debería ser similar al siguiente:

“Fetching plugin "org.apache.cordova.dialogs" via plugin registry Installing "org.apache.cordova.dialogs" for android”

El aspecto de la carpeta “plugins” figura 4.5, luego de ejecutar el comando “cordova plugin add” es mostrado a continuación. Nuevamente debemos enfatizar que esta carpeta tampoco debe ser modificada, pero se puede explorar para poder ver su contenido.



Fig. 4.5 - Detalle de la carpeta plugins luego de instalar el plugin Dialogs

4.4.6 Listar Plugins

Si necesitáramos conocer qué plugins tenemos instalados, simplemente escribimos:

$>cordova plugin list

El resultado en nuestro caso que sólo hemos instalado el plugin de diálogos es: “org.apache.cordova.dialogs 0.2.8 Notification” La gran utilidad de este comando queda probada a la hora de remover un plugin o bien, si se desea instalar el mismo en otra computadora de desarrollo. Basta con ver la primer parte del texto devuelto por el comando (destacado en negrita para que se vea más claramente) para conocer el argumento “repositorio” que debe ser utilizado como argumento.

4.4.7 Remover plugins

De igual modo que con las plataformas, para los plugins también tenemos una sentencia dedicada a su remoción:

$>cordova plugin rm repositorio

En nuestro caso, desinstalaremos el plugin que habíamos instalado:

$>cordova plugin rm org.apache.cordova.dialogs

Los plugins son una parte fundamental de este framework. Es por eso que más adelante, dedicaremos un capítulo para mostrar con más detalle cuestiones tales como: su principio de funcionamiento, configuraciones, ejemplos de plugins no oficiales e incluso una pequeña guía de cómo desarrollar uno.



4.4.8 Compilación de la aplicación

A continuación detallaremos los comandos que constituyen el proceso de preparación y compilación de una aplicación PhoneGap, siempre trabajando para la plataforma Android. El concepto es el mismo para cualquier otra plataforma, basta sustituir el argumento “android” por el de la plataforma deseada.

El comando presentado a continuación copia los archivos desde la carpeta www principal a la carpeta www de la plataforma Android, en este caso. Si se omite el argumento se aplica a todas las plataformas instaladas. Este es el paso previo para que el proyecto sea posteriormente compilado en cada SDK.

$>cordova prepare android

Luego podemos compilar la aplicación mediante el comando “cordova compile”. Nuevamente el destino es la plataforma Android. Si el argumento es omitido se aplicará a todas las plataformas instaladas. La ejecución de este comando genera un instalador que es depositado en la carpeta “platforms/android/ant-build” de nuestro proyecto. Suponiendo que la aplicación se llama “test” , entonces encontraremos en la carpeta antes nombrada el archivo “test-debug.apk” listo para ser instalado en un dispositivo real. A continuación la sintaxis del comando:

$>cordova compile android

Existe un atajo rápido que ejecuta el comando cordova prepare y luego aplica cordova compile sobre el proyecto para la plataforma elegida o todas las plataformas que se tengan instaladas si el argumento correspondiente es omitido. Eso se logra como sigue:

$>cordova build android

4.4.8 Correr la aplicación

El siguiente comando permite ejecutar la aplicación directamente sobre un dispositivo, para la plataforma Android, en este caso:

$>cordova run android

Esta sentencia intenta desplegar la aplicación en un dispositivo físico que se encuentre conectado a un puerto USB de la PC de desarrollo. En caso de no hallarse el mismo, abrirá el emulador de android para instalar y mostrar la aplicación en el mismo. Si se omite la plataforma de destino intentará ejecutarse para todas las plataformas que se tengan instaladas.



4.4.9 Emular la aplicación

Muchas veces no se cuenta con un dispositivo real de prueba o bien no presenta este las características que necesitamos (cantidad de memoria, versión de sistema operativo, tamaño de pantalla, etc.) para testear nuestra aplicación. Esto convierte, en nuestra opinión, al siguiente comando en uno de los más interesantes de los que provee este framework. Mediante el mismo se accede a la emulación de la aplicación en desarrollo con la gran ventaja de poder configurar completamente la máquina virtual. De esta manera permite observar cómo se comporta nuestra aplicación al ir cambiado las características del dispositivo virtual. La sintaxis es la siguiente:

$>cordova emulate android

La ejecución del comando anterior es equivalente a ejecutar la sentencia “cordova run –emulator android”. De no especificar la plataforma intentará abrir y desplegar el emulador de todas las plataformas instaladas.

Los SDK para las plataformas móviles, incluyen en su gran mayoría emuladores que ejecutan una imagen de un dispositivo. Este es el caso de Android, que permite configurar y lanzar un AVD (dispositivo virtual de Android) y provee un gestor que permite crear nuevos dispositivos y cambiar sus características. Se accede (previa configuración de la variable de entorno PATH vista en Instalación del SDK de Android) a este gestor mediante el comando:

$>android

Otro comando útil en la etapa de desarrollo a la hora de probar la aplicación es el siguiente:

$>cordova serve

Esta sentencia monta un servidor web en la dirección “localhost:8000”, y permite acceder al proyecto y emular la aplicación a través de un navegador web. Esto conlleva la enorme ventaja de que la emulación es mucho más rápida que con un dispositivo virtual y es especialmente recomendable para la depuración de la interfaz de la aplicación.

Para más claridad acerca de cómo es la apariencia de la página web que nos permite hacer lo comentado presentamos la figura 4.6.



Fig. 4.6 - Captura desde un browser de la página web “localhost:8000”

Podemos observar cómo el servidor web nos muestra tres secciones bien definidas:

• Package Metadata: Nombre y versión de la aplicación y el nombre del paquete. • Platforms: Links a las plataformas a emular (aquí sólo activa la de Android). • Plugins: Los plugins instalados en la aplicación (el de diálogos en este caso).

Con sólo hacer clic en el enlace “android” podremos ver la aplicación e interactuar con ella cual si fuera la aplicación real. Cabe aclarar que algunas funcionalidades podrían no estar disponibles por una cuestión de que esta emulación no permite simular cuestiones como por ejemplo de hardware o los contactos que si posee el AVD o un dispositivo físico.

Cuando se realiza un cambio en el código fuente si deseamos que se vea reflejado en el servidor web, debemos ejecutar la sentencia “cordova prepare” y luego volver a correr el comando “cordova serve”. Eso generará que despleguemos la siguiente secuencia de comandos cada vez que queramos ver reflejado dicho cambio:

$>cordova prepare $>cordova serve

En la práctica ejecutaremos la secuencia anterior con mucha frecuencia por lo que conviene crear un pequeño script que automatice un poco la tarea:

$>echo “killall node; cordova prepare; cordova serve &” > script $>chmod u+x script



En la primera línea del ejemplo anterior lo primero que hacemos es crear un archivo llamado “script” para:

• Matar al proceso node que pudiera estar ejecutando el servidor web (killall ), • preparar los archivos con las nueva modificaciones (prepare), • y volver a ejecutar el servidor web (serve) en segundo plano.

En la segunda línea le damos permiso de ejecución a nuestro script. Hecho lo anterior ya automatizamos nuestra tarea de actualización y re-arranque del servidor web de PhoneGap. Si deseamos ejecutar el archivo solo debemos hacer lo siguiente:

$>./script



4.5 Personalización de la plataforma

PhoneGap permite implementar fácilmente una aplicación para distintas plataformas pero a veces se necesita añadir ciertas personalizaciones, es decir deseamos implementar algún comportamiento específico para una determinada plataforma. Existe a tal efecto en la carpeta raíz de nuestro proyecto un directorio llamado “merges”. En este se pueden agregar archivos específicos para cada una de las plataformas instaladas, que serán copiados en los respectivos directorios de compilación.

4.5.1 Usando “Merges”

Para clarificar lo antes expuesto, propondremos un pequeño ejemplo. Supongamos que tenemos instaladas las plataformas “android” y “blackberry10” y que por algún motivo deseamos que el tamaño de la letra para la aplicación en su versión android sea de 14px (catorce pixeles).

Lo primero que hacemos es editar el punto de entrada al programa, el fichero “www/index.html”, agregando una línea que importe la hoja de estilos “extra.css” de la siguiente manera:

<link rel="stylesheet" type="text/css" href="extra.css"/>

Luego creamos el archivo “merges/android/extra.css” que contendrá el nuevo estilo para la

plataforma Android. Gráficamente se vera similar a la siguiente figura 4.7

Fig. 4.7 - Detalle de la carpeta merges y sus subdirectorios

Finalmente dentro del archivo “extra.css” introducimos el código que permitirá modificar el tamaño de la fuente para la aplicación en su versión Android:

@charset 'UTF-8';

body{ font-size: 14px; }

Podemos repetir este proceso tantas veces y para las plataformas que haga falta, separando así de manera muy limpia y sencilla las peculiaridades de cada una de ellas.



4.6 Scripts de compilación

Existe en nuestro proyecto creado con PhoneGap, un directorio más que aún no hemos analizado. Se trata de la carpeta “hooks” . La misma puede contener secuencias de comandos que permiten personalizar los comandos de PhoneGap. Los scripts se agregan al correspondiente directorio para ser ejecutados antes y después de los comandos que se corresponden con el nombre de una carpeta. Por ejemplo si deseamos que se haga algo después de la preparación, agregamos la carpeta “hooks/after_prepare” y dentro, el script que deseamos sea ejecutado.

Este esquema de trabajo es especialmente útil para la customización del proceso de compilación o incluso la integración con sistemas de control de versiones. Las opciones soportadas son mostradas en la tabla 4.1:

Tabla 4.1 – Referencia para la creación de hooks (ganchos)

Momento de ejecución Comando Carpeta a crear

build before_build/

compile before_compile/

emulate before_emulate/

plaform add before_platform_add/

ANTES DE… platform rm before_platform_rm/

platform list before_platform_ls/

plugin add before_plugin_add/

plugin list before_plugin_ls/

plugin rm before_plugin_rm/

prepare before_prepare/

run before_run/

serve before_serve/

build after_build/

compile after_compile/

emulate after_emulate/

plaform add after_platform_add/

platform rm after_platform_rm/

DESPUÉS DE… platform list after_platform_ls/

plugin add after_plugin_add/

plugin list after_plugin_ls/

plugin rm after_plugin_rm/

prepare after_prepare/

run after_run/

serve after_serve/

ANTES DE EMPAQUETAR build pre_package/



4.6.1 Usando hooks

Con el fin de ejemplificar el funcionamiento de esta característica de PhoneGap propondremos un pequeño ejemplo. Implementaremos un script que instale el plugin “dialogs” y sea ejecutado cada vez que se agrega una nueva plataforma.

Lo primero que haremos será crear la carpeta “after_platform_add” para que el script sea ejecutado después de agregar una plataforma. Luego crearemos dentro de la misma el fichero “instalar_plugins.js”. Hecho los pasos anteriores, el resultado sería el mostrado en la figura 4.8:

Fig. 4.8 - Detalle de la carpeta hooks y el uso de un script

Nota: el archivo “README.md” en la raíz de la carpeta “hooks” provee más información acerca de todos los eventos manejados.

A continuación abrimos el archivo “after_platform_add/ instalar_plugins.js” y lo editamos agregando un código que se encargará de instalar el plugin “dialogs” a cada nueva plataforma agregada. Dicho código se muestra a continuación:

#!/usr/bin/env node var pluginlist = [ "org.apache.cordova.dialogs" ]; function (error) { var fs = require('fs'); var path = require('path'); var sys = require('sys') var exec = require('child_process').exec; function puts(error, stdout, stderr) { sys.puts(stdout); } plugin list.forEach( function(plug) { exec("cordova plugin add " + plug, puts); });



5. LOS EVENTOS Y LA API DE PHONEGAP

5.1 Introducción

En este capítulo presentaremos todos los eventos y funciones que la API (Interfaz de programación de aplicaciones) de PhoneGap nos provee para el desarrollo de aplicaciones para dispositivos móviles. Estas constituyen el corazón de este framework. Veremos ejemplos concretos de su uso, y cómo nos habilitarán las diferentes capacidades de PhoneGap para transcender la barrera de JavaScript y conectarnos directamente con un dispositivo móvil, como si estuviéramos programando una aplicación nativa convencional.

Comenzaremos el capítulo explicando el manejo de eventos que permite PhoneGap, una parte muy importante del framework y que consideramos debe ser abordada primeramente. Posteriormente recorreremos en detalle la lista de “plugins” disponibles para el desarrollo de aplicaciones.

Le recordamos al lector que en las siguientes líneas nos centraremos en los detalles del desarrollo para la plataforma “Android” con el fin de que la explicación sea más clara. Sin embargo, a grandes rasgos, los contenidos desarrollados serán aplicables a cualquier otra plataforma.

Cabe aclarar que la mayor parte del material presentado en este capítulo así como los ejemplos, fueron obtenidos de los sitios web: “http://docs.phonegap.com” y “http://cordova.apache.org”, en conjunción con las experiencias propias obtenidas del uso de PhoneGap.



5.2 Eventos

5.2.1 Onload y ready

Para comenzar a trabajar con PhoneGap lo primero que se debe tener en cuenta es el manejo de eventos. Ellos nos permiten detectar el cambio de algún componente de la interfaz, un cambio de estado en el dispositivo o el pulsado de un botón en el mismo o quizás la carga de una página.

El primer evento que debemos detectar es cuando la página que contiene nuestro programa ha sido cargada, y de este modo conocer con certeza del momento justo en el que nuestra aplicación se encuentra totalmente operativa. A tal efecto existe el evento de JavaScript onload que puede ser capturado través de window.onload. El ejemplo mínimo de cómo funciona el mismo puede ser visto a continuación:

<!DOCTYPE html> <html> <head> <script type="text/javascript"charset="utf-8"src="cordova.js"></script> <script type="text/javascript"charset="utf-8"> window.onload = function( ){ alert(’El programa ha sido cargado!’); } </script> </head> <body> <h1>Ejemplo</h1> </body> </html>

Otra forma de resolver el problema anterior es mediante el uso de “JQuery” capturando el momento en que el documento está listo (ready). El código sería el siguiente:

<!DOCTYPE html> <html> <head> <script type="text/javascript"charset="utf-8"src="cordova.js"></script> <script type="text/javascript"charset="utf-8"src="jquery.js"></script> <script type="text/javascript"charset="utf-8"> $(document).ready( function ( ) { alert(’El programa ha sido cargado!’); }); </script> </head> <body> <h1>Ejemplo</h1> </body> </html>



5.2.2 Deviceready

Vamos a suponer ahora que ya capturamos los eventos “ready” u “onload” y necesitamos llamar a una función de PhoneGap propia de su API .Existe la posibilidad de que esta no llegue a ejecutarse. Esto se debe a que los eventos que capturamos tienen en cuenta sólo el momento en que el código HTML, JavaScript y CSS han sido cargados. Pero PhoneGap no sólo consta de una librería de JavaScript sino que además existe una librería asociada con todo el código nativo que PhoneGap nos provee. Es muy probable que la página web sea cargada más rápidamente que el código nativo, por lo que cuando se ejecute el evento “window.onload” (o $(document).ready) posiblemente falte un instante de tiempo para que la librería nativa de PhoneGap esté completamente funcional y la llamada a la función de la API fallará.

¿Cómo resuelve PhoneGap este problema?

Para solucionar este problema existe un evento llamado “deviceready” (dispositivo listo) que nos permitirá conocer el momento exacto a partir del cual se podrá hacer uso de la API de PhoneGap. A continuación se muestra un pequeño código de ejemplo:

<!DOCTYPE html> <html> <head> <script type="text/javascript"charset = "utf-8"src = "cordova.js"></script> <script type="text/javascript"charset="utf-8"src="jquery.js"></script> <script type="text/javascript"charset= "utf-8"> $(document).ready( function ( ) { document.addEventListener("deviceready", onDeviceReady, false); function onDeviceReady(){ alert(”La API de PhoneGap ha sido cargada!”); } }); // fin ready </script> </head> <body> <h1>Ejemplo</h1> </body> </html>

En el código anterior podemos ver cómo a través de la función del “DOM” (“Document Object Model”) document.addEventListener se agrega un nuevo evento llamado deviceready. Recibe tres parámetros:

• deviceready: Es el nombre del nuevo evento a capturar. • onDeviceReady: Función que será llamada al ocurrir el nuevo evento agregado.

• false: Indica que no se asociará la función onDeviceReady a otras llamadas posteriores del evento deviceready.

La función onDeviceReady contendrá todo el código que haga uso de las API de PhoneGap y nos asegurará que al momento de ejecutarse, la librería necesaria se encontrará disponible y lista para su uso.



5.2.3 Captura de botones

Una parte muy importante de las funcionalidades provistas por PhoneGap es el enlace a los botones físicos de los distintos dispositivos. Existe un listado de eventos que se pueden capturar y determinar así el momento en que determinado botón es pulsado y, sobre-escribir de ser necesario, el comportamiento predeterminado del mismo. Dicha lista se presenta a continuación, donde se aclara además para qué plataforma está disponible dicho evento:

• backbutton: Botón regresar (disponible en plataformas: Amazon Fire OS, Android, BlackBerry10, Windows Phone 8).

• menubutton: Botón menú (disponible en plataformas: Amazon Fire OS, Android, BlackBerry10).

• searchbutton: Botón Buscar (disponible sólo para Android). • startcallbutton: Botón llamar (disponible sólo para BlackBerry10). • endcallbutton: Botón finalizar llamada (disponible sólo para BlackBerry10). • volumedownbutton: Botón bajar volumen (disponible sólo para BlackBerry10). • volumeupbutton: Botón subir volumen (disponible sólo para BlackBerry10).

A continuación presentamos un pequeño ejemplo con la captura del evento “backbutton”

(botón regresar). En la plataforma “Android” el comportamiento por defecto de este botón hará que la página actual sea sustituida por la anterior. Cambiaremos este comportamiento para que al presionarse, la aplicación sea cerrada. El resto de los eventos se capturan de forma análoga al código que presentaremos por lo que no amerita un ejemplo para cada uno de ellos.

<!DOCTYPE html> <html> <head> <script type="text/javascript"charset = "utf-8"src = "cordova.js"></script> <script type="text/javascript"charset="utf-8"src="jquery.js"></script> <script type="text/javascript"charset= "utf-8"> $(document).ready( function ( ) { document.addEventListener("deviceready", onDeviceReady, false); function onDeviceReady( ){ document.addEventListener("backbutton",onBackButton, false); } function onBackButton( ){ navigator.app.exitApp(); } }); // fin ready </script> </head> <body> <h1>Ejemplo</h1> </body> </html>



Se puede ver cómo se agrega el evento “backbutton” dentro de la función “onDeviceReady”. De esta manera se asocia el evento sólo cuando la correspondiente librería nativa ha sido cargada. Finalmente vemos como la función “onBackButton” posee solamente una línea que es la que permite mediante el objeto “navigator” (objeto creado por JavaScript) salir de la aplicación.

5.2.4 Pause y resume

Estos dos eventos son útiles si se desea realizar alguna tarea específica cuando nuestra aplicación pasa a un segundo plano (“pause”) y/o regresa al primer plano (“resume”). El concepto para su aplicación es exactamente el mismo que el visto en la sección “Captura de botones”. La redefinición de estos eventos se habilita agregando los siguientes códigos dentro de la función “onDeviceReady” de nuestro código:

document.addEventListener("pause", onPause, false);

document.addEventListener("resume", onResume, false);

Luego resta simplemente implementar las funciones “onPause” y “onResume” con el

código que deseamos sea ejecutado.



5.3 La API de PhoneGap

5.3.1 Device-motion (Acelerómetro)

El acelerómetro es un pequeño artefacto que hoy en día cualquier dispositivo móvil posee. Consta básicamente de tres sensores, uno para cada una de las tres dimensiones espaciales que puede tener un dispositivo en determinado momento. En la práctica permite conocer la posición de un dispositivos respecto a los tres ejes conocidos comúnmente como “X”, “Y” y “Z” . En la figura 5.1 se muestra la descripción gráfica de un dispositivo con respecto a dichos ejes:

Fig. 5.1 - Representación gráfica de los ejes imaginarios.

PhoneGap nos permite acceder a las funciones del acelerómetro de los dispositivos mediante el plugin “device-motion”. Para instalarlo desde la shell nos posicionamos en el directorio raíz de nuestro proyecto e ingresamos el siguiente código:

$>cordova plugin add org.apache.cordova.device-motion

Métodos para el manejo del Acelerómetro

• accelerometer.getCurrentAcceleration • accelerometer.watchAcceleration • accelerometer.clearWatch

Con el método “getCurrentAcceleration”, obtenemos la posición relativa del dispositivo respecto a los tres ejes imaginarios en un momento dado. Para entender mejor su principio de funcionamiento mostraremos un pequeño ejemplo que permite obtener y mostrar la posición del dispositivo y su “timestamp” (marca de tiempo). A partir de ahora con fines prácticos omitiremos las etiquetas HTML del código para mayor simplicidad y visibilidad.



$(document).ready( function ( ) { document.addEventListener("deviceready", onDeviceReady, false); function onDeviceReady( ){ navigator.accelerometer.getCurrentAcceleration(onSuccess, onError); } function onSuccess(acceleration) { alert('Acceleration X: ' + acceleration.x + '\n' + 'Acceleration Y: ' + acceleration.y + '\n' + 'Acceleration Z: ' + acceleration.z + '\n' + 'Timestamp: ' + acceleration.timestamp + '\n'); } function onError() { alert('Error al capturar posición!'); } }); // fin ready

El código precedente invoca el método “getCurrentAcceleration” (siempre dentro del contexto deviceready), el cual en caso de tener éxito, invocará la función “onSuccess”. Esta se encargará de mostrar los valores “acceleration.x”, “acceleration.y” y “acceleration.z”, para obtener la posición del dispositivo en los ejes “x”, “y” y “z” respectivamente, junto con la variable “acceleration.timestamp”.

Se puede observar un segundo parámetro (“onError” ) en la llamada “getCurrentAcceleration”. Este corresponde a la función que será invocada en caso de que por algún motivo el método no pueda obtener la posición del dispositivo móvil. En este caso sólo se muestra un mensaje de error, pero se puede implementar un código de mayor utilidad si hiciera falta.

Existe otro método que también permite capturar la posición del dispositivo llamado “watchAcceleration”. La gran diferencia con respecto a la llamada anterior es que habilita la observación (watch) de los cambios en la posición por intervalos de diez segundos (default, salvo que se altere la opción pertinente).

Para verlo en acción presentaremos el siguiente código que hace exactamente lo mismo que el presentado anteriormente sólo que, además, repetirá el proceso mostrando los cambios de posición cada tres segundos gracias a la única opción configurable, denominada “frequency”. Cabe aclarar que la misma espera un número que representa el intervalo de tiempo en milisegundos entre las diferentes re-llamadas a la función. “watchAcceleration”.

$(document).ready( function ( ) { var watchID = null; document.addEventListener("deviceready", onDeviceReady, false); function onDeviceReady( ){ var options = { frequency:3000 }; // actualizar cada 3 segundos



watchID = navigator.accelerometer.watchAcceleration(onSuccess, onError, options); document.addEventListener("backbutton", stopWatch, false); // Para detener captura } function onSuccess(acceleration) { alert('Acceleration X: ' + acceleration.x + '\n' + 'Acceleration Y: ' + acceleration.y + '\n' + 'Acceleration Z: ' + acceleration.z + '\n' + 'Timestamp: ' + acceleration.timestamp + '\n'); } function onError() { alert('Error!'); } function stopWatch () { if (watchID) { navigator.accelerometer.clearWatch(watchID); watchID = null; } } }); // fin ready

Observaremos primeramente la función “onDeviceReady” del código anterior. En la primera sentencia se observa la creación de la variable “option” que contendrá a su vez la opción “frequency” y nos permitirá setear el intervalo de tiempo en tres mil milisegundos (tres segundos). Luego está la llamada a “watchAcceleration” que a diferencia de “getCurrentAcceleration”, devuelve un identificador que tiene una utilidad que mostraremos en breve. Posteriormente seteamos la función “stopWatch” para que se active al presionar el botón retroceso. Dicha función tiene por objetivo detener la llamada watchAcceleration.

Las funciones “onSuccess” y “onError” hacen exactamente lo mismo que antes, por lo que no requiere mayor explicación.

Existe un tercer método importante de esta parte de la API llamado “clearWatch”. Este permite detener la llamada “watchAcceleration” mediante el uso del identificador “watchID” , y eso es precisamente lo que hace la función “stopWatch”.

5.3.2 Camera (Cámara)

Como ya todos sabemos desde hace algunos años los dispositivos móviles vienen equipados con, al menos, una cámara fotográfica. Los fabricantes han logrado aumentar tanto la calidad de las mismas que es indispensable contar con una herramienta que permita a nuestra aplicación en desarrollo, acceder a dicho artefacto. Como era de sospechar, PhoneGap implementa también a tal efecto un plugin para la captura de imágenes mediante la cámara de nuestro dispositivo.



El comando para instalar este plugin es el siguiente:

$>cordova plugin add org.apache.cordova.camera

Métodos para la utilización cámara

• camera.getPicture • camera.cleanup

El método “getPicture” captura una foto usando la cámara, o bien, recupera una foto de la galería de imágenes del dispositivo. La imagen capturada es transferida a la función “cameraSuccess” como un String codificado en base 64, o como la URL de archivo de imagen. La llamada a esta función tiene la siguiente forma:

navigator.camera.getPicture( cameraSuccess, cameraError, [ cameraOptions ] ); Los argumentos recibidos por la función significan lo siguiente:

• cameraSuccess: Función llamada en caso de éxito, normalmente contiene el código que hace algo con la imagen obtenida.

• cameraError: Función llamada en caso de error. • cameraOptions: Opciones de configuración (Opcional).

El parámetro “cameraOptions” es el más interesante de los tres ya que nos permite configurar el comportamiento de la llama “getPicture”. A continuación mostraremos la tabla 5.1 que resume las opciones soportadas:

Tabla 5.1 – Opciones para “getPicture”

Opción Valores Detalle

quality 0 - 100 Valor que representa en porcentaje la calidad con que se guarda la fotografía obtenida

Camera.DestinationType.DATA_URL Retorna una imagen como una cadena codificada en base64

destinationType Camera.DestinationType.FILE_URI Retorna el URI (Uniform Resource Identifier) de un archivo de imagen

Camera.DestinationType.NATIVE_URI Retorna el URI de una imagen nativa (por ej.: assets-library:// en iOS)

Camera.PictureSourceType.PHOTOLIBRARY Buscar imagen en la galería de fotos

sourceType Camera.PictureSourceType.CAMERA Tomar una imagen con la cámara

Camera.PictureSourceType.SAVEDPHOTOALBUM Buscar imagen en el álbum de fotos

allowEdit true Permitir edición simple antes de seleccionar la imagen



false No permitir edición simple antes de seleccionar la imagen

encodingType Camera.EncodingType.JPEG Retorna una imagen codificada en JPEG

Camera.EncodingType.PNG Retorna una imagen codificada en PNG

targetWidth numero natural Ancho en pixeles para escalar la imagen. Debe ser usado junto con targetHeight

targetHeight numero natural Alto en pixeles para escalar la imagen. Debe ser usado junto con targetWidth

Camera.MediaType.PICTURE Permite la selección de una foto solamente

mediaType Camera.MediaType.VIDEO Permite la selección de un video solamente

Camera.MediaType.ALLMEDIA Permite la selección de cualquier formato

correctOrientation true Rota la imagen a la correcta orientación del dispositivo durante la captura

false Toma la foto respetando la orientación que el dispositivo tiene durante la captura

saveToPhotoAlbum true Guardar la imagen en el álbum de fotos del dispositivo después de la captura

false Permite guardar la imagen en una locación diferente luego de su captura

popoverOptions true Permite usar la opción “popover” para definir la locación en iPad (solo para IOS)(*)

false No permite la opción "popover"

cameraDirection Camera.Direction.BACK Abre la cámara trasera por defecto para tomar la fotografía

Camera.Direction.FRONT Abre la cámara frontal por defecto para tomar la fotografía

(*) La opción “popover” sólo está disponible para la plataforma iOS y no será abordada en este trabajo. Para más información al respecto recurrir a “http://cordova.apache.org/docs/en/edge/”

A continuación presentaremos un breve ejemplo de la utilización del comando “getPicture”. Lo que haremos será tomar una foto con la cámara y guardarla en el álbum de fotos del dispositivo, al mismo tiempo que dicha imagen se mostrará en el objeto HTML cuyo id es “imagen_ejemplo”.

$(document).ready( function ( ) { var pictureSource; // fuente para la fotografía var destinationType; // variable para el tipo de formato retornado document.addEventListener("deviceready", onDeviceReady, false); function onDeviceReady( ) { /*se preparan las variables de sistema para poder usar la cámara*/ pictureSource = navigator.camera.PictureSourceType; destinationType = navigator.camera.DestinationType; } options = { quality : 50, targetWidth: 100, targetHeight: 100, correctOrientation: true, destinationType : Camera.DestinationType.FILE_URI,



sourceType : Camera.PictureSourceType.CAMERA, saveToPhotoAlbum: true } navigator.camera.getPicture(getImageURI, onFail, options); function getImageUri( imageURI ) { var imagen = document.getElementById('imagen_ejemplo'); image.src = imageURI; } function onFail( message ) { alert('Ocurrió un error: ' + message); } }); // fin ready

Básicamente el código anterior crea las variables necesarias para permitir la captura de una nueva imagen. Luego define una serie de opciones que generan la configuración siguiente:

• Que la calidad de la imagen sea el 50% de la que posee la foto original.

• Que tanto el ancho como el alto de la imagen sea de 100 pixeles. • Que la orientación de la foto sea corregida al momento de hacer la captura.

• La localización de la fotografía será devuelta como una URI. • La captura se realizará directamente desde la cámara del dispositivo. • La fotografía será guardada en el álbum de fotos del dispositivo.

Más adelante en el código se invoca a “navigator.camera.getPicture” para que la foto sea tomada con las opciones antes nombradas y recibe además dos funciones. La primera es “getImageUri” , que se ejecuta si la captura ha tenido éxito. Recibe como parámetro la localización de la imagen tomada y carga un supuesto objeto HTML perteneciente a una imagen, con dicha localización. La segunda función es “onFail”, la cual se activa en caso de error y muestra un mensaje, el cual, recibe como parámetro. Es útil para informar al usuario que la operación no se pudo completar correctamente.

El otro método ofrecido por la API para la cámara es “cleanup”. Cabe destacar que sólo está disponible para la plataforma IOS. Esta función permite remover los archivos temporales que son generados por las llamadas a “camera.getPicture”. Se aplica sólo cuando el valor de Camera.sourceType es igual a “Camera.PictureSourceType.CAMERA” y el de Camera.destinationType es igual a “Camera.DestinationType.FILE_URI”.

A continuación un pequeño ejemplo de su uso:

$(document).ready( function ( ) { navigator.camera.cleanup(onSuccess, onFail); function onSuccess () { alert('Archivos temporales eliminados!');



} function onFail( message ) { alert('Ocurrió un error: ' + message); } }); // fin ready

5.3.3 Media-capture (Captura multimedia)

Hablábamos anteriormente de cómo los dispositivos móviles habían mejorado notablemente sus capacidades respecto a la cámara fotográfica que incorporaban. Ese mejoramiento no es ajeno a la capacidad de grabar tanto sonido como video. Es por eso que PhoneGap, como no podía ser de otra manera, implementa el plugin “media-capture”, que proporciona acceso a las capacidades de captura de audio, imagen y video del dispositivo.

El comando de instalación de esta característica es el siguiente:

$>cordova plugin add org.apache.media-capture

Métodos de captura

• capture.captureAudio

• capture.captureImage • capture.captureVideo

• MediaFile.getFormatData

El método “captureAudio” básicamente permite abrir una aplicación para la grabación de sonidos y posteriormente devolver el audio capturado por la misma a nuestra aplicación. La sintaxis de esta función es la siguiente:

navigator.device.capture.captureAudio( captureSuccess, captureError, [options] );

Como se puede observar esta función recibe tres argumentos. Una función “captureSuccess” que se ejecuta cuando la captura de audio es exitosa; una segunda, llamada “captureError” , que se ejecuta si ocurre un error y un parámetro opcional con posibles opciones denominada “options” . Este último consta de dos posibles valores:

• limit : El máximo de capturas de audio que el usuario puede hacer en una sola operación. El valor por defecto es uno (1).

• duration : La duración máxima de los audio capturados en segundos.



A continuación presentamos un pequeño código de ejemplo para ver la llamada en funcionamiento:

$(document).ready( function ( ) { var options = { duration: 60, limit: 2 }; navigator.device.capture.captureAudio(captureSuccess, captureError, options); var captureSuccess = function( mediaFiles ) { var i, path, len; for (i = 0, len = mediaFiles.length; i < len; i++) { path = mediaFiles[i].fullPath; // HACER ALGO CON LOS AUDIOS OBTENIDOS } }; var captureError = function( error ) { alert('Código de error: ' + error.code); }; }); // Fin ready

El método “captureImage” se encarga de iniciar la cámara del dispositivo y retornar la información acerca de las imágenes capturadas. La sintaxis de la llamada es la siguiente:

navigator.device.capture.captureImage ( captureSuccess, captureError, [options] );

Esta función recibe tres argumentos. Una función “captureSuccess” que se ejecuta cuando la captura de las imágenes tiene éxito; una segunda, denominada “captureError” , que se ejecuta si ocurre un error y un parámetro no obligatorio denominado “options” . Este último permite configurar la siguiente opción:

• limit : El máximo de capturas fotográficas que el usuario puede hacer en una sola operación. El valor por defecto es uno (1).

A continuación mostramos un ejemplo de código para ver la llamada en funcionamiento:

$(document).ready( function ( ) { var options = { limit: 10 }; navigator.device.capture.captureImage(captureSuccess, captureError, options); var captureSuccess = function( mediaFiles ) { var i, path, len; for (i = 0, len = mediaFiles.length; i < len; i++) {



path = mediaFiles[i].fullPath; // HACER ALGO CON LAS IMÁGENES CAPTURADAS } }; var captureError = function( error ) { alert('Código de error: ' + error.code); }; }); // Fin ready

El método “captureVideo” se encarga de iniciar la aplicación por defecto del dispositivo para la captura de video y, retorna la información acerca de los archivos de las películas grabadas. La sintaxis de la llamada se muestra a continuación:

navigator.device.capture.captureVideo ( captureSuccess, captureError, [options] );

“captureVideo” recibe tres argumentos. Una función “captureSuccess” que se ejecuta

cuando la captura de video tiene éxito; una segunda, llamada “captureError” , que se ejecuta si ocurre un error y un parámetro no obligatorio denominado “options” . Este último permite configurar las siguientes opciones:

• limit : El máximo de videos que el usuario puede capturar en una sola operación. El valor por defecto es uno (1).

• duration : La duración máxima de cada video capturado en segundos.

A continuación un ejemplo de código para ver la llamada en funcionamiento:

$(document).ready( function ( ) { var options = { limit: 3 }; navigator.device.capture.captureVideo(captureSuccess, captureError, options); var captureSuccess = function( mediaFiles ) { var i, path, len; for (i = 0, len = mediaFiles.length; i < len; i++) { path = mediaFiles[i].fullPath; // HACER ALGO CON LOS VIDEOS CAPTURADOS } }; var captureError = function( error ) { alert('Código de error: ' + error.code); }; }); // Fin ready



Finalmente presentamos el último método ofrecido por este plugin media-capture, “MediaFile.getFormatData”. El mismo nos permite recuperar cierta información acerca del formato de los archivos multimedia capturados. Los datos que podemos obtener son:

• codecs: El formato actual de un archivo de video o audio. • bitrate : Calidad del contenido del archivo. Este valor es cero para la imágenes.

• height: El alto de la imagen o video en pixeles. Este valor es cero para los archivos de audio.

• width : El ancho de la imagen o video en pixeles. Este valor es cero para los archivos de audio.

• duration : Longitud de del video o audio en segundos. Cero si es una imagen.

La sintaxis de la llamada se muestra a continuación:

mediaFile.getFormatData( successCallback, [ errorCallback ] ););

Esta llamada a diferencia de las anteriores, recibe sólo dos argumentos. Una función “successCallback” que se ejecuta cuando la llamada es exitosa y una segunda función denominada “errorCallback” , la cual es opcional y que se ejecuta si ocurre algún error durante la invocación.

A continuación un ejemplo de código para ver la llamada en funcionamiento. Se capturará un video y se mostrará al usuario las cinco propiedades vistas al usuario:

$(document).ready( function ( ) { var options = { limit: 1 }; navigator.device.capture.captureVideo(captureSuccess, captureError, options); var captureSuccess = function( mediaFiles ) { mediaFiles[0]. getFormatData(successGetFormat, errorGetFormat); } var captureError = function( error ) { alert('Código de error: ' + error.code); }; function successGetFormat ( data ) { alert('Codec del video: ' + data. codecs); alert('Calidad del video: ' + data. bitrate); alert('Alto del video: ' + data. height); alert('Ancho del video: ' + data. width); alert('Duración del video: ' + data. duration); } function errorGetFormat ( error ) { alert('Fallo getFormatData, código de error: ' + error.code); } }); // Fin ready



5.3.4 Geolocation (Geolocalización)

La geolocalización permite conocer el posicionamiento que define la localización de un objeto en un sistema de coordenadas determinado. PhoneGap implementa un plugin de geolocalización siguiendo el estándar definido por la “W3C” (la organización que define los estándares de la web) y permite conocer la ubicación de nuestro dispositivo basado en las magnitudes latitud y longitud. El comando de instalación del plugin es el siguiente:

$>cordova plugin add org.apache.cordova.geolocation

Métodos de geolocalización

• geolocation.getCurrentPosition • geolocation.watchPosition

• geolocation.clearWatch

La función asincrónica “getCurrentPosition”, nos permitirá obtener las coordenadas de la posición actual del dispositivo y otras características que veremos en breve. Este método tiene la siguiente sintaxis:

navigator.geolocation.getCurrentPosition(onSuccess, onError);

Siguiendo la misma tónica que todos los métodos que hemos visto hasta ahora la llamada “getCurrentPosition” recibe dos parámetros. Una función en caso de que la captura del posicionamiento haya sido exitosa (onSuccess) y una segunda función que se ejecuta en caso de error (onError). Al ejecutar esta llamada podremos obtener las siguientes magnitudes:

• Latitude : Latitud en grados decimales. • Longitude: Longitud en grados decimales.

• Altitude : Altura de la posición en metros por encima del elipsoide. • Accuracy: Nivel de precisión de las coordenadas de latitud y longitud en metros.

• AltitudeAccuracy : Nivel de precisión de las coordenadas de altitud en metros. • Heading: Dirección del recorrido especificado en grados, contando hacia la derecha en

relación con el norte real. • Speed: Velocidad actual del dispositivo especificado en metros por segundos.

A continuación mostramos un ejemplo del uso de “getCurrentPosition”:

$(document).ready( function ( ) { document.addEventListener("deviceready", onDeviceReady, false); function onDeviceReady() { navigator.geolocation.getCurrentPosition(onSuccess, onError); }



function onSuccess( position ) { alert('Latitude: ' + position.coords.latitude + '\n' + 'Longitude: ' + position.coords.longitude + '\n' + 'Altitude: ' + position.coords.altitude + '\n' + 'Accuracy: ' + position.coords.accuracy + '\n' + 'Altitude Accuracy: ' + position.coords.altitudeAccuracy + '\n' + 'Heading: ' + position.coords.heading + '\n' + 'Speed: ' + position.coords.speed); } function onError(error) { alert('Error al capturar Coordenadas del dispositivo, código: ' + error.code); } }); // Fin ready

Otro método ofrecido por PhoneGap es “geolocation.watchPosition”. El mismo permite

obtener la posición del dispositivo cada vez que esta cambia. La sintaxis de la llamada es la siguiente:

navigator.geolocation.watchPosition(onSuccess, [onError], [options]);

Los argumentos recibidos por la llamada son tres. El primero es una función, la cual es ejecutada cuando la posición actual del dispositivo es recuperada con éxito. El segundo es opcional y es una función que se ejecutará en caso de que haya ocurrido un error. El tercer y último parámetro, también opcional, permite configurar los siguientes parámetros al realizar la llamada:

• enableHighAccuracy: Proporciona un indicio o insinuación de que la aplicación necesita los mejores resultados posibles. De forma predeterminada, el dispositivo intenta recuperar una posición empleando métodos basados en la red. Al establecer esta propiedad en verdadero indicamos al framework que intente utilizar métodos más precisos, como el posicionamiento por satélite (GPS).

• timeout: Es la longitud máxima de tiempo (en milisegundos) permitida desde la llamada a “geolocation.watchPosition” hasta que la correspondiente función “onSuccess” se ejecuta. Si la misma no se invoca dentro de este lapso, la llamada “onError” es invocada y se le pasa un código de error “PositionError.TIMEOUT” .

• maximumAge: Permite aceptar una posición en caché cuya edad sea mayor que el tiempo especificado en milisegundos.

Antes de mostrar un ejemplo de código para la llamada anterior, explicaremos la utilidad del

tercer método ofrecido por este plugin y llamado “clearWatch”. El mismo permite detener la ejecución de la llamada “geolocation.watchPosition” usando el identificador devuelto por esta. Con el fin de clarificar lo expuesto mostramos el siguiente código de ejemplo donde las últimas dos llamadas explicadas son utilizadas:



$(document).ready( function ( ) { var watchID = null; document.addEventListener("deviceready" function onDeviceReady() { var options = { maximumAge: watchID = navigator.geolocation.getWatchPosition(onSuccess, onError, options); // Para detener la captura al ocurrir el evento document.addEventListener("backbutton" } function onSuccess( position ) { alert('Latitude: ' + position.coords.latitude + 'Longitude: ' + position.coords.longitude + 'Altitude: ' + position.coords.altitude + 'Accuracy: ' + position.coords.accuracy + 'Altitude Accuracy: ' + position.coords.altitudeAccuracy + 'Heading: ' + position.coords.heading + 'Speed: ' + position.coords.speed); } function onError(error) { alert('Error al capturar Coordenadas del dispositivo, código: ' } // Detener observación de la posición al presionar function stopWatch () { if (watchID) { navigator. geolocation.clearWatch(watchID); watchID = null; } } }); // Fin ready

5.3.5 Device-orientation (Brújula)

Una brújula (“compass” en inglés) es un instrumento que determina el ángulo de rotación de un dispositivo respecto al polo norte están equipados con una. La brújula es un sensor que detecta la dirección o rumbo al que el dispositivo está apuntando, normalmente desde su parte superior PhoneGap permite interactuar con ella mediante la instalación del siguiente comando:


Chavez Alexis David

"deviceready", onDeviceReady, false);

options = { maximumAge: 3000, timeout: 5000, enableHighAccuracy: true

navigator.geolocation.getWatchPosition(onSuccess, onError, options);

// Para detener la captura al ocurrir el evento backbutton "backbutton", stopWatch, false);

+ position.coords.latitude + '\n' + + position.coords.longitude + '\n' +

+ position.coords.altitude + '\n' + + position.coords.accuracy + '\n' +

+ position.coords.altitudeAccuracy + '\n' + + position.coords.heading + '\n' +

+ position.coords.speed);

'Error al capturar Coordenadas del dispositivo, código: ' + error.code);

// Detener observación de la posición al presionar “backButton”

.clearWatch(watchID);

orientation (Brújula)

en inglés) es un instrumento que determina el ángulo de rotación de un dispositivo respecto al polo norte magnético de la tierra. Hoy la gran mayoría de los dispositivos están equipados con una. La brújula es un sensor que detecta la dirección o rumbo al que el dispositivo está apuntando, normalmente desde su parte superior PhoneGap permite interactuar con

a mediante la instalación del siguiente comando:


Pág. 104

};

navigator.geolocation.getWatchPosition(onSuccess, onError, options);

en inglés) es un instrumento que determina el ángulo de rotación de magnético de la tierra. Hoy la gran mayoría de los dispositivos

están equipados con una. La brújula es un sensor que detecta la dirección o rumbo al que el dispositivo está apuntando, normalmente desde su parte superior PhoneGap permite interactuar con



$>cordova plugin add org.apache.cordova.device-orientation

Métodos de la Brújula

• compass.getCurrentHeading • compass.watchHeading • compass.clearWatch

El método “getCurrentHeading”, permite obtener la dirección actual del dispositivo mediante su brújula. Se mide en grados de 0 a 359.99, donde 0 es el norte. La sintaxis de esta llamada es la siguiente:

navigator.compass.getCurrentHeading(onSuccess, onError);

El primer parámetro es una función llamada “onSuccess” que se ejecuta en caso de éxito y permite recuperar la información asociada a la dirección del dispositivo. Los valores capturados son los siguientes:

• magneticHeading: Dirección en grados, en el rango 0-359.99, en un determinado momento. • trueHeading: Es la dirección relativa al Polo Norte en grados de 0 a 359,99 en un momento

dado. Un valor negativo indica que no se puede determinar. • headingAccuracy: La desviación en grados entre la dirección informada y la verdadera.

• timestamp: El momento en que se determinó esta dirección. El segundo parámetro de esta llamada es “onError” y se ejecuta en caso de fallar la ejecución del método principal y se encarga de capturar una variable con los datos del error. A continuación presentamos un ejemplo del uso de “getCurrentHeading”: $(document).ready( function ( ) { document.addEventListener("deviceready", onDeviceReady, false); function onDeviceReady() { navigator.geolocation.getCurrentHeading(onSuccess, onError); } function onSuccess( heading ) { alert(' magneticHeading: ' + heading. magneticHeading + '\n' + ' trueHeading: ' + heading. trueHeading + '\n' + ' headingAccuracy: ' + heading. headingAccuracy + '\n' + ' timestamp: ' + heading.timestamp); } function onError(error) { alert('Error al capturar dirección del dispositivo, código: ' + error.code); } }); // Fin ready



El segundo método “compass.watchHeading” , permite obtener la dirección de la brújula en grados, en un intervalo regular de tiempo. Mide el rumbo en grados con un valor entre 0 ya 359,99. La sintaxis de esta llamada es la siguiente:

navigator.compass.watchHeading(onSuccess, onError, [options] );

El primer parámetro es una función denominada “onSuccess” que se ejecuta si la llamada se realizó con éxito. Permite recuperar la misma información asociada a la dirección del dispositivo vista para el método “getCurrentHeading”.

El segundo parámetro de esta llamada es “onError” y es la función ejecutada en caso de fallar la ejecución del método principal.

El tercer parámetro llamado “options” es opcional y permite configurar dos útiles opciones:

• frequency: Con qué frecuencia recuperar datos de la brújula en milisegundos. • filter : El cambio necesario, en grados, para disparar la ejecución de la función “onSuccess”.

El tercer y último método ofrecido por PhoneGap para la manipulación de la brújula es “clearWatch”. Esta llamada permite detener la ejecución de la captura generada por “compass.watchHeading” . A continuación un código de ejemplo mostrando cómo funcionan estos dos métodos:

$(document).ready( function ( ) { var watchID = null; document.addEventListener("deviceready", onDeviceReady, false); function onDeviceReady() { // Actualizar la brújula cada tres segundos var options = { frequency: 3000 }; watchID = navigator.compass.watchHeading(onSuccess, onError, options); // Para detener la captura al ocurrir el evento backbutton document.addEventListener("backbutton", stopWatch, false); } function onDeviceReady() { navigator.geolocation.getCurrentHeading(onSuccess, onError); } function onSuccess(heading) { alert(' magneticHeading: ' + heading. magneticHeading + '\n' + ' trueHeading: ' + heading. trueHeading + '\n' + ' headingAccuracy: ' + heading. headingAccuracy + '\n' + ' timestamp: ' + heading.timestamp); }



Tabla 5.2 – Referencia a los objetos del plugin “contacts”

Objeto Propiedad Detalle

id Un identificador global y único

displayName Nombre del contacto adecuado para mostrar al usuario final

name Objeto que contiene todos los componentes del nombre de una persona

nickname Nombre informal del contacto (apodo)

phoneNumbers Arreglo con todos los números de teléfono del contacto

emails Arreglo con todas la direcciones de correo electrónico del contacto

Contact addresses Arreglo con todas las direcciones (geográficas) del contacto

ims Arreglo con todas las cuentas de mensajería instantánea del contacto

organizations Arreglo con todas las organizaciones del contacto

birthday Fecha de nacimiento del contacto

note Nota acerca del contacto

photos Arreglo con todas las fotos del contacto

categories Arreglo de todas las categorías def. por el usuario asociados con el contacto

urls Arreglo con todas las páginas web asociadas con el contacto

formatted El nombre completo del contacto

familyName El apellido del contacto

ContactName givenName El primer nombre del contacto

middleName El segundo nombre del contacto

honorificPrefix Prefijo para el contacto (Ej.: Sr. ó Dr.)

honorificSuffix Sufijo para el contacto

type Una cadena que indica a qué tipo pertenece este campo

ContactField value El valor de un campo determinado

pref Establecido a true si este ContactField contiene el valor preferido del usuario

pref Establecido a true si este ContactAddress contiene el valor preferido del usuario

type Una cadena que indica a qué tipo pertenece este campo

formatted La dirección geográfica completa formateada para mostrar

ContactAddress streetAddress La dirección postal completa

locality La ciudad

region La provincia o estado

postalCode El código postal

country El nombre del país

pref Es true si este ContactOrganization contiene el valor preferido del usuario

type Una cadena qué indica a que tipo pertenece este campo

ContactOrganization name El nombre de la organización

department EL nombre del departamento de contrato.

title El título de contacto de la empresa

ContactFindOptions filter La cadena de búsqueda usada para encontrar contactos

multiple Determina si la operación de búsqueda devuelve varios contactos

ContactError code Código de error

Ahora que tenemos una tabla de referencia a todos los objetos del plugin “contacts” empezaremos por analizar la primera de las llamadas ofrecidas por este. El método “create”



devuelve un nuevo objeto “Contact” . El mismo no crea un contacto en la base de datos, funciona más bien como una fábrica de contactos que permite crear un objeto contacto (Contact) vacío. Luego de crear dicho objeto este proveerá tres funciones que nos permitirán hacer lo siguiente:

• clone: Retorna un nuevo objeto contacto que es una copia exacta del objeto invocador con la

propiedad “id” puesta a null. • remove: Elimina el contacto de la base de datos del dispositivo.

• save: Guarda un nuevo contacto en la base de datos del dispositivo o actualiza un contacto existente que tiene el mismo “id”.

La sintaxis de la llamada “create” es la siguiente:

navigator.contacts.create( properties );

El único argumento recibido por este método es “properties” (propiedades) y permite crear un nuevo objeto Contacto, configurable con todas las características vistas en la tabla 5.2. Luego veremos un ejemplo para ver más claro su funcionamiento.

El otro método suministrado por este plugin es “find” . El mismo nos permitirá consultar la base de datos de contactos del dispositivo y obtener uno o más objetos de contacto, según el criterio especificado. Su sintaxis es la siguiente:

navigator.contacts.find( contactFields, onSuccess, [onError], [findOptions]);

El primer argumento, llamado “contactFields”, es utilizado para especificar qué campos deben incluirse en los objetos de contacto recuperados en la operación de búsqueda. Hay una referencia a este objeto en la tabla 5.2. El Segundo parámetro, “onSuccess”, es la función que se ejecutará en el momento en que los contactos sean obtenidos de la base de datos. El tercer argumento denominado “onError” , es opcional y es ejecutado si ocurre algún error. El último de los parámetros, “findOptions”, también es opcional y es usado para filtrar los contactos retornados de la base de datos. Este objeto posee dos valores configurables (filter y multiple) y está referenciado en “ContactFindOptions” dentro de la tabla 5.2.

Con el fin de ilustrar un poco el funcionamiento de los métodos “create” y “find” vistos, mostraremos un breve ejemplo codificado de la creación y resguardo de un nuevo contacto, y la búsqueda de otro.

$(document).ready( function ( ) { document.addEventListener("deviceready", onDeviceReady, false); function onDeviceReady( ) { var phoneNumbers = [ ]; // Recipiente para los números de teléfono phoneNumbers[0] = new ContactField('work', '212-555-1234', false); phoneNumbers[1] = new ContactField('mobile', '917-555-5432', true); // Número preferido



5.3.7 Device (Dispositivo)

Hay veces que se requiere obtener ciertos datos referidos al software o hardware del dispositivo móvil con el fin de identificarlo, o bien, con motivo de alterar el flujo del programa de acuerdo a alguno de esos parámetros. PhoneGap provee un plugin llamado “device” para ayudarnos en esta tarea. A continuación mostramos el comando de instalación del mismo:

$>cordova plugin add org.apache.cordova.device Este complemento es realmente muy sencillo. Básicamente lo que hace es generar una variable global llamada “device”, la cual permite conocer los siguientes valores:

• device.model: Devuelve el modelo del dispositivo. Este valor es establecido por el fabricante y puede variar en distintas versiones del mismo.

• device.cordova: Retorna la versión de PhoneGap corriendo en el dispositivo. • device.platform: Obtiene el nombre del sistema operativo del dispositivo. • device.uuid: Devuelve el identificador único universal del dispositivo (UUID). • device.version: Retorna la versión del sistema operativo. • device.name: Devuelve el nombre del modelo del dispositivo, pero está en desuso, se

recomienda usar device.model.

A continuación un pequeño ejemplo del uso de este plugin que permite observar los valores antes comentados:

$(document).ready( function ( ) { document.addEventListener("deviceready", onDeviceReady, false); function onDeviceReady( ){ alert('Device Model: ' + device.model + '\n' + 'Device Cordova: ' + device.cordova + '\n' + 'Device Platform: ' + device.platform + '\n' + 'Device UUID: ' + device.uuid + '\n' + 'Device Version: ' + device.version); } }); // fin ready

5.3.8 Media (Captura de audio)

PhoneGap posee un plugin llamado “media”, el cual implementa un objeto que ofrece la posibilidad de grabar y reproducir archivos de audio, en un dispositivo móvil. El comando para instalar esta característica es el siguiente:

$>cordova plugin add org.apache.cordova.media



Luego de instalar el plugin estaremos habilitados para utilizar una nueva abstracción cuya clase se denomina “Media” . La misma permite instanciar un nuevo objeto de ese tipo mediante la siguiente sentencia:

var media = new Media(src,[mediaSuccess], [mediaError], [mediaStatus]);

Mediante la llamada anterior se llama al constructor de la clase “Media” y se pasa a una variable la referencia a un nuevo objeto. Dicho constructor recibe los siguientes parámetros:

• src: La URI (identificador de recursos uniforme) donde se encuentra el audio. • mediaSuccess: Función llamada después de que un objeto Media ha completado la acción

actual de reproducción, grabación o stop. (Opcional).

• mediaError : Es la función que se ejecuta en caso de error. (Opcional). • mediaStatus: Función que se ejecuta para indicar los cambios de estado. (Opcional).

La función “mediaStatus” es capaz de capturar las siguientes constantes de estado para el objeto Media:

• Media.MEDIA_NONE = 0;

• Media.MEDIA_STARTING = 1; • Media.MEDIA_RUNNING = 2;

• Media.MEDIA_PAUSED = 3; • Media.MEDIA_STOPPED = 4;

Métodos para el objeto Media

• media.getCurrentPosition • media.getDuration

• media.play • media.pause

• media.release • media.seekTo

• media.setVolume • media.startRecord • media.stopRecord

• media.stop

El método “media.getCurrentPosition” devuelve la posición actual dentro de un archivo de audio en segundos. Su sintaxis es la siguiente:



media.getCurrentPosition(mediaSuccess, [mediaError]);

Donde “mediaSuccess” es la función a la que se le pasa la posición actual en el archivo en segundos. “mediaError” es opcional y es una función que es llamada en caso de error. Mostramos a continuación un pequeño código de ejemplo:

var my_media = new Media(src, onSuccess, onError); // Actualizamos la posición una vez por segundo var mediaTimer = setInterval(function () { my_media.getCurrentPosition( // En caso de éxito function (position) { if (position > -1) { console.log((position) + " segundos"); // Mostrar posición en la consola } }, // En caso de error function (e) { console.log("Error al posicionarse, " + e); // Mostrar error en la consola } ); }, 1000);

La función “media.getDuration” devuelve la duración de un archivo de audio en segundos. Si no la puede determinar devuelve “-1”. Su sintaxis es la siguiente:

media.getDuration( );

A continuación un fragmento de código que muestra su uso:

var my_media = new Media(src, onSuccess, onError); var counter = 0; var timerDur = setInterval(function() { // Tomar la duración de una pista luego de 100 miliseg. counter = counter + 100; if (counter > 2000) { clearInterval(timerDur); // Evitar que se vuelva a ejecutar timerDur transcurridos 2 seg. } var dur = my_media.getDuration(); if (dur > 0) { clearInterval(timerDur); Evitar ejecución de timerDur una vez obtenida la posición. alert("La duración de la pista es de " + dur + " seg."); } }, 100);



La llamada “media.play” permite iniciar o reanudar la reproducción de un archivo de audio. Su invocación se muestra a continuación:

media.play( );

A continuación un ejemplo de código para mostrar su uso:

function playAudio(url) { // Se reproducirá el audio de una URL válida var my_media = new Media(url, // Función ejecutada en caso de éxito, que muestra un mensaje a tal efecto function () { alert("Audio reproduciéndose!"); }, // Función ejecutada en caso de error function (err) { alert("Error al reproducir audio, " + err); } ); // Función que comienza la reproducción my_media.play(); }

La función “media.pause” permite pausar la reproducción de un archivo de audio. Su sintaxis es la que sigue:

media.pause ( );

El código que sigue muestra como es su uso:

function playAudio(url) { // Se reproducirá el audio de una URL válida var my_media = new Media(url, // Función en caso de reproducción exitosa function( ) { alert("Reproduciendo audio!"); }, // Función en caso de error al reproducir function( err ) { alert("Error al intentar reproducir audio, " + err); } ); // Se envía la orden de reproducción del audio my_media.play(); // Se pausa la reproducción automáticamente luego de 10 seg. setTimeout(function () { media.pause(); }, 10000); }



El método “media.release” es utilizado para liberar los recursos de audio del sistema operativo subyacente. Su sintaxis es la siguiente:

media.release( );

El código a continuación muestra un ejemplo de su uso:

var my_media = new Media(src, onSuccess, onError); // El ciclo de vida de toda aplicación que use audio debería ser similar a lo siguiente my_media.play(); my_media.stop(); my_media.release(); // Luego de la reproducción se liberan los recursos del sistema operativo

La llamada “media.seekTo” permite cambiar la posición actual dentro de un archivo de audio. La sintaxis es la que sigue:

media.seekTo( milliseconds );

Donde el parámetro “milliseconds” representa la nueva posición en milisegundos en el archivo de audio. A continuación un ejemplo de su uso:

var my_media = new Media(src, onSuccess, onError); my_media.play(); // Posicionamos el puntero en 10 seg. Transcurridos 5 seg. de reproducción setTimeout(function() { my_media.seekTo(10000); }, 5000);

La función “media.setVolume” permite cambiar el volumen actual durante la reproducción de un archivo de audio. Su sintaxis es esta:

media.setVolume( volume );

El parámetro “volume” es un valor entre 0.0 (mínimo) y 1.0 (máximo) con el que el volumen actual del archivo audio será ajustado. A continuación un ejemplo:

function playAudio(url) { // Se reprodicira un archivo de audio desde una URL valida var my_media = new Media(url, // Llamada en caso de reproducción exitosa



function() { alert("Reproducción de audio exitosa"); }, // Llamada en caso de error function(err) { alert("Error en la reproducción" + err); }); // Se manda a reproducir el audio my_media.play(); // Mutar volumen luego de 2 segundos setTimeout(function() { my_media.setVolume('0.0'); }, 2000); // Poner volumen al máximo transcurridos 5 segundos setTimeout(function() { my_media.setVolume('1.0'); }, 5000); }

El método “media.startRecord” permite comenzar la grabación de sonido sobre un archivo de audio. La sintaxis es la siguiente:

media.startRecord( );


function recordAudio() { var src = "myrecording.mp3"; // Nombre para el archivo de audio var mediaRec = new Media(src, // Función ejecutada en caso de éxito function() { alert("Archivo de audio creado exitosamente"); }, // Función ejecutada en caso de error function(err) { alert("No se pudo crear archivo de audio, error: " + err.code); }); // Comenzando grabación de audio mediaRec.startRecord(); }

La llamada “media.stopRecord” permite detener la grabación de sonido de un archivo de

audio. La sintaxis es la siguiente:

media.stopRecord( );



5.3.9 Globalization (Globalización)

Este plugin de PhoneGap permite obtener información y llevar a cabo operaciones de conversión en relación con la configuración regional del usuario y la zona horaria. El comando de instalación es el siguiente:

$>cordova plugin add org.apache.cordova.globalization

Métodos para globalización

• globalization.getPreferredLanguage • globalization.getLocaleName • globalization.dateToString

• globalization.stringToDate • globalization.getDatePattern

• globalization.getDateNames • globalization.isDayLightSavingsTime • globalization.getFirstDayOfWeek

• globalization.numberToString • globalization.stringToNumber

• globalization.getNumberPattern • globalization.getCurrencyPattern

El método “getPreferredLanguage” retorna una cadena identificando el lenguaje actual de usuario (por jemplo “language: English”). La sintaxis para utilizarlo es la siguiente:

navigator.globalization.getPreferredLanguage(onSuccess, onError);

El primer parámetro de la llamada es la función “onSuccess”, la cual se ejecuta en caso de éxito y recibe como argumento un objeto conteniendo el nombre del lenguaje utilizado. El segundo parámetro es la función “onError” que se ejecuta en caso de error. A continuación un breve ejemplo del uso de esta llamada:

navigator.globalization.getPreferredLanguage( // En caso de exito function (language) { alert('Lenguaje: ' + language.value + '\n'); }, // En caso de error function ( ) { alert('Error al obtener lenguaje' + '\n'); } );



El método “getLocaleName” devuelve una cadena que identifica la configuración regional (por ejemplo: “en\_US ”). La sintaxis para utilizarlo es la siguiente:

navigator.globalization.getLocaleName(onSuccess, onError);

El primer parámetro de la llamada es la función “onSuccess”, la cual se ejecuta en caso de éxito y recibe como argumento un objeto conteniendo el nombre de la configuración regional del dispositivo. El segundo parámetro es la función “onError” que se ejecuta en caso de error. A continuación un breve ejemplo del uso de esta llamada:

navigator.globalization.getLocaleName ( // En caso de exito function (locale) { alert('Configuración local: ' + locale.value + '\n'); }, // En caso de error function ( ) { alert('Error al obtener configuración' + '\n'); } );

La llamada “dateToString” devuelve una fecha con formato de cadena de acuerdo a la configuración regional y la zona horaria en el dispositivo. La sintaxis de uso es la siguiente:

navigator.globalization.dateToString(date, onSuccess, onError, [options]);

El parámetro “date” es la fecha a convertir y debe ser de tipo Date. El segundo argumento, la función “onSuccess” se ejecuta en caso de éxito y recibe como argumento un objeto conteniendo la fecha convertida. El tercer parámetro es la función “onError” que se ejecuta en caso de error y recibe un objeto con el error. “options” es opcional y permite configurar las siguientes características:

• formatLength: Formato de la fecha retornada, puede ser “short” (corto), “medium” (mediano), “long” (largo), o “full” (completo).

• Selector: Permite los valores “date” , “time” o “date and time”, según se desee mostrar, fecha, hora, o fecha y hora.

A continuación un pequeño ejemplo:

navigator.globalization.dateToString( new Date(), // Fecha a convertir function (date) { alert(Fecha convertida: ' + date.value + '\n'); }, // Función en caso de éxito function () { alert('Error al convertir fecha. \n'); }, // Función en caso de error { formatLength: 'short', selector: 'date and time' } // Se mostrará fecha y hora en formato corto );



La llamada “stringToDate” Analiza una fecha en formato cadena, de acuerdo con las preferencias y calendario del usuario, usando la zona horaria del dispositivo, y devuelve el correspondiente como un objeto date. La sintaxis que usa es la que sigue:

navigator.globalization.stringToDate(dateString, onSuccess, onError, options);

El parámetro “dateString” es la fecha a convertir y debe ser de tipo String. El segundo argumento, la función “onSuccess” se ejecuta en caso de éxito y recibe como argumento un objeto conteniendo la fecha convertida con las siguientes propiedades:

• year: Los cuatro dígitos del año • month: El mes en el rango de 0 a 11.

• day: El día en el rango 1a 31. • hour: La hora en el rango 0 a 23.

• minute: Los minutos en el rango 0 a 59. • second: Los segundos en el rango 0 a 59.

• millisecond: Los milisegundos en el rango 0 a 999.

El tercer parámetro es la función “onError” que se ejecuta en caso de error. El cuarto argumento, “options”, es opcional y permite configurar las características “formatLength” y “Selector” como se vio para la función “dateToString”.

A continuación un pequeño código de ejemplo:

navigator.globalization.stringToDate( '25/9/2014', // Fecha a convertir en formato String function (date) { // Función en caso de éxito alert('Mes:' + date.month + '\n'+ ' Dia:' + date.day + '\n' + ' Año' + date.year ); }, function ( ) { // Función en caso de error alert('Error al convertir fecha\n'); }, {selector: 'date'} Se mostrara sola la fecha );

El método “getDatePattern” retorna un objeto conteniendo el patrón usado para dar formato y analizar las fechas de acuerdo a las preferencias del usuario (por ejemplo: “M/d/yyyy h:mm”). Utiliza la siguiente sintaxis:

navigator.globalization.getDatePattern(onSuccess, onError, options);



El primer argumento, la función “onSuccess”, se ejecuta en caso de éxito y recibe como argumento un objeto conteniendo el formato de fecha usado por el usuario con las siguientes propiedades:

• pattern: El patrón de fecha y hora para dar formato y analizar las fechas. • timezone: El nombre abreviado de la zona horaria del usuario.

• utc_offset: La diferencia en segundos entre la zona horaria del usuario y el tiempo universal coordinado (UTC).

• dst_offset: La diferencia en segundos entre la zona horaria con horario de verano y la zona horaria común.

El segundo parámetro es la función “onError” que se ejecuta en caso de error. El último parámetro denominado “options” es opcional, y permite configurar las siguientes características “formatLength” y “Selector” como se vio para la función “dateToString”.

A continuación un ejemplo del uso de “getDatePattern”:

navigator.globalization.getDatePattern( function (date) { // Función en caso de éxito alert(Patrón: ' + date.pattern + '\n'); }, function ( ) { // Función en caso de error alert('Error al obtener patrón \n'); }, { formatLength: 'short', selector: 'date and time' } // Opciones );

El método “getDateNames” devuelve un arreglo con los nombres de los meses o días de la semana, dependiendo de las preferencias y calendario.

navigator.globalization.getDateNames(onSuccess, onError, options);

El argumento “onError” es la función ejecutada si ocurre un error. “onSuccess” es la llamada que se ejecuta en caso de éxito y recibe como argumento un arreglo conteniendo los días de la semana o los meses del año, según lo configurado en el parámetro “options” , el cual permite establecer las siguientes propiedades:

• type: El formato del nombre de los meses o días. Permite los valores: “narrow” (reducido) o “wide” (amplio).

• Item: El tipo de ítem que contendrá el arreglo retornado. Los valores posibles son: “months” (meses) o “days” (días).

A continuación un código de ejemplo:



navigator.globalization.getDateNames( function (names) { // En caso de éxito se muestran los meses del año for (var i = 0; i < names.value.length; i++) { alert('Mes: ' + names.value[i] + '\n'); } }, function ( ) { alert('Error al obtener meses\n'); }, // En caso de error {type: 'wide', item: 'months'} // Obtener meses en format amplio );

El método “isDayLightSavingsTime” permite saber si una determinada fecha se encuentra dentro del horario de verano según la zona horaria del usuario. La sintaxis:

navigator.globalization.isDayLightSavingsTime(date, onSuccess, onError);

El primer argumento (“date” ) es la fecha sobre la que se requiere saber si rige o no el horario de verano. La función “onSuccess”, se ejecuta en caso de éxito y recibe un parámetro para saber si la fecha ingresada pertenece al horario de verano (true) o no (false). El parámetro “onError” es la función ejecutada en caso de ocurrir un error.

A continuación un ejemplo del uso de este método:

navigator.globalization.isDayLightSavingsTime( new Date(), // Fecha a testear function (date) { // En caso de éxito if(date.dst == true) alert('La fecha ingresada pertenece al horario de verano\n'); else alert('La fecha ingresada NO pertenece al horario de verano \n'); }, function () { alert(Error al procesar fecha\n'); } // En caso de error );

El método “getFirstDayOfWeek” devuelve un número representando el primer día de la semana, de acuerdo con el calendario y preferencias del usuario. La sintaxis de la llamada es esta:

navigator.globalization.getFirstDayOfWeek(onSuccess, onError);

La función “onSuccess” es ejecutada en caso de éxito y recibe el número correspondiente al primer día de la semana empezando a contar desde uno (1), siendo este valor el correspondiente al día domingo. “onError” es ejecutada si ocurre un error.

A continuación un breve ejemplo:

navigator.globalization.getFirstDayOfWeek(



function (day) { // En caso de éxito alert('Día: ' + day.value + '\n'); }, function ( ) { // En caso de error alert('Error al obtener el día\n'); } );

La llamada “numberToString” convierte un número a cadena de acuerdo con las preferencias de usuario. La sintaxis para su uso es la siguiente:

navigator.globalization.numberToString(number, onSuccess, onError, [options]);

El parámetro “number” es el número a convertir a cadena. El segundo argumento, la función “onSuccess” se ejecuta en caso de éxito y recibe como argumento el número pasado a cadena. El tercer parámetro es la función “onError” que se ejecuta en caso de error. “options” es de carácter opcional y permite configurar la siguiente característica:

• type: Formato del número recibido. Puede ser “decimal” , “percent” (porcentaje), o “currency” (moneda).

A continuación un ejemplo del uso:

navigator.globalization.numberToString( 3.1415926, // Número a convertir function (number) {alert('Cadena: ' + number.value + '\n');}, // Función en caso de éxito function ( ) {alert('Error al convertir número\n');}, // Función en caso de error {type:'decimal'} // Opción puesta a decimal );

La llamada “stringToNumber” convierte una cadena a su correspondiente valor numérico de acuerdo con a las preferencias de usuario. La sintaxis para su uso es la siguiente:

navigator.globalization.stringToNumber (string, onSuccess, onError, [options]);

El parámetro “string” es la cadena que se desea convertir. La función “onSuccess” se ejecuta en caso de éxito y recibe como argumento el número resultado de la conversión. El tercer parámetro es la función “onError” que se ejecuta en caso de error. “options” es opcional y se comporta igual que el parámetro options del método “stringToNumber”. A continuación un ejemplo del uso:

navigator.globalization.stringToNumber ( '3.1415926', // Cadena a convertir function (number) {alert('Número ' + number.value + '\n');}, // Función en caso de éxito function ( ) {alert('Error al convertir número\n');}, // Función en caso de error



{type:'decimal'} // Opción puesta a decimal );

El método “getNumberPattern” retorna un objeto conteniendo el patrón usado para dar formato y analizar el formato de los números de acuerdo a las preferencias del usuario. Utiliza la siguiente sintaxis:

navigator.globalization.getNumberPattern(onSuccess, onError, [options]);

El primer argumento, la función “onSuccess”, se ejecuta en caso de éxito y recibe como argumento un objeto conteniendo el formato numérico usado por el usuario con las siguientes propiedades:

• pattern: El patrón usado para formatear y analizar números. • symbol: El símbolo usado al dar formato o analizar los valores correspondientes a

porcentajes o moneda. • fraction : El numero de dígitos fraccionarios usado para números. • rounding: El incremento por redondeo usado al formatear y analizar números.

• positive: El símbolo usado para valores numéricos positivos. • negative: El símbolo usado para valores numéricos negativos.

• decimal: El símbolo usado para valores decimales. • grouping: El símbolo de agrupamiento usado.

El segundo parámetro es la función “onError” que se ejecuta en caso de error. El último parámetro denominado “options” , es opcional y se comporta igual que el parámetro options del método “stringToNumber”. A continuación un ejemplo:

navigator.globalization.getNumberPattern( function (pattern) { // En caso de éxito alert('pattern: ' + pattern.pattern + '\n' + 'symbol: ' + pattern.symbol + '\n' + 'fraction: ' + pattern.fraction + '\n' + 'rounding: ' + pattern.rounding + '\n' + 'positive: ' + pattern.positive + '\n' + 'negative: ' + pattern.negative + '\n' + 'decimal: ' + pattern.decimal + '\n' + 'grouping: ' + pattern.grouping); }, function ( ) { alert('Error al obtener patrón\n'); }, // En caso de error { type: 'decimal' } // Opción a decimal );



Un posible resultado para el código anterior podría ser el siguiente:

pattern: #,##0.### symbol: . fraction: 0 rounding: 0 positive: negative: - decimal: . grouping: ,

El método “getCurrencyPattern” devuelve un objeto conteniendo el patrón para dar formato y analizar los valores de una determinada moneda, de acuerdo a las preferencias del usuario y el código de moneda ISO 4217. Utiliza la siguiente sintaxis:

navigator.globalization.getCurrencyPattern(currencyCode, onSuccess, onError);

“currencyCode” es una cadena que representa la moneda que se va analizar. La función “onSuccess”, se ejecuta en caso de éxito y recibe como argumento un objeto conteniendo el formato de moneda usado con las siguientes propiedades:

• pattern: El patrón usado para formatear y analizar moneda.

• code: El código de moneda ISO 4217 usado por el patrón. • fraction : El número de dígitos fraccionarios usado para moneda.

• rounding: El incremento por redondeo usado al formatear y analizar. • decimal: El símbolo usado para valores decimales.

• grouping: El símbolo de agrupamiento usado.

El tercer parámetro es la función “onError” que se ejecuta en caso de error. A continuación un ejemplo del uso de “getCurrencyPattern”:

navigator.globalization.getCurrencyPattern( 'USD', function (pattern) { // En caso de éxito alert('pattern: ' + pattern.pattern + '\n' + 'code: ' + pattern.code + '\n' + 'fraction: ' + pattern.fraction + '\n' + 'rounding: ' + pattern.rounding + '\n' + 'decimal: ' + pattern.decimal + '\n' + 'grouping: ' + pattern.grouping); }, function ( ) { alert('Error al obtener patrón\n'); // En caso de error }, { type: 'decimal' } // Opción a decimal );



Un posible resultado para el código anterior podría ser el siguiente:

pattern: $#,##0.##;($#,##0.##) code: USD fraction: 2 rounding: 0 decimal: . grouping: ,

5.3.10 File (Archivo)

Hemos visto hasta ahora el aprovechamiento por parte de PhoneGap de varias características que poseen los dispositivos, pero aún no hicimos referencia a una de las más importantes, la persistencia de datos. Para resolver esta necesidad contamos con el plugin “file” , basado en la implementación de la API de la W3C (World Wide Web Consortium), y permite leer, escribir y navegar el sistema de archivos del dispositivo.

Para acceder a esta característica debemos usar el siguiente comando:

$>cordova plugin add org.apache.cordova.file

Dado que este plugin es muy complejo y extenso, comenzaremos por desglosar la gran variedad de objetos que posee y sus propiedades.

Objetos usados por file (en concordancia con la W3C)

• DirectoryEntry (Representa un directorio en un sistema de archivos)

• DirectoryReader (Muestra los archivos y directorios dentro de un directorio) • File: (Este objeto contiene atributos de un sólo archivo.) • FileEntry (Representa un archivo en un sistema de archivos)

• FileError (Objeto que contiene los datos de error de archivo cuando este ocurre) • FileReader (Permite el acceso básico a un archivo)

• FileSystem (Representa el sistema de archivos) • FileWriter (Permite crear y escribir datos en un archivo)

• Flags (Banderas usadas por el objeto DirectoryEntry) • LocalFileSystem (Permite obtener sistema de archivos raíz.) • Metadata (Proporciona información sobre el estado de un archivo o directorio.)

DirectoryEntry: • isFile: Siempre retorna false. • isDirectory: Siempre retorna true. • name: El nombre del objeto DirectoryEntry, excluyendo el camino hacia el mismo.



• fullPath: El camino absoluto desde la raíz hasta DirectoryEntry.

FileEntry:

• isFile: Siempre retorna true. • isDirectory: Siempre retorna false. • name: El nombre del objeto FileEntry, excluyendo el camino hacia él mismo. • fullPath : El camino absoluto desde la raíz hasta FileEntry.

File:

• name: El nombre del archivo. • fullPath: El camino completo al archivo incluido su nombre. • type: El tipo MIME del archivo. • lastModifiedDate: La última vez que el archivo fue modificado. • size: El tamaño del archivo en bytes.

FileError:

• code: Código que indica el tipo de error. Puede ser alguno de los que sigue: o FileError.NOT_FOUND_ERR: Error por archivo no encontrado. o FileError.SECURITY_ERR: Error por falta de permisos. o FileError.ABORT_ERR: Error por cancelar operación. o FileError.NOT_READABLE_ERR: Error por archivo no legible. o FileError.ENCODING_ERR: Error por codificación inválida. o FileError.NO_MODIFICATION_ALLOWED_ERR: Error producido por archivo

no modificable. o FileError.INVALID_STATE_ERR: Error producido por estado inválido del

archivo. o FileError.SYNTAX_ERR: Error producido por sintaxis inválida. o FileError.INVALID_MODIFICATION_ERR : Error producido por modificación

inválida de archivo. o FileError.QUOTA_EXCEEDED_ERR: Error producido por exceso en el cupo de

almacenamiento. o FileError.TYPE_MISMATCH_ERR: Error producido por tipo de dato o recurso

inesperado o incorrecto. o FileError.PATH_EXISTS_ERR: Error por previa existencia de archivo.

FileReader:

• readyState: Uno de los tres posibles estados de lectura: EMPTY, LOADING o DONE. • result: El contenido del archivo que ha sido leído. • error : Un objeto conteniendo errores. • onloadstart: Función llamada cuando la lectura comienza. • onload: Función llamada cuando la lectura termina exitosamente.



• onabort: Función llamada cuando la lectura es abortada. • onerror : Función llamada cuando la lectura falla. • onloadend: Función llamada cuando la solicitud se ha completado (en caso de éxito o falla).

FileSystem

• name: El nombre del sistema de archivos. • root: El directorio raíz del sistema de archivos.

LocalFileSystem:

• LocalFileSystem.PERSISTENT: Constante que indica el uso de persistencia y la no remoción automática.

• LocalFileSystem.TEMPORARY: Constante que indica el uso de almacenamiento sin garantía de persistencia.

Metadata: • modificationTime: La fecha de la última modificación de archivo o directorio.

FileWriter:

• readyState: Uno de los tres posibles estados: INIT, WRITING, o DONE. • fileName: El nombre del archivo a ser escrito.

• length La longitud del archivo a ser escrito. • position: La actual posición del puntero en el archivo.

• error : Un objeto conteniendo errores. • onwritestart : Función llamada cuando inicia la escritura. • onwrite: Función llamada cuando la solicitud se ha completado exitosamente.

• onabort: Función llamada cuando la escritura ha sido abortada. • onerror : Función llamada cuando la escritura ha fallado.

• onwriteend: Función llamada cuando la solicitud se ha completado (en caso de éxito o falla).

Flags:

• create: Indica que el archivo o directorio debe ser creado, si no existe.

• exclusive: Si se usa con create, hace que, si existe el archivo o directorio, la llamada falle.

A continuación presentaremos la tabla 5.3 la cual permite tener una referencia rápida de todos los objetos disponibles y los métodos para interactuar con ellos:



Tabla 5.3 – Métodos provisto por el plugin file Objeto Método Detalle

getMetadata Averiguar los metadatos de un directorio

setMetadata Escribir los metadatos de un directorio

moveTo Mover un directorio a una localización diferente

copyTo Copiar un directorio a una localización diferente

DirectoryEntry toURL Retorna una URL para ayudar a encontrar un directorio

remove Borrar un directorio (debe estar vacío)

getParent Obtener el directorio padre de una carpeta

createReader Crear un nuevo DirectoryReader para leer entradas al directorio

getDirectory Crear o buscar un directorio

getFile Crear o buscar un archivo

removeRecursively Borrar un directorio y todo su contenido

DirectoryReader readEntries Leer las entradas de un directorio

getMetadata Buscar los metadatos de un archivo

setMetadata Escribir los metadatos de un archivo

moveTo Mover un archivo a una localización diferente

copyTo Copiar un archivo a una localización diferente

FileEntry toURL Retorna una URL para ayudar a encontrar un archivo

remove Borrar un archivo

getParent Obtener el directorio padre de un archivo

createWriter Crear un objeto FileWriter para escribir un archivo

file Crea un objeto archivo conteniendo propiedades de archivo

abort Abortar la lectura de un archivo

readAsDataURL Leer un archivo y retornar como URL de datos codificada en base 64

FileReader readAsText Lee un archivo de texto

readAsBinaryString Lee un archivo como binario y devuelve una cadena binaria

readAsArrayBuffer Lee un archivo como ArrayBuffer

abort Aborta la escritura del un archivo

FileWriter seek Mueve el puntero de archivo a un byte específico

truncate Acorta un archivo a la longitud especificada

write Escribe datos en un archivo

LocalFileSystem requestFileSystem Solicita un sistema de archivos

resolveLocalFileSystemURI Recupera un DirectoryEntry o FileEntry utilizando una URI local

File slice Selecciona sólo una porción del archivo que será leída

Para culminar con esta sección dedicada al plugin “file” mostraremos un pequeño ejemplo de su uso, donde crearemos dos carpetas, y dentro de ellas un archivo, sobre el cual modificaremos en tres momentos diferentes su contenido:

$(document).ready( function ( ) { document.addEventListener("deviceready", onDeviceReady, false);

function onDeviceReady() { window.requestFileSystem(LocalFileSystem.PERSISTENT, 0, gotFS, fail); }



• FileTransferError (Objeto que contiene los datos de un error al transferir) • FileUploadOptions ( Objeto pasado a FileTransfer con opciones de carga)

• FileUploadResult (Objeto pasado a FileTransfer en caso de éxito de carga)

FileTransfer:

• onprogress: Función llamada cada vez que se transfiere un nuevo fragmento de datos.

FileTransferError:

• http_status: Estado HTTP. Sólo disponible cuando se recibe un código de respuesta de la conexión HTTP.

• source: URI hacia la fuente.

• target: URI hacia el destino. • code: Código que indica el tipo de error ocurrido. Puede ser uno de los que está debajo:

o FileTransferError.FILE_NOT_FOUND_ERR: Error producido por archivo no encontrado.

o FileTransferError.INVALID_URL_ERR: Error producido por archivo inválido. o FileTransferError.CONNECTION_ERR: Error producido por problemas de

conexión. o FileTransferError.ABORT_ERR: Error al abortar operación.

FileUploadOptions:

• fileKey: El nombre del elemento a formar. Por defecto “file” . • fileName: El nombre usado cuando el archivo se guarda en el servidor.

• mimeType: El tipo MIME del archivo a transferir. Por defecto “image/jpeg”. • params: Conjunto opcional de pares “key/value” para pasar a la petición HTTP. • chunkedMode: Si se cargarán los datos en modo de transmisión fragmentada. Por defecto

true. • headers: Un mapa de valores name/header para la cabecera.

FileUploadResult:

• bytesSent: El número de bytes enviados al servidor como parte de la carga. • responseCode: El código de respuesta HTTP devuelta por el servidor. • response: La respuesta HTTP devuelta por el servidor.

Métodos para file-transfer

• upload • download • abort



El método “upload” permite enviar un archivo a un servidor. Su sintaxis es la siguiente:

upload( filePath, sever, onSuccess, onError,[trustAllHosts], [options] );

El primer argumento, “filePath” , representa la dirección absoluta del archivo en el dispositivo. “server” es la URL del servidor que recibirá el archivo, codificada por encodeURI(). “onSuccess” es la función llamada en caso de éxito con un parámetro tipo FileUploadResult. En caso de error se ejecuta la función “onError” . El parámetro opcional “trustAllHosts” (que por defecto esta en false) indica si se aceptan todos los certificados de seguridad o no. Finalmente el argumento opcional “options” permite configurar (por medio de un objeto llamado FileUploadOptions) el comportamiento de esta llamada.

A continuación presentamos un pequeño ejemplo de cómo sería el uso de este método para la carga de un archivo de texto simple suponiendo que la variable “fileURL” contiene una URL válida a un archivo de texto en el dispositivo.

// En caso de éxito se recibe el control junto con el objeto FileUploadResult var onSuccess function (r) { alert ("Code = " + r.responseCode + "\n" + "Response = " + r.response + "\n" + "Sent = " + r.bytesSent); } var onError = function (error) { alert("An error has occurred: Code = " + error.code + "\n" + "upload error source " + error.source + "\n" + "upload error target " + error.target); } // Opciones para la transferencia var options = new FileUploadOptions(); options.fileKey = "file"; options.fileName = fileURL.substr(fileURL.lastIndexOf('/') + 1); options.mimeType = "text/plain"; // Tipo de archivo: texto plano // Parámetros enviados al servidor var params = {}; params.value1 = "test"; params.value2 = "param"; options.params = params; var ft = new FileTransfer(); // Objeto que permite la transferencia de archivos ft.upload(fileURL, encodeURI("http://server.com/upload.php"), onSuccess, onError, options);

El método “download” permite descargar un archivo desde un servidor. Su sintaxis es la siguiente:

download( source, target, onSuccess, onError,[trustAllHosts], [options] );



El primer argumento, “source”, representa la URL del archivo a descargar en el servidor codificada por encodeURI(). El parámetro “target” es la URL que representa el fichero en el sistema de archivos del dispositivo. “onSuccess” es la función llamada en caso de éxito con un parámetro tipo FileEntry. En caso de error se ejecuta la función “onError” . El parámetro opcional “trustAllHosts” (que por defecto esta en false) indica si se aceptan todos los certificados de seguridad o no. Finalmente el argumento opcional “options”, permite configurar sólo el parámetro headers.

A continuación un ejemplo del uso de este método, suponiendo que la variable “fileURL” contiene una URL válida a un archivo de texto en el dispositivo:

// En caso de éxito se recibe el control y el objeto FileEntry var onSuccess function (entry) { alert("Descarga completa: " + entry.fullPath); } var onError = function (error) { alert("Ocurrió un error: Código = " + error.code + "\n" + "Error en la fuente: " + error.source + "\n" + "Error en el destino " + error.target); } var ft = new FileTransfer(); // Objeto que permite la transferencia de archivos var uri = encodeURI("http://server.com/download.php"); // Archivo a descargar var option = headers: { Cabecera "Authorization": "Basic dGVzdHVzZXJuYW1lOnRlc3RwYXNzd29yZA==" }; ft.download(uri, fileURL, onSuccess, onError, options);

El último método ofrecido es “abort” . El mismo permite detener una transferencia en progreso. Su sintaxis es la siguiente:

abort();

Como se puede observar la función no recibe parámetros. Un ejemplo de su utilización se muestra a continuación:

// En caso de éxito var onSuccess = function(r) { alert("No debe ser llamada si se aborta antes"); } // En caso de error o de que se aborte la transferencia en este caso var onError = function(error) { // error.code == FileTransferError.ABORT_ERR alert("Ocurrió un error: Código = " + error.code); } var options = new FileUploadOptions();



options.fileKey="file" ; options.fileName="myphoto.jpg"; options.mimeType="image/jpeg"; var ft = new FileTransfer(); ft.upload(fileURL, encodeURI("http://server.com/upload.php"), onSuccess, onError, options); ft.abort(); // Se aborta la carga del archivo

5.3.12 InAppBrowser (Navegador embebido)

Este plugin es sin dudas, uno de los más raros de los ofrecidos por PhoneGap, en el sentido de que a priori, no parece de una utilidad evidente. Por supuesto esto dependerá del problema que se nos presente y seguramente existen muchísimos casos en los que sería de gran ayuda. Estamos hablando de “InAppBrowser” , el cual nos da la posibilidad de ejecutar un navegador (browser) dentro de nuestra aplicación.

Su instalación tiene la siguiente sintaxis:

$>cordova plugin add org.apache.cordova.inappbrowser

“InAppBrowser” es invocado cuando se ejecuta la llamada al método JavaScript, window.open(), o bien cuando un link de la forma <a target=“_blank”> es abierto.

Métodos de InAppBrowser

• addEventListener • removeEventListener • close • show • executeScript • insertCSS

El método “addEventListener” permite agregar un manejador para un evento ocurrido en InAppBrowser. Su sintaxis es la siguiente:

addEventListener(eventname, callback);

El argumento “eventname” es el evento a escuchar y puede ser cualquiera de los que sigue:

• loadstart: Evento lanzado cuando el InAppBrowser empieza a cargar una URL. • loadstop: Evento lanzado cuando el InAppBrowser termina de cargar una URL.

• loaderror : Evento lanzado cuando el InAppBrowser encuentra un error al cargar una URL. • exit: Evento lanzado cuando la ventana del InAppBrowser es cerrada.



El parámetro denominado “callback” , es una llamada que se ejecuta cuando el evento capturado es lanzado. Esta función recibe como parámetro un objeto. InAppBrowserEvent que tiene las siguientes propiedades:

• type: Es el nombre del evento (loadstart, loadstop, loaderror, o exit). • url : La URL que ha sido cargada.

• code: El código de error, sólo para el caso de loaderror. • message: El mensaje de error, sólo para el caso de loaderror.

Ejemplo breve de su uso:

var ref = window.open('http://apache.org', '_blank', 'location=yes'); // Se ejecuta InAppBrowser ref.addEventListener('loadstart', function( ) { // Se configura evento alert(event.url); });

El método “removeEventListener” permite quitar el manejador de un evento configurado para InAppBrowser. Su sintaxis es la siguiente:

removeEventListener(eventname, callback);

Los argumentos son los mismos que para el método “InAppBrowser” . A continuación un ejemplo breve de su uso:

var ref = window.open('http://apache.org', '_blank', 'location=yes'); // Se ejecuta InAppBrowser var myCallBack = function() { alert(event.url); } ref.addEventListener('loadstart', myCallBack); // Se configura evento ref.removeEventListener('loadstart', myCallBack); // Se quita evento

El método “close” permite cerrar una ventana del tipo “InAppBrowser”. Su sintaxis es la siguiente:

close();

A continuación un ejemplo de su utilización:

var ref = window.open('http://apache.org', '_blank', 'location=yes'); // Se ejecuta InAppBrowser ref.close(); // Se cierra el objeto InAppBrowser



El método “show” permite mostrar una ventana “InAppBrowser” que fue abierta como oculta (hidden). Esta llamada no tiene ningún efecto si la ventana ya se encuentra visible. La sintaxis que utiliza es la siguiente:

show();

A continuación un ejemplo de su utilización:

var ref = window.open('http://apache.org', '_blank', 'hidden=yes'); // Abre una ventana oculta // Se hace algo ref.show(); // Se muestra el objeto InAppBrowser que estaba oculto

El método “executeScript” permite inyectar código JavaScript en la ventana “InAppBrowser” . Su sintaxis es la que sigue:

executeScript(injectDetails, callback);

El parámetro “injectDetails” detalla la secuencia de comandos a ejecutar, especificando un archivo o código fuente:

• file: La URL con el script a inyectar. • code: Texto con los comandos a inyectar.

El argumento “callback” es la función que se ejecuta luego de que el código JavaScript es inyectado.

var ref = window.open('http://apache.org', '_blank', 'location=yes'); ref.addEventListener('loadstop', function() { ref.executeScript( { file: "myscript.js" } ); Se configura el archivo con el script });

El método “insertCSS” permite inyectar código CSS (hoja de estilos en cascada) en la ventana “InAppBrowser” . Su sintaxis es la que sigue:

insertCSS(injectDetails, callback);

El parámetro “injectDetails” detalla la secuencia de estilos a aplicar, especificando un archivo o código fuente:



• file: La URL a una hoja de estilos a inyectar. • code: Texto con los comandos CSS a inyectar.

El argumento “callback” es la función que se ejecuta luego de que el código CSS es inyectado.

var ref = window.open('http://apache.org', '_blank', 'location=yes'); ref.addEventListener('loadstop', function() { ref.insertCSS( { file: "mystyles.css" } ); //Se configura el archivo con la hoja de estilos });

5.3.13 Splashscreen (Pantalla de Bienvenida)

Este plugin permite mostrar y ocultar la pantalla de bienvenida de la aplicación desarrollada. Su instalación es la siguiente:

$>cordova plugin add org.apache.cordova.splashscreen

Métodos de splashscreen

• splashscreen.show • splashscreen.hide

El método “show” permite mostrar la pantalla de bienvenida. La sintaxis de esta llamada es

la siguiente:

navigator.splashscreen.show();

El método “hide” permite ocultar la pantalla de bienvenida. La sintaxis de esta llamada es la

siguiente:

navigator.splashscreen.hide();

NOTA : se deben crear los iconos necesarios para que se visualice la pantalla de bienvenida, dentro de la carpeta raíz del proyecto, como se muestra a continuación:

• www/res/icon/android/icon-36-ldpi.png (426 × 320 pixeles)

• www/res/icon/android/icon-48-mdpi.png (470 × 320 pixeles) • www/res/icon/android/icon-72-hdpi.png (640 × 480 pixeles)

• www/res/icon/android/icon-96-xhdpi.png (960 × 720 pixeles)



5.3.14 Battery-status (Estado de batería)

Este plugin de PhoneGap permite supervisar el estado de la batería del dispositivo. Su instalación es mediante el siguiente comando:

$>cordova plugin add org.apache.cordova.battery-status

Eventos manejados

• batterystatus • batterycritical

• batterylow

El evento “batterystatus” se desencadena cuando el porcentaje de carga de la batería cambia por lo menos en un uno por ciento, o bien si el dispositivo es conectado o desconectado.

El evento “batterycritical” es disparado cuando el porcentaje de carga de la batería ha alcanzado el umbral crítico. Ese valor es específico de cada dispositivo.

• El evento “batterylow” es disparado cuando el porcentaje de carga ha alcanzado el umbral de batería baja. Ese valor es específico de cada dispositivo

Para agregar la captura de estos eventos la sintaxis es la que sigue:

window.addEventListener(“batterystatus”, onBatteryStatus, false);

window.addEventListener(“batterycritical”, onBatteryCritical, false);

window.addEventListener(“batterylow”, onBatteryLow, false);

Donde “onBatteryStatus”, “onBatteryCritical” y “onBatteryLow” son los métodos que serán llamados en caso de que ocurran los eventos pertinentes. Estas funciones reciben como parámetro un objeto con los siguientes campos:

• level: El porcentaje que representa el nivel de carga de la batería del dispositivo con un número de 0 a 100.

• isPlugged: Un booleano que indica si el dispositivo está conectado. A continuación un pequeño código de ejemplo:

$(document).ready( function ( ) { document.addEventListener("deviceready", onDeviceReady, false); function onDeviceReady() { window.addEventListener('batterylow, function(info){ alert('Batería baja:' + info.level + '%'); }, false); } }); //Fin Ready



5.3.15 Network-information (Información sobre red)

Este plugin proporciona información acerca de la conexión celular e inalámbrica del dispositivo y si el mismo tiene una conexión a Internet. El comando de instalación es el siguiente:

$>cordova plugin add org.apache.cordova.network-information

Propiedades de la conexión

• connection.type (Permite conocer el estado actual de conexión del dispositivo)

Utiliza la siguiente sintaxis:

var networkState = navigator.connection.type;

Distingue entre las siguientes constantes:

• Connection.UNKNOWN: Conexión desconocida.

• Connection.ETHERNET: Conexión tipo Ethernet.

• Connection.WIFI: Conexión tipo Wireless.

• Connection.CELL_2G: Conexión tipo 2G.

• Connection.CELL_3G: Conexión tipo 3G. • Connection.CELL_4G: Conexión tipo 4G.

• Connection.CELL: Conexión genérica.

• Connection.NONE: Sin conexión de red.

Eventos de network-information

• online • offline

El evento “online” ocurre cuando un dispositivo previamente desconectado, recibe una conexión de red de modo que, la aplicación puede acceder a Internet.

El evento “offline” se desencadena cuando un dispositivo previamente conectado, pierde la conexión de red de modo que, la aplicación ya no puede acceder a Internet.

Para capturar los eventos nombrados la sintaxis es la siguiente

window.addEventListener(“online”, onOnline, false);

window.addEventListener(“offline”, onOffline, false);

Donde “onOnline” y “onOffline” son las funciones ejecutadas al ocurrir los eventos.



5.3.16 Dialogs (Diálogos)

Este plugin permite emitir notificaciones al usuario de la aplicación. Podremos enviar mensajes de notificación, pedir un dato, solicitar la confirmación para realizar determinada acción e inclusive emitir un pitido de aviso.

Para acceder a esta característica debemos ejecutar el siguiente comando:

$>cordova plugin add org.apache.cordova.dialogs

Métodos para dialogs

• navigator.notification.alert

• navigator.notification.confirm • navigator.notification.prompt

• navigator.notification.beep

El método “alert” muestra un mensaje de alerta mediante un cuadro de diálogo personalizable. Su sintaxis es la siguiente:

navigator.notification.alert(message, alertCallback, [title], [buttonName])

El argumento “message” representa el mensaje a mostrar al usuario. “alertCallback” es la función ejecutada al cerrarse el cuadro de dialogo. “title” representa el título del mensaje y es opcional (por defecto se muestra “Alert” ). El último parámetro, también opcional, llamado “buttonName”, es el nombre que tendrá el único botón mostrado (por defecto el valor es “OK” ).

Un ejemplo de su uso se muestra a continuación:

navigator.notification.alert( 'Has ganado!', // Mensaje alertDismissed, // Función llamada 'Juego terminado', // Titulo 'Continuar' // Nombre del botón );

El método “confirm” muestra un cuadro de diálogo personalizable de confirmación. Su sintaxis es la siguiente:

navigator.notification.confirm(message, confirmCallback, [title], [buttonLabels])



El argumento “message” representa el mensaje a mostrar al usuario. “confirmCallback” es la función invocada recibiendo el índice del botón presionado (“1”, “2”, “3”, etc.) o “0” si el dialogo se cerró sin presionar un botón. “title” representa el título del mensaje y es opcional (por defecto se muestra “Confirm” ). El último parámetro, también opcional, llamado “buttonLabels”, es un arreglo de cadenas que especifican las etiquetas de los botones (por defecto es [“OK” ,”Cancel” ]). Un ejemplo de su uso se muestra a continuación:

function onConfirm(buttonIndex) { alert('El botón presionado fue: ' + buttonIndex); } navigator.notification.confirm( 'Has ganado!', // Mensaje onConfirm, // Función llamada 'Juego terminado', // Titulo ['Reiniciar','Salir'] // Nombre de los botones );

El método “prompt” muestra un cuadro de diálogo personalizable que permite la captura de una cadena de texto ingresada por parte del usuario. Su sintaxis es la siguiente:

navigator.notification.prompt(message, promptCall, [title], [buttonLabels], [defText])

El argumento “message” representa el mensaje a mostrar al usuario. “promptCall” es la

función invocada al cerrarse la ventana de diálogo que recibe un objeto con los parámetros:

• buttonIndex: El índice del botón presionado (“1”, “2”, “3”, etc.) o “0” si el diálogo se cerró sin presionar un botón.

• input1: Es el texto ingresado por el usuario.

El argumento “title” representa el título del mensaje y es opcional (por defecto se muestra “Prompt” ). El cuarto parámetro, también opcional, llamado “buttonLabels”, es un arreglo de cadenas que especifican las etiquetas de los botones (por defecto es [“OK” ,”Cancel” ]). “defText” es la cadena por defecto en caso de que el usuario no ingrese nada (si no se completa este argumento esta opción se configura como una cadena vacía). Un ejemplo del uso de la llamada “prompt” se muestra a continuación:

function onPrompt(result) { alert('El botón presionado: ' + result.buttonIndex + ' cadena ingresada: ' + result.input1); }

navigator.notification.prompt( 'Por favor ingrese su nombre, // Mensaje onPrompt, // Función llamada 'Registración', // Titulo ['Reiniciar','Salir'] // Nombres de los botones 'Jane Doe' // Texto por defecto );



El último de método listado, denominado “beep”, permite que el dispositivo reproduzca un pitido. La sintaxis de la llamada es la siguiente:

navigator.notification.beep(times);

El único argumento recibido por este método es “times” que indica la cantidad de veces que el dispositivo reproducirá un pitido o beep. El sonido reproducido será el configurado por defecto para los mensajes de texto.

A continuación un ejemplo de su uso:

// Se reproducen dos pitidos navigator.notification.beep(2);

5.3.17 Vibration (Vibración)

El último de los plugins de PhoneGap que presentaremos nos proporciona la posibilidad de hacer vibrar el dispositivo. Su instalación se lleva a cabo con el siguiente comando:

$>cordova plugin add org.apache.cordova.vibration

Es común utilizar esta característica para notificar al usuario de que ocurrió algún tipo de evento. La sintaxis de uso es la siguiente:

navigator.notification.vibrate( [time] )

Donde el único parámetro de la llamada es “time”, y permite configurar la duración de la vibración en milisegundos. A continuación un breve ejemplo:

// Se hace vibrar el dispositivo por tres segundos navigator.notification.vibrate (3000);



6. CREANDO UN PLUGIN

6.1 Introducción

Las principales características de la API de PhoneGap, a partir de la tercera versión, están implementadas como plugins. Además de estos, hay muchos otros disponibles, que habilitan al desarrollador recursos como: escáner de códigos de barra, comunicación NFC (para pagos mediante dispositivos móviles), calendarios configurables, acceso a redes sociales, por nombrar algunos ejemplos.

Sin embargo, aún con toda esa parafernalia, existe la posibilidad de que requiramos una funcionalidad determinada que no se encuentre desarrollada, o bien, que su implementación no se ajuste a nuestras necesidades. Entonces surge la obvia pregunta: ¿Podemos desarrollar nosotros nuestro propio plugin a medida? La respuesta es sí.

Este capítulo pretende explicar en primer lugar, cómo está concebida la estructura interna de un plugin para, posteriormente, desmenuzar en qué consiste su implementación. Sobre el final se verá un breve ejemplo para hacer más gráfico lo expuesto.

El material con el cual fue contruido el siguiente apartado fue obtenido de los sitios web: “http://docs.phonegap.com” y “http://cordova.apache.org”.



6.2 Estructura de un plugin

Todo plugin PhoneGap consta siempre de dos partes bien definidas. Un segmento genérico (el mismo para todas las plataformas), implementado en lenguaje JavaScript, y otro específico para cada plataforma, escrito en el código nativo correspondiente. Visto gráficamente, un plugin se puede encuadrar dentro del siguiente esquema (figura 6.1):

Fig. 6.1 – Estructura básica de funcionamiento de PhoneGap y los plugins

(fuente: www.blog.koalite.com, 2012)

Se puede observar que en el primer nodo de la figura 6.1, se encuentra la aplicación

PhoneGap desarrollada, en lenguaje HTML. A su vez en la parte inferior se muestran las dos partes del plugin (“Plugin JS” y “Plugin nativo” , fragmentos JavaScript y nativo respectivamente) que deben ser implementados por nosotros. En el centro vemos cómo los componentes provistos por PhoneGap: “Cordova JS” y “Cordova Nativo”, se comunican entre sí, haciendo de puente entre la parte nativa y la parte JavaScript, permitiendo así la creación del producto final, la “Aplicación Nativa”.

Otra manera de ver la implementación de un plugin podría ser mediante la jerarquía de carpetas que utiliza. En la figura 6.2 se muestra un sencillo ejemplo de la implementación de un plugin llamado “EchoPlugin” :

Fig. 6.2 – Ejemplo de carpetas usadas por un plugin

En la figura 6.2 se pueden apreciar dos carpetas principales. La primera denominada “src” , que contiene a su vez dos subcarpetas llamadas “android” e “ios” . Las mismas contienen el código



nativo necesario para poder funcionar en las plataformas Android e iOS respectivamente. Se puede ver en el caso del directorio “ios”, el detalle de los ficheros (codificados en lenguaje Objective-C) usados para esa plataforma.

La segunda carpeta llamada “www” , contiene el código JavaScript, que como habíamos comentado anteriormente, es genérico. Es por esa razón que este directorio sólo contiene un archivo, dado que el mismo será usado por todas las plataformas implementadas.



6.3 Construcción de un plugin

Cuando se comienza a desarrollar un nuevo plugin, se debe crear el archivo “plugin.xml” . Este debe ser un documento “XML” en el espacio de nombres de plugins: “http://apache.org/cordova/ns/plugins/1.0”, característica que se indica en la etiqueta de más alto nivel, junto con el identificador del plugin y la versión del mismo. Los elementos hijos definen la estructura del plugin. Este archivo debe estar en el nivel más alto dentro del directorio del plugin. Hay muchas formas de configurarlo. A continuación se muestra una versión abreviada del plugin “device” que sirve de ejemplo <?xml version="1.0" encoding="UTF-8"?> <plugin xmlns="http://apache.org/cordova/ns/plugins/1.0" id="org.apache.cordova.device" version="0.2.3"> <name>Device</name> <description>Cordova Device Plugin</description> <license>Apache 2.0</license> <keywords>cordova, device</keywords> <js-module src="www/device.js" name="device"> <clobbers target "device"/> </js-module> <platform name="ios"> <config-file target="config.xml" parent="/*" > <feature name="Device"> <param name="ios-package" value="CDVDevice"/> </feature> </config-file> <header-file src="src/ios/CDVDevice.h"/> <source-file src="src/ios/CDVDevice.m"/> </platform> </plugin>

El significado de las etiquetas del modelo presentado es el siguiente:

• xmlns: indica cual es el espacio de nombres utilizado por el plugin, “http://apache.org/cordova/ns/plugins/1.0”, en este caso.

• id: atributo que acompaña al anterior y que identifica al paquete del plugin. Usa el mismo formato de dominio inverso que el comando del CLI que agrega el plugin.

• version: número de versión del plugin. • js-module: especifica la ruta de la interfaz JavaScript común. • clobbers: éste dentro de “js-module”, modifica el JavaScript del plugin para incluir

referencia a una variable global a la que se puede acceder en todo momento para hacer uso del plugin.

• platform: Especifica un conjunto de valores de acuerdo a la plataforma, iOS en este caso. • config-file: Encapsula una etiqueta “feature” (característica) que es inyectada en el archivo

“config.xml” específico de la plataforma, para hacerla consciente de la biblioteca de código adicional.



• header-file y source-file: Especifican la ruta de acceso a los archivos componentes de la librería, cabecera y fuente respectivamente.

6.3.1 La interfaz JavaScript

JavaScript proporciona una interfaz genérica, por lo que quizás, es la parte más importante del plugin. Se puede estructurar el plugin JavaScript de la manera que se necesite, pero se debe llamar a “cordova.exec” para la comunicación con la plataforma nativa, usando la siguiente sintaxis:

cordova.exec(function( winParam ) { }, function( error ) { }, "service", "action", ["firstArgument", "secondArgument", 42, false] //Lista de argumentos );

A continuación se describe el uso de los parámetros mencionados:

• function(winParam): Función en caso de éxito. Asumiendo que la llamada exec se completa exitosamente, se ejecuta recibiendo la lista de parámetros winParam que son pasados en ella.

• function(error): Función en caso de error. Si la operación no se realiza con éxito, entonces este método se ejecuta con un parámetro de error opcional

• “service”: El nombre de servicio para llamar del lado nativo. Esto corresponde a una clase nativa.

• “action” : El nombre de la acción para llamar del lado nativo. Este en general corresponde al método de la clase nativa.

• [/* argumentos */]: Un arreglo de argumentos que se pasan al ambiente nativo.

6.3.2 La interfaz nativa

Una vez que se ha definido el código JavaScript para el plugin, se lo debe complementar con al menos una implementación nativa. Las plataformas mencionadas a continuación soportan el uso de plugins PhoneGap.

• Amazon Fire OS

• Android • iOS

• BlackBerry 10 • Windows Phone



6.4 Implementando un plugin

A continuación se mostrará la implementación de un plugin al que denominaremos “Echo” . No es más que una función que envía una cadena de texto a un proceso nativo y, si tiene éxito, vuelve a recibir la misma secuencia de caracteres. En caso contrario se regresa un mensaje de error.

6.4.1 Interfaz JavaScript

A continuación se muestra una forma de implementar la interfaz JavaScript del plugin. Este código será guardado en un archivo al que llamaremos “echo.js”.

window.echo = function(str, success) { cordova.exec( success, // Primer parámetro function(err) { // Segundo parámetro success ('Nothing to echo.'); }, "Echo", // Tercer parámetro "echo", // Cuarto parámetro [ str ] // Quinto parámetro ); };

Analizaremos primero los últimos tres argumentos de la función cordova.exec. El tercer parámetro llama al servicio “Echo” , nombre de la clase (nativa). El cuarto, hace la solicitud de la acción “echo” , un método dentro de esta clase. El quinto es un arreglo de parámetros que contiene la cadena a la que se le aplicará el eco, y que es el primer parámetro de la función window.echo.

La función “success” pasada a exec es simplemente una referencia para que la llamada a window.echo tome. Si la plataforma nativa dispara la llamada de error, simplemente se llama a esa función y le pasa una cadena predeterminada.

Los usuarios del plugin lo invocarán de la siguiente manera:

window.echo("echome", function(echoValue) { alert(echoValue == "echome");// debe mostrar verdadero });

El código anterior retornará verdadero en caso de que la cadena enviada sea igual a la recibida (“echome”) o falso en otro caso.

6.4.2 Interfaz nativa (Android)

Para relacionar la interfaz JavaScript del plugin de nuestro ejemplo con la implementación nativa, se debe crear el archivo “plugin.xml” , dentro de la carpeta de nuestro plugin para que luego,



se inyecte la especificación de la nueva característica en el archivo “config.xml” de la plataforma local.

<platform name="android"> <config-file target="config.xml" parent="/*" > <feature name="Echo"> <param name="android-package" value="org.apache.cordova.plugin.Echo"/> </feature> </config-file> </platform>

Luego agregamos el archivo “src/org/apache/cordova/plugin/Echo.java” al plugin:

package org.apache.cordova.plugin; import org.apache.cordova.CordovaPlugin; import org.apache.cordova.CallbackContext; import org.json.JSONArray; import org.json.JSONException; import org.json.JSONObject; public class Echo extends CordovaPlugin{ public Boolean execute(String action, JSON Array args, CallbackContext call) throws JSONException{ if(action.equals(“echo”);{ String message = args.getString(0); this.echo(message, call); return true; } return false; } private void echo(String message, CallbackContext call) { if(message !=null && message.length() > 0) { call.success(message); } else { call.error(“Se esperaba una cadena no vacía”); } } }

Las librerías necesarias se importan en la parte superior del archivo. Además se crea la clase Echo, la cual extiende a la clase CordovaPlugin, cuyo método execute() es sobrescrito para recibir mensajes de exec(). El método execute() comprueba primero, el valor de la acción, en este caso sólo hay un valor echo válido. Cualquier otra acción devuelve falso y da lugar a un error INVALID_ACTION, que se traduce en una función de error del lado de JavaScript.

A continuación, el método recupera la cadena de echo utilizando el método getString() del objeto args, que especifica el primer parámetro pasado al método. Después de que el valor se pasa a un método echo() privado, es chequeado para asegurarse de que no es nulo o una cadena vacía, en



cuyo caso call.error() invoca la función de error de JavaScript. Si los diversos controles pasan, call.success() pasa la cadena del mensaje original de nuevo a la función de éxito del lado JavaScript como parámetro.

6.4.3 Agregar referencia al plugin

Por último no debemos olvidar agregar la referencia al plugin. Para eso editamos el archivo “index.html” de nuestro proyecto, agregando en el head del mismo la línea siguiente:

<script src="echo.js"></script>



6.5 Otros plugins para PhoneGap

Para concluir este capítulo, presentaremos un listado de algunos plugins oficiales y no oficiales de PhoneGap, pero muy usados por la comunidad desarrolladora. Por supuesto existen muchísimos más. Esta lista es sólo a modo ilustrativo y con el fin de mostrar la diversidad de opciones y posibilidades que el framework posee en esta materia.

� Apache Cordova Facebook Plugin: Este es el plugin oficial de Facebook para PhoneGap.

Permite utilizar el mismo código JavaScript en nuestra aplicación tal como es usado en una aplicación web.

� GAPlugin para Google Analytics: Plugin actualmente disponible para las plataformas iOS y Android. Permite publicar información sobre el uso de la aplicación a su cuenta de Google Analytics.

� YTPhoneGapPlugin: Permite integrar un reproductor para videos de Youtube en una aplicación PhoneGap para la plataforma Android.

� PhoneGapBarcode Scanner Plugin: Este plugin actualmente existe tanto para Android como para iOS. Permite escanear y decodificar un código de barras en cuestión de segundos. Posee soporte para la mayoría de los formatos usados actualmente, desde los conocidos códigos de barra al más moderno tipo QR.

� PushPlugin: Permite a las aplicaciones recibir notificaciones tipo “push” (el servidor puede enviar un mensaje al dispositivo sin previa conexión cuando tiene una información o notificación nueva). La implementación existe tanto en Android como en iOS.

� Flashlight: Permite encender y apagar la linterna (flash) del dispositivo. Disponible para Android, iOS y Windows Phone 8.

� Calendar: Este plugin permite manipular el calendario nativo. Sólo implementado para Android e iOS.

� Cordova-zip-plugin: Es usado para descomprimir archivos en Android e iOS



7. DESARROLLO PROPUESTO

7.1 Introducción

Habíamos planteado en su momento como uno de los objetivos principales de esta Tesina, el desarrollo de una aplicación para dispositivos móviles mediante alguna de las herramientas existentes. Llegados a este punto sabemos que esa herramienta se llama PhoneGap. Es por eso que en este capítulo nos centraremos en la realización de una prueba empírica con este framework para tener a ciencia cierta, una experiencia de primera mano. Si bien hemos estudiado sus características a lo largo de los capítulos anteriores, sólo luego de experimentar con ella, podremos expedir un veredicto en relación a sus virtudes y falencias.

Es por ello que a continuación formularemos el enunciado de un problema a resolver. Si bien el mismo no representará la demanda de un usuario real, contendrá todos los ingredientes necesarios que tendría cualquier aplicación de similares características. Especificaremos a tal efecto los requisitos necesarios para posteriormente, presentar el diseño y desarrollo de nuestra aplicación.



7.2 Problema propuesto

7.2.1 Resumen

Se requiere la implementación de un sistema informático para la gestión de la historia clínica de los pacientes de una institución médica. La misma debe ser capaz de correr sobre un dispositivo móvil tipo Tablet, Smartphone o similar, bajo la plataforma “Android” .

7.2.2 Enunciado

Con el fin de simplificar la captura y organización de los datos referidos a la historia clínica de cada uno de los pacientes atendidos por los profesionales de una institución médica, se requiere la implementación de un sistema informático a tal efecto. El mismo debe funcionar en el teléfono móvil de cada profesional y ser capaz de llevar la historia clínica de sus pacientes en formato digital. La aplicación debe funcionar de manera autónoma con persistencia de datos y proveer las siguientes funcionalidades básicas:

� Creación de un nuevo Paciente. � Modificación de un Paciente existente. � Eliminación de un Paciente existente. � Creación y asociación de una consulta con un paciente. � Modificación de una consulta para un determinado paciente. � Eliminación de una consulta para un determinado paciente. � Altas, bajas y modificaciones de medicamentos. � Altas, bajas y modificaciones de vacunas. � Altas, bajas y modificaciones de prácticas médicas. � Altas, bajas y modificaciones de especialidades. � Altas, bajas y modificaciones de patologías. � Altas, bajas y modificaciones de obras sociales. � Altas, bajas y modificaciones de tablas suplementarias. � Grafica con el histórico de los pesos de un paciente. � Grafica con el histórico de las tensiones arteriales de un paciente. � Grafica con el histórico de frecuencias cardíacas de un paciente. � Reporte en texto o PDF de la historia clínica completa de un paciente.

Además de las funciones nombradas, se requiere poder conocer mediante esta aplicación, la distancia a la que cada uno de los profesionales se encuentra del establecimiento. En dicho edificio se debe poder contar con un servidor que, mediante internet, permita listar los profesionales y la distancia a la que distan del mismo.

El sistema debe correr bajo la plataforma “Android” , pero no se descarta la posibilidad futura de ser implementado para los sistemas operativos “BlackBerry 10” e “iOS” .



7.2.3 Datos básicos requeridos

• Paciente: o Nombre o Apellido o Tipo y número de documento o Sexo/género o Fecha de nacimiento o Estado civil o Email o Teléfono o Domicilio o País de nacimiento o Obra social o Talla actual o Peso actual o Patologías crónicas o Número de afiliado

• Consulta:

o Fecha y hora de consulta o Talla o Peso o Presiones sistólica y diastólica o Frecuencia cardíaca o Motivo de consulta o Patologías diagnosticadas o Vacunas recetadas o Medicación recetada o Prácticas médicas solicitadas o Especialidad a la que se deriva o Pronóstico o Observaciones del profesional

• Vacunas:

o Nombre

• Medicación: o Nombre

• Práctica:

o Nombre



• Especialidad: o Nombre

• Patología:

o Nombre

• Profesional: o Nombre o Localidad o Especialidades

Además de los datos nombrados en “Datos básicos requeridos”, se desea contar con la posibilidad de cargar la foto de cada uno de los pacientes. Cabe aclarar que toda esta información estará y funcionará de manera autónoma en cada dispositivo móvil. Únicamente se requerirá guardar en el servidor los siguientes datos:

• Profesional: o Nombre o Localidad o Especialidades o Distancia a la que se encuentra o Última hora de actualización de la información

• Servidor o Ubicación

Nota: Este enunciado surgió de una idea inicial propuesta por un médico amigo y fue pulida posteriormente, con ayuda de otros profesionales de la salud mediante entrevistas. Es un planteo minimalista y seguramente perfectible, pero cumple con los requisitos básicos que se pueden encontrar en aplicaciones de similares características.



7.3 Diseño de la solución

Dado que el problema ya está planteado, podemos comenzar a diseñar la base de datos de nuestra aplicación a la que llamaremos de ahora en más “DigitalHC” . Pero antes de poder comenzar con el diseño “per se” , es necesario resolver un interrogante: ¿Con qué técnicas o mecanismos de persistencia de datos contamos?

7.3.1 Selección de método de persistencia de datos

Decidimos utilizar alguno de los métodos provistos por PhoneGap sin la necesidad de caer en algún complemento o artilugio extra. Las opciones provistas por este framework son:

• Plugin “file” (API de PhoneGap) • WebStorage • WebSQL • IndexedDB

Plugin file

Este plugin implementado por PhoneGap en concordancia con las recomendaciones de la W3C, fue estudiado en el capítulo quinto relacionado con la API del framework. Esta opción fue descartada rápidamente por un simple hecho: si bien provee la capacidad de persistencia, no proporciona ningún tipo de estructura o lógica para el ordenamiento de los datos. Esto implica que dicha lógica debe ser implementada “tracción a sangre” por nosotros. Habiendo otras opciones que proveen ese tipo de funcionalidades, el descarte de esta opción fue una decisión sencilla.

WebStorage

Proporciona acceso a una interfaz W3C almacenamiento (W3C Storage). Permite datos persistentes mediante el concepto de par: “Clave/Valor” (key/value). Estos datos pueden ser, por ejemplo, variables locales, información en base 64 y arreglos. Se divide en dos vertientes, el “SessionStorage”, para guardar información que caducará al final de la sesión, en nuestro caso al cerrarse la aplicación, y el “LocalStorage”, que permite almacenar datos que perduren entre distintas sesiones de usuario. Permite crear archivos de datos con topes que varían entre los 5 y los 10 megabytes como máximo, según la implementación. En la actualidad es compatible con todas las plataformas.

WebSQL

Proporciona toda la potencia de una base de datos relacional SQL estructurada con un set de instrucciones de menor tamaño. De todos modos contiene lo necesario para el almacenamiento de los tipos de datos básicos como números, cadenas de caracteres y fechas. Desde 2010 la W3C ha dado por obsoleto WebSQL. Sin embargo PhoneGap sigue brindando soporte para su utilización.



Permite crear bases de datos de hasta 5 megabytes sin interacción del usuario, luego podría solicitar permiso para ampliar su capacidad, dependiendo de la implementación.

WebSQL puede ser utilizado en las siguientes plataformas:

• Android

• BlackBerry 10 • iOS • Tizen

IndexedDB

Es un punto intermedio entre WebSQL y WebStorage. Se trata de un almacén de objetos JavaScript donde se guarda un par de valores “clave/objeto”. Aquí las búsquedas no se hacen con una consulta SQL, sino que se realiza una consulta sobre un índice que luego es iterado.

Con IndexedDB al igual que en WebSQL, al abrir una base de datos, se debe indicar su nombre y la versión concreta. Posteriormente crear los “almacenes de objetos”, que son muy parecidos a un archivador con índices, lo cual permite encontrar de una manera muy rápida el objeto que es buscado. Una vez que el almacén está listo, se puede almacenar cualquier tipo de objeto con el índice que se defina. No importa los tipos de objetos que se almacenen, ni siquiera tienen que tener las mismas propiedades. Permite un almacenamiento de aproximadamente 50 megabytes. Es compatible con las siguientes plataformas:

• BlackBerry 10 • Windows Phone 8 • Windows 8

Conclusión

Como habíamos comentado inicialmente, se descartó la utilización del plugin “file” rápidamente por las razones enunciadas. El siguiente en ser descartado fue “WebStorage” por resultar una implementación similar a la de IndexedDB pero menos completa.

Entonces la incógnita quedó reducida a dos posibles candidatos: “WebSQL” e “IndexedDB” . Concluimos, finalmente, que utilizaríamos la primera. La razón de la elección de “WebSQL” se puede resumir en los siguientes ítems:

� Está soportada en Android. � Es una base de datos relacional, tecnología que ya conocemos. � Su manipulación es sencilla y natural. � Es compatible también con BB10 e iOS, plataformas a implementar a futuro.



7.3.2 Diseño de la base de datos para DigitalHC

Como anunciamos en las líneas anteriores, utilizaremos una base de datos relacional bajo WebSQL para el desarrollo de la base de datos de la aplicación. A continuación presentamos el resultado del esquema creado mediante la figura 7.1.

Fig. 7.1 – Esquema resultante de la base de datos (historiaBD)

Como se puede observar en la figura 7.1, el esquema de base de datos cuenta con doce tablas, de las cuales hay dos que son las más importantes: “paciente” y “consulta” . Básicamente la tabla “paciente” guarda los datos propios de cada paciente y se relaciona con las tablas: “obra_social”, “estado_civil”, “tipo_documento”, “país”, “patología” (para las patologías crónicas) y “consulta” . Esta última guardará los datos de cada una de las consultas de un paciente al profesional y está relacionada con las tablas “vacunas”, “vademécum” (listado de medicamentos), “practica” (para las prácticas a realizar en el paciente), “especialidad” (en caso de requerir derivación a un especialista), y “patologías” (para las patologías detectadas en la consulta). Finalmente podemos ver una tabla suelta llamada “configuración” , que contiene los datos del profesional que utiliza la aplicación, y un dato muy importante: el servidor con el cual se conectará el dispositivo para poder enviarle al mismo su posición actual.



7.3.3 Diseño de la base de datos del servidor

Como parte de la resolución del problema, también surgió la necesidad de capturar y almacenar datos en un servidor externo. Estos datos responden a las posiciones de los distintos dispositivos donde se usará la aplicación, entre otros.

En este caso y en sintonía con la premisa del uso de herramientas libres, optamos por la implementación de un servidor tipo LAMP (Linux Apache MySQL Php). El esquema de la base de datos es muy sencillo y se muestra en la figura 7.2

Fig. 7.2 – Tabla de la base de datos del servidor

Como se puede observar en la figura 7.2, el esquema consta únicamente de dos tablas. Una llamada “ubicación” , que contiene el nombre del usuario del dispositivo, las especialidades del mismo y la localidad de residencia. Además permite almacenar el identificador único del dispositivo, la posición en función de la longitud, latitud y altitud, además de la fecha y hora de la última actualización de los datos.

La segunda tabla denominada “ubicación_actual”, contiene la posición en la que se encuentra el servidor en función de la longitud y latitud. Estos datos permitirán calcular la distancia entre el punto en el que se encuentra el servidor y el punto en el que el profesional se encuentra usando su dispositivo.

7.3.4 Estructura del código fuente

A esta altura no es ningún secreto el lenguaje en que nuestra aplicación ha sido desarrollada. Estamos hablando en realidad de una tecnología, formada en este caso por los lenguajes web HTML5 , JavaScript y CSS3. No será motivo de estudio de este capítulo ni de esta tesina el código en sí mismo. Más bien nos centraremos en la lógica mediante la cual se estructuró el mismo, teniendo en cuenta su relación con cada módulo de la aplicación.

Para comenzar a desenmarañar un poco el ovillo, comenzaremos por mostrar la estructura base de la aplicación. Recordemos que, como vimos en el capítulo “Presentando Phonegap”,



nuestra carpeta de trabajo es el directorio denominado “www” . En la figura 7.3 se muestra el contenido de la misma, que representa en definitiva, todo el código de nuestra aplicación:

Fig. 7.3 – Estructura de archivos de la aplicación “DigitalHC”

Como se puede observar en la figura 7.3, la carpeta contiene cuatro directorios y luego un fichero de extensión XML junto con un conjunto de archivos HTML. Estos últimos representan lo siguiente:

• index.html: Es el punto de entrada de la aplicación. Se encarga de incluir todas las librerías y recursos que se usarán. Define la estructura base que tendrá toda la aplicación.

• config.xml: Contiene las distintas configuraciones usadas por la aplicación. • ABM_generico.html: Contiene el diseño base de la estructura para la gestión de las tablas:

o obra_social o practica o vacuna o patologia o especialidad o vademecum o tipo_documento o pais o estado_civil

• configuracion.html: Contiene el diseño base de la estructura para la tabla configuracion.

consultas.html: Define el diseño base de la estructura para la gestión de la tabla consultas.



• pacientes.html: Contiene el diseño base de la estructura para la tabla pacientes y su menú asociado.

• presentacion.html: Contiene la estructura de la página de bienvenida mostrada al ingresar a la aplicación.

• reportes.html: Define el diseño de la estructura para el menú Reportes • tablas.html: Contiene la definición de la estructura con el menú que permite seleccionar

entre las diferentes tablas de sistema a gestionar.

Las carpetas “res” e “img” , contienen los íconos usados por la aplicación así como la imagen de bienvenida mostrada al cargarse la aplicación.

El directorio “js” contiene los códigos JavaScript usados por la aplicación. Mostramos el contenido de la misma en la figura 7.4:

Fig. 7.4 – Detalle de la carpeta “js” de la aplicación

Se puede apreciar que esta carpeta contiene los archivos siguientes:

• ABM_generico.js: Contiene la lógica para la gestión (altas, bajas, modificaciones) de las tablas asociadas al archivo “ABM_generico.html” (obra_social, practica, vacuna, patologia, especialidad, vademecum, tipo_documento, pais, estado_civil).

• comun.js: Define algunas variables que son usadas globalmente, así como cierto comportamiento que es común a varios componentes de la aplicación.



• configuracion.js: Implementa la lógica necesaria para la gestión de los datos de la tabla configuración.

• consultas.js: Contiene la lógica necesaria para la gestión de las consultas de cada uno de los pacientes.

• index.js: Se encarga de la inicialización de la aplicación, creando las tablas necesarias, haciendo la precarga de los diferentes componentes y tareas que correrán en segundo plano.

• pacientes.js: Contiene la lógica necesaria para la gestión de cada uno de los pacientes.

• reportes.js: Se encarga de implementar los métodos necesarios para proveer las siguiente funcionalidades:

o Gráfico de Pesos (de un paciente) o Gráfico de Presiones (de un paciente) o Gráfico Frecuencias Cardíacas (de un paciente) o Exportar a PDF (historia clínica de un paciente)

• tablas.js: Gestiona el menú de gestión de tablas de sistema. • utiles.js: Provee funcionalidades diversas que son utilizadas por los distintos

módulos de la aplicación.

Además de los archivos vistos, la capeta “js” , posee también un subdirectorio llamado “lib” que contiene una serie de librerías de código JavaScript de apoyo, utilizadas en la aplicación. No entraremos por el momento en mayores detalles, eso será tratado más adelante. Por lo pronto comentaremos que estos archivos son los siguientes:

• jquery-2.1.0.min.js: Famosa librería JavaScript que facilita mucho la programación en este lenguaje y que además es el cimiento usado por la mayoría de los plugins y complementos existentes, incluidos los que siguen a continuación.

• highcharts.js: Librería para la visualización de gráficos estadísticos. • jquery.bpopup.min.js: Librería que permite mostrar popups configurables. • jQuery.fastClick.js: Pequeña utilidad que permite acelerar el disparo del evento Click. • jquery.touch.min.js: Librería que permite capturar los gestos típicos generados en una

pantalla táctil, por ejemplo: toque, toque prolongado, arrastrar a los lados, etc. • jspdf.min.js: Librería que permite generar archivos del tipo PDF.

Finalmente, el directorio “css”, contiene las hojas de estilo necesarias para definir con qué formato se mostrará la aplicación. Estos códigos definirán por ejemplo, qué colores se usarán, tipos de letra, tamaños y posiciones de los objetos, entre otras cosas. A continuación se muestra la figura 7.5 que detalla el contenido de esta carpeta:



Fig. 7.5 – Detalle de la carpeta CSS de la aplicación DigitalHC

De la imagen se desprenden los siguientes archivos de estilo:

• ABM_generico.css: Se encarga de darle estilo a la estructura definida en el archivo ABM_generico.html.

• configuracion.css: Le da estilo a la estructura definida en el archivo configuracion.html.

• index.css: Se encarga de darle estilo a la estructura definida en el archivo index.html. • presentacion.css: Da estilo a la estructura definida en presentacion.html. • tablas.css: Se encarga de dar estilo a la estructura definida en tabla.html. • comun.css: Define una serie de estilos común a varios módulos de la aplicación. • consultas.css: Da estilo a la estructura definida en consultas.html. • pacientes.css: Se encarga de darle estilo a la estructura definida en el archivo

pacientes.html. • reportes.css: Da estilo a la estructura definida en reportes.html. • topcoat-mobile-light.min.css: Se trata de una hoja de estilos optimizada para

acelerar y mejorar la vista en dispositivos móviles. (Será tratada en un capítulo posterior).



7.4 Explorando la aplicación

En esta sección exploraremos el resultado de la aplicación entrar demasiado en detalle en cuestiones técnicas referidas al código en mostrar qué aspecto tiene la misma y cómo fueron abordadas las diferentes funcionalidades.

Las capturas que se mostrarán, han sido obtenidas utilizandoAndroid para que la aplicación se vea los más parecido posible a como se vería en un dispositivo real.

7.4.1 Vista del emulador

En la siguiente imagen completa que ofrece el emulador de corresponde a la pantalla del dispositivo virtual, donde se observan varios nuestra aplicación (ref. “F” ). En la parte derecha se encuentra el tablero de controles que permite emular el comportamiento de los botones clásicos de los dispositivos que poseen mismos son: A) bajar y subir volumen, B) apagar dispositivo, C) ir al inicio, D) mostrar mencontextual, E) regresar a la pantalla anterior/salir.

Fig. 7.6


Chavez Alexis David

7.4 Explorando la aplicación

En esta sección exploraremos el resultado de la aplicación “DigitalHC” entrar demasiado en detalle en cuestiones técnicas referidas al código en mostrar qué aspecto tiene la misma y cómo fueron abordadas las diferentes funcionalidades.

Las capturas que se mostrarán, han sido obtenidas utilizando una máquina virtual de Android para que la aplicación se vea los más parecido posible a como se vería en un dispositivo

utilizado

correspondiente a la figura 7.6, podremos apreciar la ventana completa que ofrece el emulador de Android. Podemos divisar en la parte de la izquierda lo que corresponde a la pantalla del dispositivo virtual, donde se observan varios íconos entre los que está

. En la parte derecha se encuentra el tablero de controles que permite emular el comportamiento de los botones clásicos de los dispositivos que poseen mismos son: A) bajar y subir volumen, B) apagar dispositivo, C) ir al inicio, D) mostrar mencontextual, E) regresar a la pantalla anterior/salir.

Fig. 7.6 – Vista completa del emulador


Pág. 165

“DigitalHC” desarrollada, sin entrar demasiado en detalle en cuestiones técnicas referidas al código en sí mismo. La idea es mostrar qué aspecto tiene la misma y cómo fueron abordadas las diferentes funcionalidades.

una máquina virtual de Android para que la aplicación se vea los más parecido posible a como se vería en un dispositivo

podremos apreciar la ventana . Podemos divisar en la parte de la izquierda lo que

conos entre los que está . En la parte derecha se encuentra el tablero de controles que permite

emular el comportamiento de los botones clásicos de los dispositivos que poseen Android. Los mismos son: A) bajar y subir volumen, B) apagar dispositivo, C) ir al inicio, D) mostrar menú



7.4.2 Pantalla de bienvenida (splashscreen)

Al presionar en el ícono de la aplicación, la misma comenzará a cargarse y se mostrará durante cinco segundos una pantalla de bienvenida como la de la figura 7.7:

Fig. 7.7 – Pantalla de bienvenida

7.4.1 Pantalla de presentación

Una vez que la aplicación ha sido cargada, se mostrará una pantalla como la de la figura 7.8. En la misma se observa una cabecera fija con las tres opciones básicas: “Tablas” , “Pacientes” y “Reportes”. En el cuerpo se aprecia un mensaje de bienvenida el cual, sólo es mostrado al entrar en la aplicación. Finalmente en el pie, una pequeña barra de navegación que indica en qué punto de la aplicación estamos (“Presentación” en este caso).

Fig. 7.8 – Pantalla de presentación



7.4.2 Menú Pacientes

Al ingresar por primera vez al menú de pacientes encontraremos una pantalla similar a la que se mostrará luego. En la sección B) se encuentra el botón que permite cargar un nuevo paciente. El sector C) muestra la lista de pacientes actual, que en este caso está vacía. Mediante el buscador de la sección A) se puede reducir la lista mostrada a los pacientes cuyo DNI o apellido o nombre coincida con el criterio ingresado aquí.

Fig. 7.9 – Detalle menú “pacientes”

7.4.3 Nuevo paciente

A continuación se muestra el formulario completo de ingreso de un paciente, estratificado en cuatro imágenes. Notar que los botones quedan fijos y la cabecera principal ha desaparecido.

Fig. 7.10 – Formulario “Nuevo paciente” (1/4) Fig. 7.11 – Formulario “Nuevo paciente” (2/4)



Fig. 7.12 – Formulario “Nuevo paciente” (3/4) Fig. 7.13 – Formulario “Nuevo paciente” (4/4)

Como se puede observar gran parte de los componentes mostrados son cajas de texto, objetos HTML de tipo input que según el atributo type utilizado, varían automáticamente su comportamiento. Ilustraremos esto a continuación.

Input tipo “text” y “email”

A continuación en la figura 7.14 se muestra el comportamiento del teclado del dispositivo de acuerdo con el tipo (type) de input definido. En el primer caso (campo Nombre) el tipo es “text” y se muestran los caracteres básicos que uno puede llegar a necesitar en un texto ordinario. En la segunda imagen se puede ver cómo se ha agregado (para el campo Email) el símbolo “@”, dado que el tipo ha sido definido como “email” .

Fig. 7.14 – Inputs tipo “text” y tipo “email” (de izquierda a derecha)



Input tipo “number” y “tel”

En la figura 7.15 se puede observar a la izquierda, como el teclado se actualiza para valores numéricos puros (Campo “Peso (kgs.)”) de acuerdo al input tipo “number” . A la derecha se puede ver como se agregan botones que tienen que ver con números de teléfono (campo “Teléfono”) siendo el input tipo “tel” .

Fig. 7.15 – Inputs tipo “number” y tipo “tel”

Combos (select) nativos

El formulario “Nuevo Paciente” mostrado anteriormente cuenta con varios objetos conocidos en la jerga web como “combos”. Son en realidad objetos HTML denominados “select”. Los mismos contienen una lista de opciones de las cuales una sola puede ser seleccionada en un momento dado. PhoneGap le da a estos “combos” un formato nativo y en consecuencia, se visualizan como en la figura 7.16, por ejemplo para el tipo de documento:

Fig. 7.16 – Detalle del combo “Tipo Documento”



Listas (select tipo multiple) nativas

Además de combos, el formulario cuenta con una lista. Las listas tienen la misma naturaleza que los primeros, es decir son objetos HTML de tipo “select”, sólo que además, poseen un atributo configurado de la siguiente manera: multiple=‘multiple’ . De este modo se obtiene un objeto que PhoneGap muestra como una lista nativa, y que permite seleccionar múltiples valores. A continuación veremos la figura 7.17 que ilustra lo comentado:

Fig. 7.17 – Detalle de lista múltiple para el campo “Patologías crónicas”

En la figura de la izquierda tenemos la lista, que en el ejemplo consta de dos ítems (patologías) según la sección A) de la imagen. En la sección B) podemos observar un botón con un lápiz el cual, al ser presionado, despliega la lista de patologías mostrada en la segunda imagen sobre la margen derecha.

Mensajes de error y éxito

Para concluir con este formulario, mostramos los mensajes desplegados al intentar guardar los datos del paciente, en caso de éxito (izquierda) o error (derecha).

Fig. 7.18 – Mensajes mostrados en caso de éxito o de error (de izquierda a derecha)

En ambos casos, los mensajes son mostrados por un periodo de tiempo de tres segundos. Transcurrido el tiempo desaparecen de la pantalla y el formulario se desplaza hacia arriba nuevamente, ocupando el lugar vacío dejado por el anuncio.



7.4.4 Listado de paciente

Una vez que contamos con algunos pacientes en nuestra base de datos, el listado se verá de manera similar al de la figura 7.19:

Fig. 7.19 – Listado de pacientes

Se puede observar en la figura 7.19, un listado de cuatro pacientes. Cada uno de los renglones del mismo muestra: apellido, nombre, tipo y número de documento, y un pequeño recuadro disponible para cargar una imagen desde la cámara fotográfica del dispositivo.

7.4.5 Tomar la foto de un paciente

Una de los requisitos propuestos, además de poder resguardar los datos de cada uno de los pacientes, es permitir la captura de una foto que los identifique. Haciendo uso del plugin “camera” provisto por PhoneGap, esto pudo ser posible. En la figura 7.20 se muestra el detalle de un renglón de la lista de pacientes. En la misma está resaltado el sector A), el cual, al ser presionado permite la captura de una imagen con la cámara del dispositivo que es asociada automáticamente con ese paciente:

Fig. 7.20 – Detalle de un renglón del listado de pacientes



7.4.6 Ver los datos de un paciente

Al tocar uno de los renglones vistos en la imagen anterior podemos ver los datos del paciente correspondiente, igual que la figura 7.21:

Fig. 7.21 – Vista de “Detalle Paciente” en dos capturas

Como peculiaridades del reporte anterior, podemos comentar: una funcionalidad que calcula la edad del paciente según su fecha de nacimiento y otra que muestra el IMC (índice de masa corporal) asignando además, una valoración entre alguno de los siguientes rangos:

• 'Delgadez severa' (IMC menor a 16)

• 'Delgadez moderada' (IMC entre16 y 17) • 'Delgadez aceptable' (IMC entre 17 y 18,5) • 'Normal' (IMC entre 18,5 y 25)

• 'Pre obeso' (IMC entre 25 y 30) • 'Obeso tipo I' (IMC entre 30 y 35)

• 'Obeso tipo II' (IMC entre 35 y 40) • 'Obeso tipo III' (IMC mayor a 40)

Otro punto a destacar son los botones presentados y que se explican a continuación:

Fig. 7.22 – Detalle de los botones en “Detalle Paciente”



De la figura 7.22 se puede observar: el botón A) que envía un mail a la dirección asociada, B) permite llamar al paciente y C) que sirve para enviar un mensaje al paciente usando la aplicación por default a tal efecto.

7.4.7 Buscar un paciente

Como vimos en la sección “Menú Pacientes”, existe una caja de texto que permite filtrar los pacientes listados. Este filtro puede ser tanto numérico como alfabético. En caso de ingresar números, filtrará por número de documento. De otro modo el filtro se aplicará para nombre y apellido. A continuación se muestra la figura 7.23 para comprender mejor su funcionamiento:

Fig. 7.23 – Filtros por número de documento y por nombre/apellido (de izquierda a derecha)

7.4.8 Menú para la gestión del paciente

Para editar o eliminar los datos de un paciente o bien, ver sus consultas, existe un menú oculto. Consiste en un popup que se despliega al mantener presionado el dedo encima de alguno de los renglones listados, tal como se muestra en la figura 7.24:

Fig. 7.24 – Detalle del Popup con opciones para el pacente



Eliminar un paciente

Si se desea borrar los datos de un paciente, se debe seleccionar la opción “eliminar” y se pedirá entonces, la confirmación para realizar esta operación, igual que en la figura 7.25:

Fig. 7.25 – Mensaje mostrado al intentar borrar un paciente

Editar un paciente

Si se escoge la opción “editar” , entonces se mostrará un formulario igual al visto en la sección “Nuevo paciente” sólo que con los datos del paciente a modificar, tal como en la figura 7.26:

Fig. 7.26 – Formulario de edición de un paciente



7.4.9 Gestión de consultas

Existe una tercera opción llamada “Ver Consultas”, dentro del submenú oculto de pacientes, que permite ver y gestionar las consultas de cada paciente. Cuando aún no se ha ingresado ninguna consulta, la vista es similar a la figura 7.27:

Fig. 7.27 – “Listado de Consultas” sin registros ingresados

Nueva consulta

El formulario desplegado al presionar “Nueva” en “Listado de Consultas”, es similar al de “Nuevo Paciente”. Mostramos dicho formulario en las siguientes imágenes:

Fig. 7.28 – Formulario “Nueva Consulta” (1/6) Fig. 7.29 – Formulario “Nueva Consulta” (2/6)





Como se puede apreciar en las capturas, el formulario para una nueva consulta es más extenso que el usado para la captura de los datos de un nuevo paciente. No obstante podemos observar que se utilizan los mismos objetos en ambos casos

Menú oculto para la gestión de consultas

Así como para el listado de pacientes se cuenta con un submenú para la manipulación de los mismos, también existe un submenú para las consultas. Su funcionamiento es igual, sólo se debe



mantener presionado el renglón (consulta) que se desea modificar, entonces se desplegarán las opciones, tal y como se muestran en la figura 7.34:

Fig. 7.34 – “Listado de Consultas” con registros ingresados y Popup con opciones para las consultas

Como se puede apreciar en la imagen de la derecha, las opciones con las que se cuentan son de edición y eliminación de una consulta. Estas funciones son análogas a las vistas para el caso de los datos de los pacientes.

7.4.10 Menú Reportes

Hasta el momento hemos explorado sólo la parte de gestión y manejo de los pacientes y sus consultas. Es momento de poder hacer algo con esos datos, y a tal efecto se desarrolló este punto del menú. A continuación mostramos la pantalla inicial visualizada al ingresar a “Reportes”:

Fig. 7.35 – Deralle del menú “Reportes”



Selección del paciente

Para generar un tipo de gráfico o reporte, se debe seleccionar con qué paciente se desea trabajar. Eso se hace mediante el campo “Paciente a reportar”. Al presionar el combo asociado, se desplegará la lista de todos los pacientes en la base de datos, igual que en la figura 7.36:

Fig. 7.36 – Selección del paciente con el cual trabajar

7.4.11 Generación de gráficos estadísticos

Mediante los primeros tres botones, denominados: “Gráfico de Pesos”, “Gráfico de Presiones” y “Gráfico F. Cardíacas”, se puede acceder a los gráficos estadísticos de los pesos, presiones arteriales y frecuencias cardíacas respectivamente. Estos Gráficos son construidos a partir de los datos recopilados de las distintas consultas del paciente seleccionado. A continuación mostramos las tres gráficas ofrecidas por la aplicación mediante la figura 7.37:

Fig. 7.37 – Gráficos estadísticos referidos a pesos, presiones arteriales y frecuencia cardíaca de los pacientes



7.4.12 Exportar a PDF

La última de las opciones provistas por esta sección es: “Exportar a Pdf” . Al presionar este botón, se generará automáticamente la historia clínica del paciente (basado en las consultas) en formato PDF. Además se mostrará un mensaje indicando cómo y dónde se ha guardado la misma, tal como se muestra en la figura 7.38:

Fig. 7.38 – Mensaje desplegado al exportar a PDF

El reporte generado tendrá un aspecto similar al de las imágenes que veremos a continuación, en este caso se trata de un paciente con tres consultas:

Fig. 7.39 – Reporte PDF (1/4) Fig. 7.40 – Reporte PDF (2/4)



Fig. 7.41 – Reporte PDF (3/4) Fig. 7.42 – Reporte PDF (4/4)

Este reporte se genera a partir de los datos del paciente y de todas sus consultas. Se logró la generación en formato PDF gracias a la librería “JSPDF” , la cual estudiaremos en un capítulo posterior a este. El diseño de esta historia clínica básicamente cuenta con una carátula (primer hoja) que muestra los datos del paciente en cuestión y, posteriormente, el resultado de cada una de las distintas consultas del paciente.

7.4.13 Menú Tablas

Este punto del menú fue pensado para poder editar, lo que nosotros llamamos, “tablas de sistema”. Con este concepto nos referimos a todos aquellos datos que sirven de apoyo a la aplicación. Es decir, no forman parte de los datos propios del paciente y sus consultas, pero son necesarios para enriquecer los anteriores. A continuación se muestran los botones disponibles, que permiten interactuar con cada una de las tablas (figura 7.43).

Fig. 7.43 – Detalle del menú “Tablas”



Editar Configuración

Esta opción se accede mediante el botón “Configuración” y está relacionada con los datos propios del profesional que usa la aplicación. Estos datos son utilizados para el rastreo del mismo y están relacionados con el módulo web desarrollado en PHP. A continuación mostramos el formulario para editar estos datos, mediante la figura 7.44:

Fig. 7.44 – Formulario “Edición de Configuración”

Los primeros campos representan datos personales del profesional, pero el último, etiquetado como “Servidor” , es el que le permite a la aplicación conectarse con el servidor PHP y de esa manera, revelar la ubicación en la que el profesional se encuentra.

Editar otras tablas

Además de la tabla configuración, también podemos editar las siguientes tablas:

• obra_social • practica

• vacuna • patologia

• especialidad • vademecum • tipo_documento

• pais • estado_civil

A continuación, a modo de ejemplo seleccionaremos el botón “Obras Sociales” (figura 7.45, parte izquierda) y esto desplegará la lista de obras sociales (figura 7.45, parte derecha). Este listado se comporta de la misma manera que los vistos hasta el momento. Posee una caja de texto para filtrar por nombre de obra social y también se podrán editar o eliminar los registros.



Fig. 7.45 – Ingresando a la opción “Obras Sociales”

A continuación veremos el detalle del popup (figura 7.46, parte izquierda) y el efecto provocado al seleccionar la opción “Editar” (figura 7.46, parte derecha).

Fig. 7.46 – Editando una obra social

Nota: esta forma de proceder es aplicable a todo el resto de las tablas de sistema, por los que es redundante explicar y/o mostrar el comportamiento de cada una ellas.



7.4.14 Salir del Sistema

Como se puede observar en todas la imágenes mostradas hasta el momento, no existe un botón salir o cerrar en ninguno de los módulos de la aplicación. Esto no es una mera casualidad, dado que tal funcionalidad se le asigno al botón “Regresar/Salir” o “Back Button” (en inglés), que todo dispositivo Android posee. En el caso del emulador, este botón se presenta con la siguiente forma (figura 7.47):

Fig. 7.47 – Detalle botón atrás del emulador

Al presionar el mismo, se pedirá la confirmación al usuario para salir definitivamente de la aplicación y realizar las tareas de cierre. En la figura 7.48 se muestra cómo se ve la pantalla y el cuadro de diálogo de salida.

Fig. 7.48 – Cuadro de diálogo mostrado al intentar salir de la aplicación



7.5 Explorando el servidor web

Como se había planteado en la sección “ Problema propuesto” , al comienzo del capítulo, uno de los requisitos a implementar era el rastreo de los diferentes profesionales, la distancia a la que se encontraban del edificio de trabajo para ser más específicos. A tal fin se implementó un servidor tipo LAMP. El mismo está basado en Linux y permite combinar las herramientas Apache, PHP y MySQL. Una vez configurado este servidor, se generó una aplicación que posee básicamente tres módulos:

• eliminar.php

• coordenadas.php • index.php

El módulo “eliminar.php” se encarga de eliminar los profesionales de la base de datos según la elección del usuario. El código en “coordenadas.php” es el encargado de registrar los datos de los profesionales en la base de datos (entre ellos por supuesto la posición del mismo). Finalmente el módulo “index.php” se encarga de mostrar el listado de profesionales, sus datos y la distancia a la que se encuentran. Esto último lo logra mediante un algoritmo usando la latitud y longitud recibida y asentada en la base de datos por el módulo coordenadas.php. A continuación mostramos el algoritmo usado y codificado en PHP por supuesto:

function getDistance($lat1, $long1, $lat2, $long2) { $earth = 6371; //Radio medio de la tierra en kilómetros //Coordenadas del punto 1 $lat1 = deg2rad((double)$lat1); $long1= deg2rad((double)$long1); // Coordenadas del punto 2 $lat2 = deg2rad($lat2); $long2= deg2rad($long2); // Fórmula del Haversine $dlong = $long2 - $long1; $dlat = $lat2 - $lat1; $sinlat = sin($dlat/2); $sinlong = sin($dlong/2); $a = ($sinlat * $sinlat) + cos($lat1) * cos($lat2) * ($sinlong * $sinlong); $c = 2 * asin(min(1,sqrt($a))); $distancia = round($earth * $c, 2); return $distancia; }



7.5.1 Ingreso a la aplicación web

Para ingresar a la aplicación, se requiere simplemente de un navegador web (o browser). A continuación mostramos el detalle de la barra de direcciones donde se observa cómo realizamos el ingreso a nuestro servidor de prueba (figura 7.49).

Fig. 7.49 – Detalle de la URL de ingreso a la página principal

Es el módulo “index.php” quien se encarga de mostrar la página principal junto con la información de la base de datos. El aspecto que tiene la misma es igual al de la figura 7.50:

Fig. 7.50 – Vista de la página principal

7.5.2 Coordenadas del servidor

Las coordenadas del servidor, las cuales deberían ser las mismas que las de la institución donde los profesionales trabajan, se deben setear desde el siguiente cuadro (figura 7.51):



Fig. 7.51 – Cuadro de configuración de coordenadas del servidor

En la imagen anterior podemos ver que hay dos campos editables con las etiquetas “Latitud” y “Longitud” . Las mismas representarán, como comentábamos más arriba, la posición en la cual se encuentra el servidor. Esta dos magnitudes son la base para el cálculo de la distancia a los diferentes profesionales. Con motivo de testear la aplicación, debajo de los campos antes nombrados, se encuentra un “combo” que al ser desplegado, permite obtener ubicaciones preestablecidas de algunas de las ciudades más importantes de la zona (y la ciudad autónoma de Buenos Aires). Mostramos el listado de las mismas en la figura 7.52:

Fig. 7.52 – Combo con ubicaciones preestablecidas

7.5.3 Listado de dispositivos localizados

Podemos ver en la parte inferior de la página principal una tabla con el título “Listado de dispositivos registrados”. La misma muestra los distintos dispositivos, de cada uno de los profesionales, que han logrado conectar con el servidor y enviar los correspondientes datos (figura 7.53):

Fig. 7.53 – Detalle de los dispositivos registrados



Básicamente los datos mostrados se refieren a lo siguiente:

• Profesional: nombre del profesional que usa ese dispositivo. • Especialidades: qué especialidades tiene ese profesional.

• Localidad: de dónde es oriundo el profesional. • Última actualización: fecha y hora de la última vez que se actualiza el estado. • Distancia: espacio en kilómetros desde el servidor a la ubicación del profesional.

• X: la equis en rojo permite eliminar el registro asociado.

7.5.4 Ver el identificador del dispositivo

Existe la posibilidad de ver el identificador del dispositivo usado por el profesional. Esto se logra simplemente llevando el mouse sobre el nombre del profesional. Mostramos un ejemplo a continuación en la figura 7.54:

Fig. 7.54 – Detalle del identificador único del dispositivo de un profesional

7.5.5 Ver las coordenadas del dispositivo

Muy probablemente en la vida real, esta opción no sería moralmente correcta y no debería estar disponible. Pero con fines de testeo es que habilitamos la posibilidad de ver tanto, la longitud como la latitud del profesional, simplemente posando el mouse sobre el campo correspondiente a la distancia. Ilustramos esta funcionalidad en la figura 7.55:

Fig. 7.55 – Detalle de las coordenadas en las que se encuentra un profesional

Nota: estas coordenadas pueden ser ingresadas por ejemplo en Google Maps y de esa manera obtener la dirección precisa en la cual el usuario del dispositivo se encuentra.



8. HERRAMIENTAS UTILIZADAS

8.1 Introducción

Este capítulo está dedicado a las distintas herramientas de programación que fueron utilizadas para desarrollar la aplicación “DigitalHC” . Nos referimos a todas aquellas librerías, tanto de JavaScript, como CSS, las cuales de algún modo, simplificaron la tarea de desarrollo, al mismo tiempo que permitieron sacarle mejor provecho a PhoneGap.

Algunas de las herramientas que presentaremos como: “XUI” o “jQuery Mobile” , fueron descartadas. Este hecho se debió a que luego de probar su utilización, se decidió optar por otras posibilidades que nos parecieron más óptimas y convenientes. No obstante, nos parece que no podemos dejar de nombrarlas, ya que forman parte de nuestra experiencia personal y consideramos que al lector podría interesarle nuestra humilde opinión.

Sin más preámbulos daremos comienzo al capítulo, empezando con las dos herramientas descartadas y, posteriormente, continuaremos con las que finalmente decidimos utilizar en el desarrollo de nuestra aplicación.



8.2 jQuery Mobile

Esta herramienta ya fue expuesta en el capítulo “Explorando el estado del arte” por lo que no se entrará en mayores detalles sobre la misma. A modo de resumen podemos decir que “jQuery Mobile” : es un framework JavaScript, basado en “jQuery” , que permite incrementar la velocidad de desarrollo agregando una capa más al jQuery tradicional. Mediante su utilización se logra encapsular muchas tareas comunes, tanto en el desarrollo de la interfaz, como en el tratamiento de los eventos, entre ellos los táctiles.

Nuestra experiencia

Al comienzo del desarrollo de nuestra aplicación, donde aún se tenía más incertidumbre que certezas, y PhoneGap era una herramienta totalmente nueva y desconocida, se comenzó a utilizar jQuery Mobile (JQM). La decisión se debió al gran uso que hacia una buena parte de la comunidad desarrolladora en ese momento y que por ende, la mayoría de los ejemplos encontrados en la Web también utilizaban JQM.

Durante las primeras pruebas todo iba bien. La aplicación se testeaba únicamente desde el navegador web, el comportamiento y la estética de los pequeños prototipos eran muy satisfactorios. El problema surgió al empezar a probar la aplicación tanto en un dispositivo real, como en uno virtual, donde pudimos ver como el rendimiento se veía seriamente afectado en esos ámbitos. Básicamente se podía observar cómo los cambios de pantalla eran lentos, los botones respondían erráticamente en ocasiones, los tiempos de respuesta demasiado largos y esto hacia la usabilidad de la aplicación, muy poco natural y tediosa.

Aún con lo expuesto anteriormente, cabe destacar que JQM provee muchas características interesantes y que facilitan en gran medida el desarrollo de una aplicación para dispositivos móviles. Es por eso que se intentó mejorar la performance recurriendo a diversas opciones, reduciendo efectos, probando diferentes versiones del framework, alterando estilos, etc. Los esfuerzos fueron estériles y al cabo de un mes de pruebas, se decidió abandonar esta herramienta. Por supuesto no concluimos que JQM sea una mala opción a la hora de plantear un nuevo desarrollo. Sí sostenemos que requiere de dispositivos con un hardware bastante elevado para funcionar correctamente y preferimos utilizar herramientas que no comprometan tanto el rendimiento de nuestra aplicación en dispositivos de gama baja.



8.3 XUI

Es una librería JavaScript preparada para trabajar en navegadores como: Chrome, Firefox, Opera, IE Mobile y BlackBerry. Apareció prácticamente a la par de PhoneGap y a diferencia de frameworks como jQuery Mobile, no intenta imponer un estilo propio de diseño, pero sí permite interactuar con los elementos de HTML, como jQuery.

Probablemente el rasgo o característica más evidente de XUI, es su “pequeño” tamaño. La versión comprimida oscila entre los 7.8 Kb y los 24.3 Kb, según la versión. Esto es algo a destacar cuando de aplicaciones para dispositivos móviles se trata, dado que, cuanto menos “pesen” las librerías utilizadas, menos sobrecargas sufrirán dichas aplicaciones.

Otra característica muy interesante de XUI es el soporte para gestos y eventos. Algunos de los más importantes son:

• click: toque rápido o mediante mouse. • load: al cargarse el objeto. • touchstart: al iniciarse un toque. • touchmove: al mover el dedo sobre la pantalla. • touchend: al finalizar toque. • orientationchange: al cambiar la orientación.

Nuestra experiencia

No es demasiado lo que podemos decir sobre esta librería más allá de lo que se comentó anteriormente. La estudiamos brevemente y encontramos que hacía básicamente lo mismo que jQuery, herramienta que ya conocemos, con la desventaja que debíamos aprender una nueva sintaxis y forma de trabajar. Algunas de las facilidades que jQuery brinda, XUI no las posee. Y uno de los factores determinantes que nos hizo desechar esta opción, es el hecho de que, la inmensa mayoría de los plugins JavaScript que se pueden agregar a una aplicación, están sustentados o se basan en el uso subyacente de jQuery. Estas son las razones que nos motivaron a utilizar esta última librería y no XUI.



8.4 jQuery

Sin lugar a dudas, es la librería JavaScript por excelencia. Gratuita, open source y que simplifica aspectos como: la programación de rutinas, manipulación del DOM (Document Object Model) y la interacción con los elementos HTML de una página web. Funciona en todos los navegadores web modernos y abstrae características específicas de cada uno de estos, permitiendo de este modo, enfocarse en el diseño y resultado final, en lugar de tratar de desarrollar funciones complejas para que funcionen en todos ellos. Es también utilizado para animaciones y solicitudes asíncronas mediante AJAX.

Una de las grandes ventajas de utilizar esta librería radica en el hecho de que hay una gran comunidad desarrolladora que la utiliza. Esto trae aparejado consigo, varios aspectos positivos como ser: gran volumen de documentación y códigos de ejemplo, innumerable cantidad de plugins que usan como base jQuery y que resuelven muchos problemas recurrentes, por nombrar algunos. Para el desarrollo de nuestra aplicación, se utilizó la versión 2.1.0.

Nuestra experiencia

Por todo lo expuesto en los párrafos anteriores, es que decidimos utilizar esta librería JavaScript. Podemos decir sin lugar a dudas que ha satisfecho nuestras necesidades y expectativas y, por ende, la recomendamos ampliamente



8.5 jQuery Touch

Una de las características que jQuery no provee, es el manejo de eventos generados por gestos táctiles. Para subsanar esta falencia decidimos utilizar esta herramienta llamada jQuery Touch. La misma requiere del uso subyacente de jQuery y mediante una sintaxis muy práctica y sencilla, habilita la captura de los gestos básicos. Para poder asociar eventos táctiles a los objetos de nuestra interfaz, se procede como se muestra a continuación con el objeto cuyo id es “mi_boton” :

$('mi_boton').enableTouch(); //Se habilita el uso de gestos táctiles para el objeto 'mi_boton'

También se pueden habilitar ciertas opciones invocando la llamada con los argumentos correspondientes, por ejemplo de la siguiente manera:

//El evento tapAndHoldDelay se disparará luego de 750 milisegundos $('mi_boton').enableTouch({tapAndHoldDelay: 750});

Algunos de los eventos más importantes que permite capturar esta librería, son los siguientes:

• swipeLeft/swipeRight: desplazamiento a la izquierda y a la derecha respectivamente.

$('mi_boton'). on ('swipeLeft', function(){ //acción al tocar y desplazar con el dedo hacia la izquierda }); $('mi_boton'). on ('swipeRight', function(){ //acción al tocar y desplazar con el dedo hacia la derecha });

• tap: Este evento es similar al evento “click” de jQuery, ocurre cuando el objeto es tocado con el dedo.

$('mi_boton'). on ('tap', function(){ //acción al tocar con el dedo });

• tapAndHold: Este evento se dispara al tocar y mantener presionado durante unos instantes el objeto que captura dicho evento.

$('mi_boton'). on ('tapAndHold', function(){ //acción al tocar con el dedo y mantener presionado });



Nuestra experiencia

Muy fácil de configurar y utilizar. Resuelve de manera muy sencilla un problema bastante importante, dado que la captura de gestos táctiles es el “abc” del desarrollo de aplicaciones para dispositivos móviles. Además de las virtudes nombradas, tiene un tamaño muy reducido, tan sólo 4.8 Kb. Por todo lo comentado y por haber sido un gran colaborador en el desarrollo de nuestra aplicación, lo recomendamos ampliamente.



8.6 jQuery bPopup

“bPopup” es un plugin JavaScript utilizado para crear ventanas tipo modal. Estas ventanas tienen la propiedad de que aparecen por encima de todas las demás y mantienen el foco hasta que son cerradas. Esta herramienta no se encarga de darle estilo a las ventanas, sino de proporcionar toda la lógica necesaria para que el popup se visualice y comporte correctamente. Así como el plugin anterior, requiere la inclusión de la librería jQuery.

El uso de este plugin es sumamente sencillo. Supongamos que la ventana a mostrar es un objeto cuyo id es “mi_ventana”. Lo primero que debemos hacer es: definir en el código CSS asociado, la regla que hará que nuestra ventana inicialmente esté oculta:

#mi_ventana { display: none; }

Para poder hacer aparecer nuestro popup simplemente se debe invocar desde el código JavaScript, el método “bPopup( )” y automáticamente la ventana se desplegará:

$('#mi_ventana').bPopup();

Un ejemplo del uso de este plugin en la aplicación “DigitalHC” puede verse en la figura 8.1, donde mostramos un pequeño menú para la gestión de tablas:

Fig. 8.1 – Ejemplo de Popup

Una vez que la ventana ya no requiere seguir siendo mostrada, con el método “close()” se realiza el cierre de la misma:

$('#mi_ventana'). bPopup().close();

Nuestra experiencia

Así como la herramienta anterior, “bPopup” resultó muy confiable y fácil de usar. Le dimos una utilización muy sencilla, pero sabemos por la documentación, que esta herramienta provee otras funcionalidades que seguramente, serán motivo de estudio en futuras incursiones.



8.7 Fastclick

Al momento de realizar una aplicación para dispositivos móviles, hay una cuestión a tener en cuenta, la cual es casi imperceptible, pero está presente en prácticamente todos los dispositivos móviles. El problema radica en una demora de aproximadamente 300 milisegundos que se produce, entre la acción física de tocar un enlace o botón, y el lanzamiento del evento “click” , que es el que se encarga de realizar la tarea asociada al elemento.

En realidad cuando un botón o enlace es presionado, se disparan varios eventos además de “click” . En la figura 8.2 se clarifica lo comentado:

Fig. 8.2 – Eventos disparados al presionar un enlace o botón

Como se manifiesta en la imagen anterior, existen dos eventos iníciales que tienen que ver con: el instante en que se presiona el botón (“touchstart” ) y el momento en que se deja de hacerlo (“touchend”). El lapso de 300 milisegundos, entre los eventos “touchend” y “click” , está pensado para dar soporte al evento “doubletaps” (doble toque). Es decir que se realiza una espera ocupada durante ese tiempo, a la expectativa de recibir otro toque y saber si se trata de un “doubletaps” o no.

El evento “double tap” (o doble toque), se suele usar en los dispositivos móviles para hacer zoom sobre algún elemento de una página web. Queda en cada programador decidir si requiere soportar esta característica, o si puede prescindir de la misma a cambio de tener mayor velocidad de respuesta en la aplicación.

Luego de la explicación anterior sólo cabe una pregunta: ¿Cómo se eliminan los 300 milisegundos para poder aprovecharlos y ganar en velocidad de respuesta?

La respuesta se llama “Fastclick”. Esta solución consiste en un pequeño plugin JavaScript (y que requiere de jQuery para ejecutarse). Básicamente funciona de la siguiente manera:

• Se asocia la función “fastClick” a cualquier elemento HTML.

• Fastclick atrapa el evento “touchend” e inmediatamente, dispara un evento “click” sobre el mismo elemento para ejecutar cualquier acción asociada.

• Finalmente anula el evento “click” disparado por el navegador 300ms después, para no duplicar el evento.



Para que “Fastclick” trabaje, simplemente se debe agregar el siguiente fragmento de código JavaScript a nuestro proyecto.

window.addEventListener('load', function() {

FastClick.attach(document.body);

}, false);

Nuestra experiencia

La implantación de este plugin resulta realmente fácil y se puede notar cómo se reducen los tiempos de respuesta, sobre todo en los dispositivos de gama baja, donde la performance general es reducida. Es recomendable su uso y con más razón, si se desea desarrollar aplicaciones que funcionen lo más rápido posible, aún cuando los recursos de hardware no acompañan demasiado.



8.8 Topcoat

Es una hoja de estilos CSS desarrollada para obtener “aplicaciones web limpias y rápidas”, según enuncian en la página web oficial sus propios creadores. Por este motivo “Topcoat” se construye pensando en la velocidad y para la creación de aplicaciones sensibles con los estándares web, sin depender de JavaScript para dar animaciones al contenido. Los elementos que utiliza son limpios, y diseñados para la “Responsive Web” (Web adaptativa) como premisa.

“Topcoat” surge a partir del trabajo de feedback por parte de la comunidad de desarrolladores de PhoneGap. De este modo la empresa “Adobe”, lo construye teniendo en mente dos aspectos que ya mencionamos, diseño adaptable y velocidad. Inicialmente se basó en dos herramientas propias de Adobe: “Brackets” y “EdgeReflow”, y a partir de ese momento, ha evolucionado a lo que hoy es. Se ofrece en dos versiones: de escritorio y para dispositivos móviles. Es de una utilización muy sencilla, basta con incluir el archivo CSS, utilizar su estructura HTML y personalizarlo como se desee.

“Topcoat” incluye:

• Resultados CSS personalizables.

• Guías de estilo generadas automáticamente.

• Artefactos de diseño PSD (formato de archivo nativo de Photoshop) y otros.

• Una colección de íconos SVG simples y limpios.

• La fuente de la familia tipográfica Adobe Source Sans Pro (nueva tipografía de código abierto de Adobe).

Nuestra experiencia

Una de las razones que ayudó a tomar la decisión de no utilizar jQuery Mobile, se debió al descubrimiento de esta herramienta. Ya en las primeras pruebas realizadas con esta hoja de estilos, nos sorprendió cómo implementaba los diversos componentes, tales como: botones, listas, barras, checkbox (cuadros de comprobación), entre otros. Además de que su apariencia era agradable, no se veía reducida la performance de la aplicación, entonces decidimos que sería beneficioso utilizarla en nuestro proyecto.

Concluida la aplicación seguimos pensando que esta es una gran herramienta para el desarrollo de aplicaciones web, tanto para dispositivos móviles, como para computadoras de escritorio. No obstante siempre existe la opción de la creación de una hoja de estilos propia, esto dependerá del nivel de experiencia que cada programador tenga en la materia.



8.9 HighCharts

Es una librería escrita en JavaScript, que corre sobre jQuery. Capaz de crear gráficos estadísticos interactivos configurables, de varios tipos y estilos, como por ejemplo: lineales, circulares, de barras, áreas, columnas, entre otros. En la mayoría de los casos se lo utiliza para representar información, sobre tendencias, proyecciones o datos “real-time” (tiempo real), de una manera organizada y fácil de entender.

Uno de los grandes puntos a favor de esta librería es el hecho de ser una de las más rápidas, ideal para usar en dispositivos móviles. Además posee documentación completa y organizada con muchos ejemplos y no necesita de componentes extra (más allá de jQuery) para funcionar. Los gráficos obtenidos son muy atractivos, con animaciones y un estilo estético.

En la aplicación “DigitalHC” fueron utilizados sólo dos tipos de gráficos: “line” y “column” , que responden a gráficos lineales y de barras en columna respectivamente. Estos gráficos fueron mostrados en el capítulo “Desarrollo propuesto”. Recordaremos uno de ellos, referido al histórico de pesos de un paciente, con el fin de mostrar un ejemplo del uso de esta librería (figura 8.3):

8.3 – Gráfico desarrollado mediante librería HighCharts

Como se puede apreciar en la imagen anterior, el gráfico generado es de tipo lineal. Posee sólo tres pares de datos. En la parte inferior, correspondiente al eje de las abscisas, se encuentra la serie, formada por los valores “1” , “2” y “3” . En el eje de las ordenadas vemos los pesos que van desde “77.5” a “92.5” . A continuación veremos el código asociado a este gráfico, simplificado para facilitar su estudio.



8.10 jsPDF

Es una librería JavaScript para la creación de documentos PDF, que además, no requiere de un servidor PHP o similar (como la gran mayoría de las herramientas existentes), sino que todo el trabajo es realizado en el cliente, con las ventajas que esto supone. Permite manejar varios objetos tales como:

• Texto: permitiendo manipular su tamaño, color, tipo de letra y posición.

• Imágenes: pudiéndose insertar en el documento y controlar su tamaño.

• Formas geométricas: admite el dibujado de líneas, círculos, rectángulos y triángulos.

Así como todas las herramientas vistas hasta el momento, requiere del uso de jQuery para su

correcto funcionamiento. A continuación mostramos un breve ejemplo de su utilización:

var doc = new jsPDF(); doc.setFontSize(22); //Se configura el tamaño de la letra en 22 doc.text(20, 20, 'Este es el titulo); //Se escribe en la posición (X,Y) = (22, 22) un texto doc.setFontSize(12); doc.text(20, 30, 'Ejemplo de texto normal'); // Salida hacia el objeto 'datauri' doc.output('datauri');

Nuestra experiencia

Realmente una herramienta muy útil e interesante. Una de las pocas que posee la gran característica de funcionar de manera autónoma. La gran mayoría de las librerías encontradas requerían del uso de PHP u otras tecnologías, las cuales no son capaces de correr en un dispositivo móvil. Además de esta característica, la sencillez con la que permite trabajar, facilitó mucho la creación del reporte necesario para nuestra aplicación, obteniendo un resultado muy positivo. Sin lugar a dudas “jsPDF” es otro gran hallazgo en el inmenso mar de librerías en la web y, seguramente, volverá a dar vida a documentos PDF, en futuros proyectos.



9. BUENAS PRÁCTICAS

9.1 Introducción

En los últimos capítulos hemos hablado y desmenuzado, todo lo referido a las características más importantes de PhoneGap: su historia, estructura, su potente interface de línea de comandos, la creación y utilización de plugins, entre otras cosas. También presentamos un problema y una aplicación para resolver el mismo, mostrando también, el uso de una batería de herramientas que facilitaron y potenciaron la utilización del framework.

En esta ocasión nos centraremos en otro punto muy importante. Nos referimos al conjunto de “buenas prácticas” de diseño que se deben tener en cuenta, a la hora de realizar una aplicación de “naturaleza web” que además, correrá en un dispositivo móvil. Decimos una aplicación de naturaleza web porque como bien sabemos, los productos generados con PhoneGap, son de tipo “híbrido”, y si bien se programan usando tecnologías web, la aplicación se termina empaquetando cual si fuera nativa.

Este capítulo intenta condensar una serie de conceptos, obtenidos a lo largo del desarrollo de la aplicación “DigitalHC” , pero que son comunes a cualquier otro proyecto que utilice tecnologías de tipo web. Principalmente hay que tener en cuenta que no estamos desarrollando una aplicación para una PC de escritorio, por ende los recursos son más limitados. Es por ello que debemos tener en cuenta ciertas pautas y no abusar de un diseño estrambótico, con el fin de apuntar a la simplicidad y obtener de ese modo, una aplicación con un rendimiento óptimo y una usabilidad acorde.



9.2 Cómo comenzar

Si nuestra intención es desarrollar una aplicación para tablets y/o smatphones, partiendo de una idea o boceto de una posible interfaz, es importante no imitar el diseño de una web para computadoras de escritorio. Un dispositivo móvil no tiene la misma capacidad de procesamiento. Por este motivo, es recomendable basarse en estándares, apuntar a la simplicidad y usabilidad, y no hacer una interfaz de usuario extravagante que conlleve a que el usuario se desoriente. Es importante no perder de vista que la aplicación se tiene que adaptar a las necesidades requeridas con el mejor rendimiento posible.

En cada sistema operativo se tiende a usar una estructura propia más o menos definida. Para observar esto, basta con ver muchas de las aplicaciones del mercado, donde la misma aplicación se visualiza en cada plataforma, según su estilo. Un ejemplo de esto lo podemos ver en la figura 9.1. Como se observa en la misma, están puntualizados cuatro ítems que son: 1) cabecera, 2) cuerpo, 3) menú y 4) botón atrás.

Tanto en “Android” como en “iOS” , la cabecera siempre se mantiene en la parte superior. En ese lugar se ubican los nombres de las secciones. Cuando el usuario entra en una de ellas, el título debe cambiar. En caso de ser una cabecera fija puede modificarse el color del título o el color de fondo de esa sección y, de esta manera, el usuario sabe en qué punto de la aplicación se encuentra, sin riesgo de desorientarse. En cambio el menú (3) suele variar, en Android por lo general se encuentra en la parte superior (luego de la cabecera) y posteriormente se visualiza el cuerpo (2). En iOS el menú suele estar debajo del todo y el cuerpo entre este y la cabecera.

Los usuarios de iOS, están acostumbrados a tener un botón “atrás” (4) en la cabecera. Sin embargo, en Android se suele utilizar el botón físico, el cual incluyen los dispositivos preparados para esa plataforma, en la parte inferior.

Fig. 9.1 – Estructura iOS y Android (de izquierda a derecha) (fuente: www.phonegapspain.com, 2013)



9.2.1 Definición de la estr

Un aspecto importante que se debe definir cuando iniciamos un proyecto, es saber cómo va a estar dividida la pantalla de nuestra aplicación y cuántas partes diferentes incluirá. Con esto queremos decir si tendrá: cabecera, cuerpo y pie secciones y qué número de pantallas por sección. Por ejemplo en la sección cultura y turismo con cuatro pantallas adicionales que poseen distintos contenidos. De esta manera se puede deslizar dicha sección hasta la última pantalla y, luego, retornar del mismo modo hacia el inicio.

Fig. 9.2 – Pantallas y Secciones

Esta aplicación de ejemplo, cestructurada en “capas” o “contenedores”desarrolladores web, llamado “body”(mediante la etiqueta “div” ) correspondientes a: la cabde la primera y la última capa se pueden incluir también botones, si hiciese falta. Este sencillo diseño permite resolver, prácticamente todas las posibilidades que se pueden presentar a la hora de diseñar una aplicación para dispositivos móviles. Para clarificar lo expuesto anteriormente se presenta la figura 9.3:

Fig. 9.3 – Definición de la estructura (cabecera, cuerpo, menú)


Chavez Alexis David

9.2.1 Definición de la estructura base

Un aspecto importante que se debe definir cuando iniciamos un proyecto, es saber cómo va a estar dividida la pantalla de nuestra aplicación y cuántas partes diferentes incluirá. Con esto queremos decir si tendrá: cabecera, cuerpo y pie o sólo cabecera sin pie o viceversa, cantidad de

número de pantallas por sección. Por ejemplo en la figura 9.2 sección cultura y turismo con cuatro pantallas adicionales que poseen distintos contenidos. De esta

puede deslizar dicha sección hasta la última pantalla y, luego, retornar del mismo modo

Pantallas y Secciones (fuente: www.phonegapspain.com

Esta aplicación de ejemplo, como la desarrollada por nosotros y como la gr“contenedores”. Existe un contenedor global bien conocido por los

“body” . En el mismo se deben montar los distintos contenedores ) correspondientes a: la cabecera, el cuerpo y el pie, por ejemplo. Dentro

de la primera y la última capa se pueden incluir también botones, si hiciese falta. Este sencillo diseño permite resolver, prácticamente todas las posibilidades que se pueden presentar a la hora de

aplicación para dispositivos móviles. Para clarificar lo expuesto anteriormente se

Definición de la estructura (cabecera, cuerpo, menú)


Pág. 205

Un aspecto importante que se debe definir cuando iniciamos un proyecto, es saber cómo va a estar dividida la pantalla de nuestra aplicación y cuántas partes diferentes incluirá. Con esto

viceversa, cantidad de figura 9.2 se puede apreciar la

sección cultura y turismo con cuatro pantallas adicionales que poseen distintos contenidos. De esta puede deslizar dicha sección hasta la última pantalla y, luego, retornar del mismo modo

.com, 2013)

mo la gran mayoría, está . Existe un contenedor global bien conocido por los

. En el mismo se deben montar los distintos contenedores ecera, el cuerpo y el pie, por ejemplo. Dentro

de la primera y la última capa se pueden incluir también botones, si hiciese falta. Este sencillo diseño permite resolver, prácticamente todas las posibilidades que se pueden presentar a la hora de

aplicación para dispositivos móviles. Para clarificar lo expuesto anteriormente se

Definición de la estructura (cabecera, cuerpo, menú)



9.3 Utilizar módulo “media queries” de CSS3

En el capítulo tercero hablamos un poco sobre este tema, ahora entraremos en un poco más de detalle. Desde hace poco tiempo, el boom de las webs adaptativas ha sido muy notable. Esto ha ocurrido por un lado, debido a la evolución del lenguaje de estilo CSS a su actual versión CSS3, y por otro, a la necesidad de poder visualizar correctamente, el contenido de las webs, en distintos dispositivos, tanto de escritorio como móviles. Una de las novedades que se incorpora es la de poder controlar diferentes estilos según el ancho de la pantalla dentro de un mismo CSS gracias a la propiedad “@media only screen”.

En la figura 9.4 se observa un dispositivo móvil en modo horizontal (Landscape) con posibilidad de contener seis elementos a lo ancho y en modo vertical (Portrait), con capacidad para cuatro elementos a lo ancho.

Fig. 9.4 – Dispositivo en Portrait y Landscape (fuente: www.phonegapspain.com, 2013)

El código asociado a la imagen anterior bien podría ser el siguiente, el cual se aplicará tanto para el dispositivo en modo apaisado, como en modo vertical: /* Smartphone (landscape y portrait) */ @media only screen and (min-device-width : 480px) and (max-device-width : 767px) { /* Estilos a aplicar*/ }



9.4 Optimizando uso de íconos mediante “Sprites”

Una forma de optimizar los íconos para una carga más rápida en el webview es, crear una presentación que contenga todas las imágenes permanentes de la aplicación (sprites), en lugar de utilizarlas por separado y, mediante CSS, montar cada una como si fuera individual. Los “sprites” permiten en definitiva, agrupar todos los archivos de imagen, en una sola. Un ejemplo de cómo funcionan, queda expresado en la figura 9.5. En la misma se observa un sprite formado por nueve iconos:

Fig. 9.5 – Uso de sprites

Suponiendo que la imagen se denomina “ejemplo.png”, el siguiente código CSS representa al primero de los íconos, en este caso, un lápiz, con un ancho y alto de cincuenta pixeles. .sprite { background: url('ejemplo.png'); height: 50px; width: 50px; }

En cambio, en esta segunda porción de código, el ícono mostrado será el último, es decir, pequeño sobre amarillo.

.sprite { background: url('ejemplo.png') -138px -143px ; height: 50px; width: 50px; }

A continuación presentamos los siguientes sitios web, en los cuales se ofrece un servicio que permite generar nuestros propios sprites:

• http://spritegen.website-performance.org/

• http://draeton.github.io/stitches/

• http://www.spritecow.com/



9.5 Reducir cantidad de capas

Las capas o contenedores, consisten en espacios rectangulares, que se utilizan mediante la etiqueta HTML denominada “ div”ellas, podemos insertar a su vez, otros contenidos como: color de fondo, tamaño de letra, dimensiones, posición, márgenes, bordes, etc.

Es recomendable no hacer un uso desmesurado de esta etiqueta en aplicaciones para dispositivos móviles. Esto responde a que la aplicación puede ver disminuida su capacidad de respuesta, al mismo tiempo que es más complicado para el desarrollador administrar su lde las técnicas para reducir el número de contenedores, es tener una pantalla lateral y moverla cada vez que sea necesario. Por ejemplo, si nuestra aplicación posee cuatro secciones como: “Galería”, “Contactos”, “Productos” e “Inicio”, no es neellas. Lo conveniente es crear un contenedor para mostrar la página actual y otro lateral que esté oculto fuera de la vista del usuariocambiado de pantalla. La forma de trabajar es la siguiente:

• Se mueve la capa que se está visualizando hacia la izquierda,• Se muestra un ícono que demuestra que la página se está cargando,

• Se carga el nuevo contenido en la capa actualmente oculta a la derecha,• Se quita el cargando y se mueve hacia el centro la capa oculta.

En la figura 9.6 se muestra un ejemplo de lo expuesto anteriormente. En este caso vemos cómo la capa perteneciente al menú a la derecha, pueda ser mostrada, previa carga del contenido, lo que permite manejar tres pantalla con un solo contenedor.

Fig


Chavez Alexis David

9.5 Reducir cantidad de capas

Las capas o contenedores, consisten en espacios rectangulares, que se utilizan mediante la div” y que pueden colocarse en cualquier parte de una página web. En

ellas, podemos insertar a su vez, otros contenidos HTML, con el fin de agregarles propiedades como: color de fondo, tamaño de letra, dimensiones, posición, márgenes, bordes, etc.

omendable no hacer un uso desmesurado de esta etiqueta en aplicaciones para dispositivos móviles. Esto responde a que la aplicación puede ver disminuida su capacidad de respuesta, al mismo tiempo que es más complicado para el desarrollador administrar su lde las técnicas para reducir el número de contenedores, es tener una pantalla lateral y moverla cada vez que sea necesario. Por ejemplo, si nuestra aplicación posee cuatro secciones como: “Galería”, “Contactos”, “Productos” e “Inicio”, no es necesario crear un componente “div”ellas. Lo conveniente es crear un contenedor para mostrar la página actual y otro lateral que esté oculto fuera de la vista del usuario, para ir cambiando su contenido interno y ser mostrado si se ha cambiado de pantalla. La forma de trabajar es la siguiente:

Se mueve la capa que se está visualizando hacia la izquierda, cono que demuestra que la página se está cargando,

arga el nuevo contenido en la capa actualmente oculta a la derecha,Se quita el cargando y se mueve hacia el centro la capa oculta.

se muestra un ejemplo de lo expuesto anteriormente. En este caso vemos mo la capa perteneciente al menú es capaz de deslizarse a la izquierda para que la capa escondida

a la derecha, pueda ser mostrada, previa carga del contenido, lo que permite manejar tres pantalla

Fig. 9.6 – Comportamiento de las capas


Pág. 208

Las capas o contenedores, consisten en espacios rectangulares, que se utilizan mediante la y que pueden colocarse en cualquier parte de una página web. En

, con el fin de agregarles propiedades como: color de fondo, tamaño de letra, dimensiones, posición, márgenes, bordes, etc.

omendable no hacer un uso desmesurado de esta etiqueta en aplicaciones para dispositivos móviles. Esto responde a que la aplicación puede ver disminuida su capacidad de respuesta, al mismo tiempo que es más complicado para el desarrollador administrar su lógica. Una de las técnicas para reducir el número de contenedores, es tener una pantalla lateral y moverla cada vez que sea necesario. Por ejemplo, si nuestra aplicación posee cuatro secciones como: “Galería”,

“div” , para cada una de ellas. Lo conveniente es crear un contenedor para mostrar la página actual y otro lateral que esté

para ir cambiando su contenido interno y ser mostrado si se ha

cono que demuestra que la página se está cargando,

arga el nuevo contenido en la capa actualmente oculta a la derecha,

se muestra un ejemplo de lo expuesto anteriormente. En este caso vemos es capaz de deslizarse a la izquierda para que la capa escondida

a la derecha, pueda ser mostrada, previa carga del contenido, lo que permite manejar tres pantalla



9.6 Realizar animaciones con CSS3

Las animaciones son, sin lugar a dudas, otro punto de inflexión en cuanto a rendimiento. Respecto a esto, cabe aclarar que lo más aconsejable, es dejar de lado (siempre que se pueda), el uso de JavaScript, generando las animaciones preferentemente mediante CSS3. Las animaciones clásicas en JavaScript se basan en la iteración de cambios de un atributo específico por ejemplo: la opacidad. Para ello requiere de “timers” que van modificando la propiedad en función del tiempo, tantas veces como el procesador del dispositivo lo permita, por ejemplo, mediante la función “setTimeout”. De este modo, se puede mover una capa cambiando su posición cada cierta cantidad de milisegundos. Este enfoque en dispositivos de escritorio no está mal, pero en artefactos de menor escala y potencia como los smartphones, puede producir un efecto escalonado que carece de naturalidad, además de provocar un consumo muy grande de recursos.

Por otro lado, los efectos CSS3 de animación o transición, se basan en código nativo desarrollado en el propio navegador, lo que conlleva a un uso optimizado del procesador y, por lo tanto, un mejor rendimiento. Mediante la propiedad “transform” en su variante “translate3d”, CSS3 permite generar transiciones basadas en la aceleración por hardware y no por software, como ocurre con JavaScript. A continuación presentamos un ejemplo donde se verá una de las formas de generar transiciones. Se trabajará inicialmente con una clase CSS genérica, llamada “pagina” , la cual definirá las propiedades básicas de la pantalla:

.pagina { position: absolute; top: 0; left: 0; width: 100%; height: 100%; -webkit-transform: translate3d(0,0,0); /* Mover página al centro 100% (Android, BlackBerry, iOS) */ transform: translate3d(0,0,0); /* Mover página al centro 100% (iExplorer) */ }

Para manejar las diferentes animaciones, se generan tres clases: “paginaIzqTotal”, para correr la página hacia la izquierda hasta desaparecer, “paginaDerTotal”, para hacer desaparecer la página hacia la derecha y “paginaCentro”, para llevar nuevamente la página al centro. Basta con asignar dinámicamente mediante JavaScript, cualquiera de las clases nombradas para generar la animación correspondiente. Mostramos a continuación cual sería su codificación CSS:

.paginaCentro { -webkit-transform: translate3d(0,0,0); /* Mover página al centro 100% (Android, BlackBerry, iOS) */ transform: translate3d(0,0,0); /* Mover página al centro 100% (iExplorer) */ } .paginaIzqTotal { -webkit-transform: translate3d(-100%,0,0); /* Mover a la izquierda 100% (Android, BlackBerry, iOS) */ transform: translate3d(-100%,0,0); /* Mover a la izquierda 100% (iExplorer) */ } .paginaDerTotal{ -webkit-transform: translate3d(100%,0,0); /* Mover a la derecha 100% (Android, BlackBerry, iOS) */ transform: translate3d(100%,0,0); /* Mover a la derecha 100% (iExplorer) */ }



En la figura 9.7, se visualizan las diferentes posiciones adoptables por ciertas pantallas. Básicamente se ve un menú oculto a la izquierda ((left: 0) y una pantalla adicional oculta a la derecha (

Existe una propiedad llamada duración a una animación específica. A tal efecto se puede crear una clase modificar dicha propiedad, con un código como el que sigue:

.transicion { /* Establecer velocidad de transici -webkit-transform-duration: .5s; /* ( transition-duration: .5s; /* (iExplorer}


Chavez Alexis David

En la figura 9.7, se visualizan las diferentes posiciones adoptables por ciertas pantallas. Básicamente se ve un menú oculto a la izquierda (left: -100%), un cuerpo principal en el centro

) y una pantalla adicional oculta a la derecha (left: 100%):

Fig. 9.7 – Transiciones con CSS3

Existe una propiedad llamada “transition” , mediante la cual se logra dar un tiempo de duración a una animación específica. A tal efecto se puede crear una clase CSS3modificar dicha propiedad, con un código como el que sigue:

/* Establecer velocidad de transición en medio (0.5) segundo */ /* (Android, BlackBerry, iOS) */

iExplorer) */


Pág. 210

En la figura 9.7, se visualizan las diferentes posiciones adoptables por ciertas pantallas. ), un cuerpo principal en el centro

, mediante la cual se logra dar un tiempo de CSS3, y de ese modo,



9.7 Precarga de archivos HTML

Si la aplicación desarrollada tiene varias secciones (y es lo más probable que vaya a suceder), seguramente se utilizarán varios archivos HTML, con el fin de separar la lógica de cada una de ellas. Si se desea evitar la aparición de “saltos” al cambiar de sección (página HTML), existe una técnica a utilizar. Nos referimos a la precarga de los códigos mediante una función provista por jQuery, llamada “load” . La misma permite cargar en un contenedor, el código existente en un archivo HTML. Para clarificar este concepto, mostraremos un fragmento simplificado del código perteneciente a la aplicación “DigitalHC” desarrollada.

$(document).ready( function ( ) { $('#pacientes').hide(); // Se oculta esta capa $('#pacientes').load('pacientes.html'); // Se carga la capa con el contenido del HTML correspondiente $('#tablas').hide(); $('#tablas').load('tablas.html'); $('#reportes').hide(); $('#reportes').load('reportes.html'); $('#presentacion').load('presentacion.html'); // Se cargará y mostrará esta capa inicialmente });

El código precedente toma los tres componentes principales de la aplicación: “pacientes”, “tablas” y “reportes”, y previa ocultación de los mismos, mediante el comando “hide” , realiza la carga del código pertinente a cada uno de ellos. En la anteúltima línea, se carga la pantalla de presentación de la aplicación, la cual, al no aplicarle el comando hide, se muestra al usuario. Este código es ejecutado al iniciarse la aplicación. Posteriormente, al seleccionar alguna de las secciones disponibles, se hará visible la misma mediante el comando “show” y se ocultará la capa dedicada a la presentación. El código básicamente es el siguiente, suponiendo que se escoge la opción “pacientes”:

if(id_seccion == 'pacientes'){ $('#pacientes').show(); // Se muestra sección ‘pacientes’ $('#presentacion').hide(); // Se oculta la capa ‘presentación’ }



9.8 Mostrar símbolo de carga

Algo que quizás pasa inadvertido al comenzar el desarrollo, pero que se hace patente a medida que nuestra aplicación es probada en distintos dispositivos, es la necesidad de indicar al usuario que algún componente de la interfaz se está cargando. Aunque parece algo menor, este detalle hace realmente a la usabilidad de la aplicación. Dependiendo de la capacidad de hardware del dispositivo, muchas veces se puede tardar en cargar por ejemplo, un listado por ser muy complejo o extenso o bien porque los datos requeridos deben llegar desde un servidor. Cualquiera sea el caso, es una buena práctica mostrar al usuario que la aplicación sigue activa y que debe esperar unos instantes.

En la aplicación “DigitalHC” , este fue uno de los últimos detalles agregados. La figura 9.8, muestra el aspecto de la animación CSS3 utilizada para la espera del usuario:

Fig. 9.8 – Detalle de la animación de espera usado en la aplicación “DigitalHC”

A continuación mostramos el detalle del código CSS3 utilizado, donde se definen las características de la clase encargada de realizar la animación. Para mostrar u ocultar el objeto de la clase “espera”, simplemente se usó JavaScript.

.espera { height: 80px; width: 80px; top: 50%; margin-top: -50px; left: 50%; margin-left: -50px; position: fixed; -webkit-animation: rotation .6s infinite linear; border-left: 10px solid rgba(0,174,239,.15); border-right: 10px solid rgba(0,174,239,.15); border-bottom: 10px solid rgba(0,174,239,.15); border-top: 10px solid rgba(0,174,239,.8); border-radius: 100%; } @-webkit-keyframes rotation { from {-webkit-transform: rotate(0deg);} to {-webkit-transform: rotate(359deg);} }



9.9 Otros consejos para una aplicación fluida

No es muy agradable que al utilizar una aplicación, se observe un comportamiento lento, con poca capacidad de respuesta o transiciones poco fluidas. Para evitar estos problemas, es necesario tener presente algunas cuestiones en el diseño. A modo de resumen, listamos a continuación, algunos puntos clave a tener en cuenta:

• No abusar de las tipografías: Si no se utiliza una tipografía de base nativa, el webview está forzando leer e interpretar un archivo externo en el navegador.

• No abusar de bordes redondeados: Se los puede utilizar pero no exageradamente. Al igual que la propiedad Shadow (sombras), disminuye el rendimiento del dispositivo, y será más notable aún, en uno de gama baja.

• No utilizar en demasía degradados CSS: Lo mismo que en el caso anterior, un degradado hecho con CSS, también afecta la performance del dispositivo. En su lugar conviene utilizar una imagen degradada por ejemplo: para efectuar un degradado a una cabecera, es recomendable usar una imagen de un pixel de ancho y repetirla al ancho de la capa.

• No usar animaciones JavaScript: Con JavaScript se pueden realizar muchos tipos de animaciones, pero requieren de un hardware bastante potente para correr fluidamente. En su lugar es mejor utilizar CSS3 para animar los componentes de la interfaz, y la diferencia de rendimiento será notable.

• Las imágenes e íconos deben adaptarse a todas las resoluciones: No hace falta crear muchas versiones de un mismo ícono o imagen. Las mismas se deben adaptar a las distintas resoluciones de pantalla mediante CSS.

• No generar la interfaz de usuario en el servidor: No es una buena práctica que la interfaz de la aplicación se cargue de manera dependiente a un servidor. Toda la estructura y estilos de la misma, deben funcionar de manera autónoma y, sólo se debe depender de los servidores, para la obtención de datos, si hiciera falta. De otro modo, se pueden experimentar varias falencias como: enlentecimiento de la aplicación o incluso, incapacidad de cargar parte de la interfaz (en caso de no poder conectar con el servidor).

• Limitar el acceso a un servidor externo: Es recomendable que, en tanto y en cuanto sea posible, se limite el acceso a servidores en la búsqueda de datos. Esto dependerá seguramente del volumen de datos manejados, y de la naturaleza de la aplicación en sí misma.

• Evaluar la necesidad de usar frameworks: Existe una gran cantidad de frameworks para dispositivos móviles, y más aún, en estos últimos años. Sin embargo, debemos evaluar si realmente nuestra aplicación, necesita utilizar uno, ya que no siempre nos va a beneficiar su uso, quizás sólo lograremos sobrecargar la aplicación sin necesidad de ello. Si lo que buscamos es hacer una interfaz de usuario estética, la podemos realizar perfectamente combinando CSS3 y JavaScript. Hay que recordar que debemos apuntar a: la simplicidad, usabilidad y la mayor cantidad de dispositivos posible, aún aquellos que carecen de un hardware moderno.



10. PRUEBAS, RESULTADOS Y CONCLUSIONES

10.1 Introducción

En el presente capítulo, se pretende mostrar los resultados obtenidos de la utilización de PhoneGap y luego de la realización de nuestra aplicación. La idea es poder contar nuestra experiencia y conclusiones obtenidas del uso de esta herramienta, a lo largo del desarrollo de este proyecto. Este enfoque estará orientado a las pruebas y herramientas de testeo usadas, así como temas referidos a las configuraciones.

También pretendemos relatar cómo fue la prueba en otras plataformas diferentes de “Android” . Particularmente nos referimos a los sistemas operativos “iOS” y “BlackBerry 10” , donde mediante sus respectivos emuladores, logramos dar vida a la aplicación “DigitalHC” , para poder comprobar así la propiedad de “multiplataforma” , ostentada por PhoneGap.

Sobre el cierre del capítulo, se presentarán algunos resultados obtenidos luego del desarrollo de nuestra aplicación. Intentaremos plasmar nuestra impresión personal referida al uso de este framework, tratando de poner en evidencia tanto, las características positivas, como las negativas y expidiendo una opinión final en concreto.



10.2 Pruebas en Android

Como se introdujo en el capítulo cuarto: “Presentando Phonegap”, al momento de comenzar el desarrollo de nuestra aplicación, decidimos que la plataforma a utilizar para las pruebas sería Android. Esto se debió en gran medida a los siguientes factores:

• La mayor parte de la documentación encontrada se refería a esa plataforma.

• Android permite la instalación de aplicaciones en dispositivos reales de manera sencilla. • Contábamos con dispositivos físicos para poder probar esa plataforma.

• Representa mejor que otras plataformas, la premisa planteada por nosotros, respecto al uso de herramientas de código abierto.

Por supuesto que la aplicación fue probada posteriormente en otras plataformas, mediante los respectivos emuladores. De otro modo, no tendría sentido haber hablado todo este tiempo de multiplataforma, y nuestro trabajo carecería de sentido, dado que estaríamos olvidando una de las premisas planteadas al comenzar el proyecto. Desde ya anticipamos que hablaremos de esas pruebas un poco más adelante en el capítulo.

Volviendo al tema de las primeras pruebas, concretamente para realizar el testeo de la aplicación “DigitalHC” , se utilizaron tres entidades diferentes, las cuales se fueron alternando según la necesidad:

• Dispositivo físico, Sony Xperia U (ST 25a) • Emulador (AVD) • Google Chrome

Los tres entornos de prueba presentan diferentes características, y pensamos firmemente que todos fueron necesarios por distintos motivos. Al momento de comenzar el desarrollo de la aplicación en cuestión, fuimos descubriendo virtudes y falencias de cada uno de ellos, por lo que resumimos que el combo completo fue menester para llegar a buen puerto en esta historia. Por supuesto esta aseveración se basa en nuestra experiencia personal y, bajo ningún concepto, pretende ser “la receta” a seguir.

En las próximas líneas mostraremos algunas de las características más importantes de los diferentes entornos de testeo utilizados para la plataforma Android.

10.2.1 Entornos de prueba

10.2.1.1 Dispositivo físico

El dispositivo físico utilizado, denominado “Sony Xperia U (ST 25a)”, pertenece a la gama media/baja de esa marca. Posee además la versión 4.0.4 del sistema operativo Android (siendo la actual la 4.4.2). Sus características de hardware son:



� Pantalla: 480 x 854 pixeles, 3.5 pulgadas � Memoria de programas: 2Gb � Memoria de datos: 4Gb � Memoria RAM: 512Mb (388.63Mb utilizables) � Procesador: Dual-core 1.0GHz

Configurar seguridad

Para poder instalar la aplicación en el dispositivo, primero se debe habilitar la instalación de “fuentes desconocidas”. Esto se logra entrando en configuraciones del dispositivo, en la opción “Seguridad”, y dentro de la misma, se debe tildar el checkbox etiquetado: “Fuentes Desconocidas”, como se muestra en la figura 10.1:

Fig. 10.1 – Detalle de configuración para permitir instalar aplicaciones con fuente desconocida

Políticas de prueba

Básicamente se utilizó este entorno de prueba, cada vez que se realizó un avance significativo en el desarrollo de la aplicación. Mayormente sirvió para pulir detalles de performance y compatibilidad, dado que muchas de las características de la interfaz gráfica, funcionaban correctamente en el emulador o en Chrome, pero en el dispositivo presentaban alguna deficiencia, por lo que debían corregirse. Otro de los aspectos que permitió probar fehacientemente fue el uso del GPS y la conexión con el servidor PHP.



10.2.1.2 Google Chrome

Sin lugar a dudas, el entorno de prueba que más fue utilizado. Si hubiera que cuantificar la cantidad de pruebas realizadas en función de porcentajes, sin miedo a equivocarnos, diríamos que “Google Chrome” se lleva al menos, un 70% del total. Esta supremacía respecto a los otros entornos responde a dos simples factores: rapidez de compilación y ejecución. Esta velocidad se debe a que PhoneGap está optimizado para recompilar en unos pocos segundos la aplicación y, montarla en un servidor web propio, para ser luego, emulada desde Chrome como si fuera una página web común, con las ventajas que ello conlleva.

Otra de las características positivas de este browser (y aprovechable por nosotros), es que provee una potente herramienta de inspección. La misma que nos da la posibilidad de seguir y depurar más fácilmente la aplicación, permitiéndonos observar una serie de parámetros. Para desplegar esta herramienta, basta con posicionar el puntero del mouse en alguna parte de la aplicación, presionar el clic derecho del mouse y seleccionar la opción: “Inspeccionar elemento”, como se muestra en la figura 10.2:

Fig. 10.2 – Despliegue del inspector de Google Chrome

Esta acción generará la aparición de varios elementos útiles para el debugging (depuración), tal y como se muestra en la figura 10.3:

Fig. 10.3 – Detalle de la herramienta de inspección de Google Chrome



Como se puede apreciar en la figura 10.3, se despliega una sub ventana en la parte inferior del navegador que contiene un interesante agrupamiento de opciones, y de gran utilidad. La primera que aparece, y que es mostrada por default, denominada “Elements”, permite ver en la parte de la izquierda, el código HTML asociado a los objetos de la pantalla, en este caso el botón “Enviar Mail” . En la zona de la derecha podemos observar los diferentes estilos aplicados a este componente, así como otras propiedades.

Fig. 10.4 – Opción “Elements” del inspector de Chrome

Otra parte interesante del inspector se encuentra en la solapa: “Sources”, donde podemos ver entre otras cosas, los diferentes archivos fuentes de la aplicación en ejecución (figura 10.5).

Fig. 10.5 – Opción “Sources” del inspector de Chrome

Existe una opción muy útil provista por esta herramienta, denominada: “Resources”, la cual permite inspeccionar las diferentes estructuras de datos utilizadas por nuestra aplicación. En la figura 10.6 se puede apreciar el detalle de las tablas pertenecientes a la base de datos “historiabd” de la aplicación “DigitalHC” , implementada utilizando WebSQL. Además de ver las estructuras, también permite auditar los datos de las tablas, como es el caso de la tabla “pais” , mostrada en la misma imagen.



Fig. 10.6 - Opción “Resources” del inspector de Chrome

Finalmente, la última de las opciones más importantes, a nuestro criterio, se encuentra en la solapa “Console”. Desde allí se pueden visualizar los diferentes mensajes, por ejemplo de error, advertencias, etcétera. Esta consola también puede ser utilizada por nosotros para mostrar mensajes útiles para la depuración de nuestra aplicación en desarrollo. A tal efecto se puede utilizar el siguiente comando JavaScript, el cual recibe una cadena de caracteres, la cual será mostrada en la consola:

console.log(mensaje);

En la figura 10.7 se presenta un ejemplo de la salida observada al ejecutar nuestra aplicación. Como se puede observar, se listan tres líneas de error referidas a la imposibilidad de acceder a tres imágenes con extensión “jpg” . Esto se debe a que las ubicaciones de las mismas, carecen de sentido fuera del sistema de archivos de un dispositivo real.

Fig. 10.7 – Opción “Console” del inspector de Chrome



10.2.1.3 Emulador

Este entorno de pruebas es uno de los más ampliamente difundidos, tanto para ser utilizado con PhoneGap, como con otras opciones de desarrollo. En nuestro caso, fue el segundo más utilizado, sólo después de Google Chrome. Básicamente permitió probar el funcionamiento de todo lo referido con el manejo de: la cámara fotográfica, sistema de archivos, así como el pulido de la interfaz de usuario.

Para poder acceder a la creación y configuración de un nuevo emulador para Android, se debe ingresar el siguiente comando desde la shell de Linux:

$>android

Esto desplegará el gestor de AVDs (Android Virtual Device), tal y como se muestra en la figura 10.8. En la misma se puede apreciar la gestión de paquetes, que permite agregar, actualizar y quitar componentes de emulación tales como: versiones del sistema operativo Android, herramientas, documentación, ejemplos, entre otras cosas.

Fig. 10.8 – Gestor de AVDs y paquetes para el emulador de Android



Para tener acceso al gestor de máquinas virtuales, se sebe acceder al menú “Tools” y dentro del mismo, a la opción “Manage AVDs”, de la misma manera que se muestra en la figura 10.9.

Fig. 10.9 – Opción para la gestión de máquinas virtuales de Android (AVD)

Una vez dentro de la opción “Manage AVDs”, veremos una imagen similar a la de la figura 10.10. En la misma se puede apreciar el listado de máquinas virtuales creadas (en este caso dos: “test-ubu” y “S4” ). En la parte lateral derecha de la figura, se encuentran las opciones creación, inicio, edición, eliminación y vista de detalles de cada una de las máquinas virtuales.

Fig. 10.10 – Detalle del gestor de AVDs

La opción que más nos interesa es la denominada “Create”. La misma nos permitirá crear y configurar los diferentes parámetros de una nueva máquina virtual. Los detalles de configuración se muestran en la figura 10.11, y se explican posteriormente qué parámetros son los más importantes y que deben ser tenidos en cuenta.



Fig. 10.11 – Detalle de configuración de una AVD

• AVD name: Nombre del emulador o máquina virtual. • Device: Tipo y tamaño de la pantalla. • Target: Versión del sistema operativo a usar. • CPU/ABI: Arquitectura de CPU utilizada por el emulador. • Keyboard: Si se utilizará el teclado de la PC o el del emulador. • Skin: Opciones para los botones del emulador. • Front Camera, Back Camera: Gestión de las cámaras frontal y trasera respectivamente. • RAM: Memoria RAM asignada al dispositivo. • VM Heap: Tamaño de la pila de la memoria virtual. • Internal Storage: Memoria interna del dispositivo. • SD Card: Memoria externa del dispositivo.

Luego de configurar una AVD, ya podremos utilizar el comando “emulate” de la CLI de PhoneGap (visto en el capítulo “Presentando Phonegap”), el cual se encargará de desplegar nuestra máquina virtual e instalar la aplicación desarrollada automáticamente.



10.2.1.4 Resumen sobre entornos de prueba

A modo de resumen, presentamos a continuación la tabla 10.1 con la comparativa que muestra las fortalezas y debilidades, a nuestro entender, de cada uno de los ambientes de prueba utilizados. Si se observan las diferentes características remarcadas, se llegará a la conclusión de que dichas herramientas son complementarias, y que cada una enriquecerá aspectos del desarrollo, en diferentes puntos de su ciclo de vida. Cabe aclarar que esta tabla, se gestó a partir del conocimiento empírico obtenido durante el desarrollo de la aplicación creada.

Tabla 10.1 – Fortalezas y debilidades de las herramientas de prueba usadas

ENTORNO VIRTUDES FALENCIAS

Rápida compilación y prueba Variación en algunos aspectos de la interfaz respecto

Ideal para testear la Interfaz de la aplicación a dispositivos reales

Google Consume pocos recursos de hardware Pérdida de la noción de performance

Chrome Da soporte para la mayoría de las estructuras de Imposibilidad de probar ciertos aspectos específicos

datos estudiadas referidos al hardware de los dispositivos (cámara,

sistema de archivos, brújula, etc.)

Es un entorno de prueba controlado, con un Consume muchos recursos del sistema anfitrión

comportamiento muy similar a un disp. real Es perceptiblemente más lento que un disp. real

Emulador Es una buena opción de no poseer un disp. físico Puede dar una sensación errada de la performance de

Es altamente configurable la aplicación

Buena integración con comandos de PhoneGap Requiere de un hardware considerable para correr

Permite una prueba real para comprobar a Por una cuestión de costos, no siempre se puede

Dispositivo ciencia cierta, el funcionamiento de la aplicación contar con un dispositivo real para probar

real Favorece el desarrollo al permitir constatar qué Si el dispositivo es de gama alta, puede provocar que

cosas funcionan correctamente y cuáles deben se genere una aplicación demasiado exigente para

cambiarse otros de menor hardware o versión de sist. operativo

10.2.2 Pruebas y resultados obtenidos

Con el fin de tener algunos valores de referencia, realizamos la instalación de la aplicación “DigitalHC” en tres dispositivos Android diferentes. Para tomar una noción de la memoria utilizada por la misma, también instalamos la aplicación “Hello World” , la cual es provista por PhoneGap como ejemplo al instalar la plataforma Android, y bien podría ser tomada como un ejemplo mínimo.

• Versión de PhoneGap utilizada en la compilación: 3.5.

• Tamaño del instalador (APK) de la aplicación “Hello World” : 392Kb. • Tamaño del instalador (APK) de la aplicación “DigitalHC” : 890Kb.

• Aplicación utilizada para auditar memoria usada por aplicaciones: “Clean Master”.



Referencias

� Dispositivo: Donde se probó la aplicación, puede ser físico o virtual. � Sistema Operativo: Versión del sistema subyacente utilizado por el dispositivo. � Memoria disponible: Cantidad de RAM disponible en el dispositivo. � Memoria usada en Stand By: Cantidad de RAM usada al abrirse la aplicación y estar en

reposo o segundo plano. � Memoria usada en carga: Cantidad de RAM utilizada al usar la aplicación y activar todas

las pantallas/funcionalidades.

Primera prueba aplicación “Hello World” � Dispositivo: Emulador � Sistema Operativo: Android 4.4.2 � Memoria disponible: 512Mb � Memoria usada en Stand By: aprox. 19.9Mb � Memoria usada en carga: aprox. 19.9Mb

Segunda prueba aplicación “Hello World” � Dispositivo: Sony Xperia U � Sistema Operativo: Android 4.0 .4 � Memoria disponible: 388.63Mb � Memoria usada en Stand By: aprox. 16.5Mb � Memoria usada en carga: aprox. 16.5Mb

Tercera prueba aplicación “Hello World”

� Dispositivo: Samsung S4 � Sistema Operativo: Android 4.4.2 � Memoria disponible: 1.82Gb � Memoria usada en Stand By: aprox. 26.3Mb � Memoria usada en carga: aprox. 26.3Mb

Cuarta prueba aplicación “DigitalHC” � Dispositivo: Emulador � Sistema Operativo: Android 4.4.2 � Memoria disponible: 512Mb � Memoria usada en Stand By: aprox. 31.4Mb � Memoria usada en carga: aprox. 46.9Mb

Quinta prueba aplicación “DigitalHC” � Dispositivo: Sony Xperia U � Sistema Operativo: Android 4.0 .4 � Memoria disponible: 388.63Mb � Memoria usada en Stand By: aprox. 30.7Mb � Memoria usada en carga: aprox. 52.3Mb



Sexta prueba aplicación “DigitalHC” � Dispositivo: Samsung S4 � Sistema Operativo: Android 4.4.2 � Memoria disponible: 1.82Gb � Memoria usada en Stand By: aprox. 35.1Mb � Memoria usada en carga: aprox. 60.4Mb

Para resumir lo anterior, mostramos a continuación la tabla 10.2 donde se concentran los valores comentados:

Tabla 10.2 – Resumen pruebas en diferentes dispositivos Android

Dispositivo Emulador Xperia U S4

Sistema Operativo Android 4.4.2 Android 4.0.4 Android 4.4.2

Aplicación Hello World DigitalHC Hello World DigitalHC Hello World DigitalHC

RAM usada en Stand

By (Mb) 19.9 31.4 16.5 30.7 26.3 35.1 RAM usada en carga

(Mb) 19.9 46.9 16.5 52.3 26.3 60.4

Luego de observar los valores arrojados por las pruebas, podemos sacar varias conclusiones. En primer lugar, podemos ver que la aplicación mínima (Hello World) desarrollada con PhoneGap, utiliza un promedio de 20Mb de memoria. Los valores para la misma con carga o sin carga son iguales, dado que al ser una aplicación de muestra, no posee opciones o funcionalidades utilizables. En el caso de la aplicación “DigitalHC” , se observa cómo el uso de memoria oscila entre los 30.7Mb y los 35.1Mb sin carga, y luego de utilizar todas las funcionalidades entre los 46.9Mb y los 60.4Mb. La variabilidad entre los diferentes tamaños registrados, responde probablemente a la disponibilidad de memoria en cada dispositivo y también quizás, a la versión del sistema operativo subyacente y su manera de gestionar la memoria.



10.3 Pruebas en iOS

Con el fin de probar la supuesta propiedad de PhoneGap de ser multiplataforma, se realizó el testeo de la aplicación “DigitalHC” en la plataforma “iOS” de “Apple Inc”. A tal efecto, se hizo la configuración correspondiente de PhoneGap (de forma similar a la expuesta en el capítulo “Presentando Phonegap”) en un equipo físico con las siguientes características:

� Marca: Apple � Memoria: 4Gb � Procesador: 1.3 GHz Intel Core i5 � Sistema Operativo: Mac OS X 10.9.4 Mavericks

Cabe aclarar que no existe un emulador de iOS fuera del entorno “Mac OS X”, por lo que de no contar con una computadora con ese sistema operativo, la única solución es la emulación de la misma mediante alguna de las opciones de virtualización del mercado (como VMware o VirtualBox). Si ese fuera el caso, se requeriría un equipo anfitrión con características no menores que las siguientes:

� Memoria necesaria: Al menos 1Gb (se recomienda 2Gb) para asignarle a la máquina virtual. � Procesador: Debe ser Intel (no AMD), con soporte para vitalización. � Espacio en disco: Al menos unos 30Gb libres en disco.

10.3.1 Instalar Xcode IDE

Además de los requerimientos antes nombrados, es requisito obligatorio, según la propia documentación de PhoneGap, la utilización de Xcode en su versión 4.5 como mínimo. Esta herramienta facilitará en gran medida la labor de compilación y prueba para la plataforma iOS, ya que incluye dentro de sí misma el “iOS SDK” .

10.3.2 Creación de la aplicación

Luego de instalar PhoneGap y la herramienta Xcode, se procede a la creación de la aplicación. Por este motivo desde la línea de comandos ejecutamos:

$>phonegap create DigitalHC com.digitalhc “DigitalHC”

10.3.3 Creación de la plataforma iOS

Posteriormente se procede a instalar la plataforma correspondiente a iOS mediante el siguiente comando:



$>cordova platform add ios

Luego de ejecutar el comando anterior, podemos encontrar dentro de la carpeta “platform” del proyecto creado, el archivo “DigitalHC.xcodeproj” generado por PhoneGap. Al abrir el mismo, se desplegará la herramienta Xcode con el código fuente de nuestra aplicación.

10.3.4 Copiar código fuente e instalar plugins

Antes de continuar, copiaremos los códigos HTML5, CSS3 y JavaScript desde nuestro proyecto en Linux, a nuestra carpeta de trabajo en Mac. Posteriormente instalaremos los plugins necesarios mediante los siguientes comandos:

$>cordova plugin add org.apache.cordova.vibration $>cordova plugin add org.apache.cordova.dialogs $>cordova plugin add org.apache.cordova.geolocation $>cordova plugin add org.apache.cordova.device $>cordova plugin add org.apache.cordova.file $>cordova plugin add org.apache.cordova.camera

10.3.5 Abriendo el proyecto en Xcode

Ahora sí, ejecutaremos el archivo “DigitalHC.xcodeproj”, el cual abrirá el IDE Xcode 5.1, en este caso, el cual tiene una apariencia como la de la figura 10.12.

Fig. 10.12 – Vista del proyecto “DigitalHC” desde Xcode 5.1



Como se puede apreciar en la figura anterior, como “Eclipse” o “NetBeans”. Es unMac. En nuestro caso utilizamos para la gestión del código, el editor llamado embargo mediante Xcode pudimos comprobar lo sencillo y fácil que resultó lo referente a la emulación. En la figura 10.13 mostramos en da esta simulación.

Fig. 10.13

10.3.6 Emulación de la aplicación

Como se puede apreciar en la figura 10.13, existen varias opciones de emulación y depuración. Además se puede elegir el dispositivo y versión de la plataforma a utilizar, “iOS 6.1” en este caso. Una vez que se da clic es lanzado y la aplicación es instalada en el mismo, igual que como se muestra en la figura 10.14:

Fig. 10.14 – Emulador de

Al abrir la aplicación, podemos verplataforma Android. En la figura 10.15 vemos los tres puntos principales del menú desplegados:


Chavez Alexis David

Como se puede apreciar en la figura anterior, Xcode es una herramienta muy parecida a otras . Es un IDE muy poderoso, además de famoso entre los usuarios de

. En nuestro caso utilizamos para la gestión del código, el editor llamado pudimos comprobar lo sencillo y fácil que resultó lo referente a la

emulación. En la figura 10.13 mostramos en dónde se encuentran las opciones que permiten acceder

.13 – Detalle del panel de control del emulador

Emulación de la aplicación

Como se puede apreciar en la figura 10.13, existen varias opciones de emulación y depuración. Además se puede elegir el dispositivo y versión de la plataforma a utilizar,

en este caso. Una vez que se da clic sobre la opción “Build for Running”es lanzado y la aplicación es instalada en el mismo, igual que como se muestra en la figura 10.14:

Emulador de iOS con la aplicación “DigitalHC” instalada

Al abrir la aplicación, podemos ver que su aspecto es muy similar al observado en la . En la figura 10.15 vemos los tres puntos principales del menú desplegados:


Pág. 229

es una herramienta muy parecida a otras muy poderoso, además de famoso entre los usuarios de

. En nuestro caso utilizamos para la gestión del código, el editor llamado “Sublime text 2”. Sin pudimos comprobar lo sencillo y fácil que resultó lo referente a la

nde se encuentran las opciones que permiten acceder

Como se puede apreciar en la figura 10.13, existen varias opciones de emulación y depuración. Además se puede elegir el dispositivo y versión de la plataforma a utilizar, “iPhone” e

“Build for Running” , el emulador es lanzado y la aplicación es instalada en el mismo, igual que como se muestra en la figura 10.14:

instalada

que su aspecto es muy similar al observado en la . En la figura 10.15 vemos los tres puntos principales del menú desplegados:



Fig. 10.15 – Vista rápida de los tres puntos de menú de la aplicación

Cambios en la apariencia

Los cambios más evidentes que pudieron observarse en la interfaz gráfica sobre la plataforma iOS, respecto de Androidrealiza automáticamente según la plataforma en la ilustra lo comentado:

Fig. 10.16 – Detalle de un combo y una lista ( izquierda a derecha) con el aspecto típico de

Reportes gráficos y PDF

Pudimos constatar que tanto los gráficos estadísticos, como el reporte correctamente, como lo muestra la figura 10.17. Observar que también ha cambiado la apariencia de los cuadros de diálogo, a colación de lo observado en el párrafo ant


Chavez Alexis David

Vista rápida de los tres puntos de menú de la aplicación “DigitalHC”

Los cambios más evidentes que pudieron observarse en la interfaz gráfica sobre la Android, fueron en las listas y combos. Esta apariencia fluctuante se

realiza automáticamente según la plataforma en la que corra la aplicación. En la figura 10.16 se

Detalle de un combo y una lista ( izquierda a derecha) con el aspecto típico de

Pudimos constatar que tanto los gráficos estadísticos, como el reporte correctamente, como lo muestra la figura 10.17. Observar que también ha cambiado la apariencia de

ión de lo observado en el párrafo anterior.


Pág. 230

“DigitalHC” en iOS

Los cambios más evidentes que pudieron observarse en la interfaz gráfica sobre la , fueron en las listas y combos. Esta apariencia fluctuante se

que corra la aplicación. En la figura 10.16 se

Detalle de un combo y una lista ( izquierda a derecha) con el aspecto típico de iOS

Pudimos constatar que tanto los gráficos estadísticos, como el reporte PDF, se realizaron correctamente, como lo muestra la figura 10.17. Observar que también ha cambiado la apariencia de



Fig. 10.17 – Gráfico estadístico y reporte

Para poder observar la creación del reporte, se accedió al sistema de archivos de la máquina virtual desde el programa “Finder”creación de las carpetas pertinentes, tal como se ve en la figura 10.18.

Fig. 10.18 – Detalle del sistema de archivos del emulador mostrando el reporte

Reporte de coordenadas

Se pudo comprobar que el dispositivo viservidor PHP, entre los cuales se encontraban: la ubicación del mismo (un valor de prueba) y el identificador de dispositivo.

Lo que no se pudo probar

La única característica que no pudimos testear por unde la fotografía de un paciente. Inicialmente pensamos que se debía a un error en la compilación o programación, pero luego descubrimos que era una restricción propia de la máquina virtual de En la figura 10.19 podemos observar el mensaje desplegado al intentar tomar la imagen de un paciente desde la cámara.


Chavez Alexis David

Gráfico estadístico y reporte PDF (de izquierda a derecha)

Para poder observar la creación del reporte, se accedió al sistema de archivos de la máquina “Finder” de Mac, donde se pudo abrir dicho archivo y ver la correcta

creación de las carpetas pertinentes, tal como se ve en la figura 10.18.

Detalle del sistema de archivos del emulador mostrando el reporte

Se pudo comprobar que el dispositivo virtual fue capaz de enviar los datos necesarios al , entre los cuales se encontraban: la ubicación del mismo (un valor de prueba) y el

La única característica que no pudimos testear por una falencia del emulador, fue la captura de la fotografía de un paciente. Inicialmente pensamos que se debía a un error en la compilación o programación, pero luego descubrimos que era una restricción propia de la máquina virtual de

podemos observar el mensaje desplegado al intentar tomar la imagen de un


Pág. 231

(de izquierda a derecha)

Para poder observar la creación del reporte, se accedió al sistema de archivos de la máquina archivo y ver la correcta

Detalle del sistema de archivos del emulador mostrando el reporte PDF creado

rtual fue capaz de enviar los datos necesarios al , entre los cuales se encontraban: la ubicación del mismo (un valor de prueba) y el

a falencia del emulador, fue la captura de la fotografía de un paciente. Inicialmente pensamos que se debía a un error en la compilación o programación, pero luego descubrimos que era una restricción propia de la máquina virtual de iOS.

podemos observar el mensaje desplegado al intentar tomar la imagen de un



Fig. 10.19 – Mensaje de error mostrado al intentar capturar la imagen de un paciente

Nota: La razón por la que no se implementó la aplicación en un dispositivo físico, además de responder a que no poseíamos uno, se debe a una de las políticas de permitir la instalación de aplicaciones en dispositivos reales, a mende desarrollador autorizado. Para obtener la misma se debe pagar (unos US$ 99 anuales).


Chavez Alexis David

Mensaje de error mostrado al intentar capturar la imagen de un paciente

La razón por la que no se implementó la aplicación en un dispositivo físico, además de responder a que no poseíamos uno, se debe a una de las políticas de Apple. La misma consiste en no permitir la instalación de aplicaciones en dispositivos reales, a menos que se cuente con una firma de desarrollador autorizado. Para obtener la misma se debe pagar (unos US$ 99 anuales).


Pág. 232

Mensaje de error mostrado al intentar capturar la imagen de un paciente

La razón por la que no se implementó la aplicación en un dispositivo físico, además de . La misma consiste en no

os que se cuente con una firma de desarrollador autorizado. Para obtener la misma se debe pagar (unos US$ 99 anuales).



10.4 Pruebas en BlackBerry 10

Así como ocurrió al intentar probar la aplicación en a plataforma iOS, para el caso de “BlackBerry 10” (en adelante BB10) también se debió recurrir a la emulación para poder realizar el testeo. Esto fue así por no contar con un dispositivo físico para realizar las pruebas. A diferencia de iOS, se puede generar una firma y así instalar aplicaciones propias de manera más fácil. El trámite es gratuito, registrándose a tal efecto en la página oficial de BlackBerry. La buena noticia respecto a esta plataforma, es que puede ser emulada en cualquiera de los sistemas operativos de más difusión: “Linux”, “Mac OS X” o “Windows”. En nuestro caso, podremos reutilizar el código y configuraciones usados para Android sobre la plataforma Linux.

10.4.1 Requerimientos básicos

� Procesador: Intel o AMD con soporte para virtualización. � Memoria: Al menos 1.5Gb asignables a la máquina virtual. � Espacio en disco: Al menos 10Gb libres. � Software de virtualización: VMware Player (Linux, Windows), VMware Fusion (Mac OS X).

A continuación detallaremos los pasos requeridos para poder instalar todos los componentes necesarios y, de esa forma, emular nuestra aplicación. Los pasos mostrados fueron probados en Linux, pero no deberían variar demasiado en otros sistemas operativos.

10.4.2 Instalar SDK WebWorks para BB10

Existe un paquete de software que agiliza la instalación del SDK y componentes necesarios para la compilación y emulación de aplicaciones BB10. Se lo conoce como “BlackBerry 10 WebWorks SDK”. El mismo puede descargarse desde la página siguiente: “https://developer.blackberry.com/html5/download/”. Una vez descargado el paquete, se procede a instalar el mismo desde la consola como se muestra a continuación:

$>chmod u+x BB10-WebWorks-SDK_2.0.0.71.bin $>./BB10-WebWorks-SDK_2.0.0.71.bin Como la herramienta WebWorks crea algunas variables de entorno, para que estos cambios surtan efecto, se recomienda el cierre y reapertura de la sesión de usuario.

10.4.3 Instalar la máquina virtual de BB10

Posteriormente procederemos a la instalación de la máquina virtual de BB10, descargando previamente el instalador desde: “https://developer.blackberry.com/html5/download/”. Para instalar la máquina virtual de BB10 descargada ejecutaremos los siguientes comandos:



$>chmod u+x BlackBerry10Simulator-Installer-BB10_2_1-1925-Linux-201312191822.bin $>./BlackBerry10Simulator-Installer-BB10_2_1-1925-Linux-201312191822.bin

10.4.4 Instalar software de virtualización

Para poder correr la máquina virtual instalada en el paso anterior, descargaremos el software “VMware Player” desde el sitio: “https://my.vmware.com/web/vmware/downloads”. Posteriormente, la instalaremos mediante los comandos siguientes:

$>chmod u+x VMware-Player-6.0.1-1379776.i386.bundle $>sudo ./VMware-Player-6.0.1-1379776.i386.bundle

10.4.5 Configurar y ejecutar la máquina virtual

Procederemos ahora a abrir el software VMware Player y, mediante la opción “open” , buscaremos el simulador instalado. Antes de poner a correr el mismo, se recuerda que se deben setear al menos 1.5Gb de memoria.

10.4.6 Creación de la plataforma BB10

Luego de haber configurado las herramientas anteriores, se puede proceder a instalar la plataforma correspondiente a BB10. Recordamos al lector que estamos utilizando el mismo proyecto que usamos para crear la aplicación sobre Android. Por ende todo lo referido al código fuente, plugins y configuraciones ya está disponible. El comando para instalar la nueva plataforma es el siguiente:

$>cordova platform add blackberry10

10.4.7 Compilación de la aplicación a BB10

Antes de poder instalar la aplicación en la máquina virtual, se debe compilar la misma a la plataforma BB10. Esto se hace mediante el siguiente comando:

$>cordova compile blackberry10

10.4.8 Instalar la aplicación en el emulador

Para poder instalar la aplicación en la máquina virtual, previamente, debemos habilitar el “Development Mode” (modo desarrollo) ya que de otra manera, no nos permitirá desplegar la



aplicación en el emulador. Para habilitar esta configuración debemos ingresar en la siguiente opción:

“Settings->Security and Privacy->Development Mode”.

Dentro de esta pantalla encontraremos un pequeño switch que nos permitirá habilitar el modo desarrollo. Ilustramos lo comentado en la figura 10.20.

Fig. 10.20 – Detalle de configuración en modo desarrollo para emulador BB10

Es probable que al habilitar este modo, sea solicitada una contraseña de al menos cuatro caracteres. Debemos ingresar la misma dos veces y es muy importante que no la olvidemos, ya que la utilizaremos posteriormente en la instalación de la aplicación,

Ya habilitada la opción de desarrollo, sólo debemos tener en cuenta un detalle más. La máquina virtual posee una dirección IP, tomaremos nota de la misma para hacer uso de ella más adelante. La misma se encuentra en la parte inferior izquierda del emulador, tal como se muestra en la figura 10.21:

Fig. 10.21 – IP de la máquina virtual BB10



Ya estamos en condiciones de instalar la aplicación en la máquina virtual.ejecutaremos el siguiente comando desde la carpeta raíz de nuestro proyecto PhoneGap:

$>blackberry-deploy -installApp platforms/blackberry10/build/simulator/digitalhc.bar

Donde:

• password: Es la contraseña ingresada al habilitar el modo desarrollo.• device: Es la IP del dispositivo virtual de destino, visto en la figura 10.21.

• package: Es el camino al paquete de instalación

10.4.9 Emulación de la aplica

Una vez desplegado el comando de instalación, ya podemos observar el icono de la aplicación “DigitalHC” en el emulador de

Fig. 10.22 – Detalle del icono de la aplicación

Al proceder con la apertura de la aplicación nos encontramos con una visual muy parecida a la vista en las plataformas anteriores. Este hecho queda plasmado en la figura 10.23:

Fig. 10.23 – Vista rápida de los tres puntos de menú de la aplicación


Chavez Alexis David

Ya estamos en condiciones de instalar la aplicación en la máquina virtual.ejecutaremos el siguiente comando desde la carpeta raíz de nuestro proyecto PhoneGap:

installApp -password pass -device 192.168.199.135 platforms/blackberry10/build/simulator/digitalhc.bar

Es la contraseña ingresada al habilitar el modo desarrollo. Es la IP del dispositivo virtual de destino, visto en la figura 10.21.

Es el camino al paquete de instalación BB10 dentro de la carpeta

de la aplicación

Una vez desplegado el comando de instalación, ya podemos observar el icono de la en el emulador de BB10, igual que en la figura 10.22:

Detalle del icono de la aplicación “DigitalHC” instalada

apertura de la aplicación nos encontramos con una visual muy parecida a la vista en las plataformas anteriores. Este hecho queda plasmado en la figura 10.23:

Vista rápida de los tres puntos de menú de la aplicación “DigitalHC”


Pág. 236

Ya estamos en condiciones de instalar la aplicación en la máquina virtual. A tal efecto ejecutaremos el siguiente comando desde la carpeta raíz de nuestro proyecto PhoneGap:

device 192.168.199.135 -package

Es la IP del dispositivo virtual de destino, visto en la figura 10.21.

dentro de la carpeta “platform”

Una vez desplegado el comando de instalación, ya podemos observar el icono de la , igual que en la figura 10.22:

instalada

apertura de la aplicación nos encontramos con una visual muy parecida a la vista en las plataformas anteriores. Este hecho queda plasmado en la figura 10.23:

“DigitalHC” en BB10



Cambios en la apariencia

Los cambios más evidentes que pudieron observarse en la interfaz gráfica sobre la plataforma BB10 respecto de las anteriormente vistas, fueron en las listas y combos (al igual que iOS). Como ya sabemos, esta apque corra la aplicación. En la figura 10.24 se muestra lo comentado.

Fig. 10.24 – Detalle de un combo y una lista ( izquierda a derecha) con el aspecto típico de

Reportes gráficos y PDF

Pudimos constatar que tanto los gráficos estadísticos, como el reporte correctamente, como lo muestra la figura 1de los cuadros de dialogo, de manera automática al igual que en las otras plataformas.

Fig. 10.25 – Gráfico estadístico y reporte


Chavez Alexis David

Los cambios más evidentes que pudieron observarse en la interfaz gráfica sobre la respecto de las anteriormente vistas, fueron en las listas y combos (al igual que

). Como ya sabemos, esta apariencia cambia de manera automática según la plataforma en la que corra la aplicación. En la figura 10.24 se muestra lo comentado.

Detalle de un combo y una lista ( izquierda a derecha) con el aspecto típico de

Pudimos constatar que tanto los gráficos estadísticos, como el reporte correctamente, como lo muestra la figura 10.25. Se puede observar que ha cambiado la apariencia de los cuadros de dialogo, de manera automática al igual que en las otras plataformas.

Gráfico estadístico y reporte PDF (de izquierda a derecha)


Pág. 237

Los cambios más evidentes que pudieron observarse en la interfaz gráfica sobre la respecto de las anteriormente vistas, fueron en las listas y combos (al igual que

ariencia cambia de manera automática según la plataforma en la

Detalle de un combo y una lista ( izquierda a derecha) con el aspecto típico de BB10

Pudimos constatar que tanto los gráficos estadísticos, como el reporte PDF, se realizaron 0.25. Se puede observar que ha cambiado la apariencia

de los cuadros de dialogo, de manera automática al igual que en las otras plataformas.

(de izquierda a derecha)



Captura de imágenes

A diferencia del emulador de imágenes mediante la simulación de una cámara fotográfica, que captura una serie de barras de colores en movimiento, tal y como se muestra en la figura 10.26.

Fig. 10.26 – Emulador de cámara y captura de una imagen para un paciente

Reporte de coordenadas

Al igual que con el emulador de fue capaz de enviar los datos necesarios al servidor ubicación del mismo (un valor de prueba) y el identificador de dispositivo.


Chavez Alexis David

A diferencia del emulador de iOS, la máquina virtual de BB10, sí permite la captura de imágenes mediante la simulación de una cámara fotográfica, que captura una serie de barras de colores en movimiento, tal y como se muestra en la figura 10.26.

Emulador de cámara y captura de una imagen para un paciente

Al igual que con el emulador de iOS, se pudo comprobar que el dispositivo virtual de fue capaz de enviar los datos necesarios al servidor PHP, entre los cuales se encontraban: la ubicación del mismo (un valor de prueba) y el identificador de dispositivo.


Pág. 238

, sí permite la captura de imágenes mediante la simulación de una cámara fotográfica, que captura una serie de barras de

Emulador de cámara y captura de una imagen para un paciente

pudo comprobar que el dispositivo virtual de BB10 , entre los cuales se encontraban: la



10.5 Resultados finales

10.5.1 Líneas de código empleadas

En esta sección presentaremos algunos de los resultados finales, obtenidos luego de haber desarrollado la aplicación “DigitalHC” . Para comenzar, mostraremos un indicador clásico en desarrollo de software, referido a las líneas de código de la aplicación. En la tabla 10.3 se pueden observar los distintos códigos fuentes, estratificados por lenguaje, con el detalle de líneas de código escritas, los subtotales, así como el total general.

Tabla 10.3 – Líneas de código de la aplicación “DigitalHC” por archivo, lenguaje y en total

Lenguaje Archivo Nº de lineas

ABM_generico.css 50

comun.css 255

configuracion.css 4

consultas.css 13

CSS index.css 59

pacientes.css 56

presentacion.css 13

reportes.css 26

tablas.css 11

TOTAL 487

ABM_generico.js 286

comun.js 80

configuracion.js 143

consultas.js 461

JavaScript index.js 372

pacientes.js 580

reportes.js 526

tablas.js 81

utiles.js 426

TOTAL 2955

ABM_generico.html 66

configuracion.html 40

consultas.html 183

index.html 71

HTML pacientes.html 164

presentacion.html 14

reportes.html 31

tablas.html 35

TOTAL 604

TOTAL GENERAL 4046



10.5.2 Plugins de la API de PhoneGap utilizados

� Emisión de vibración (org.apache.cordova.vibration) � Manejo de diálogos (org.apache.cordova.dialogs) � Manejo del GPS (org.apache.cordova.geolocation) � Obtención de datos del dispositivo (org.apache.cordova.device) � Manejo del sistema de archivos (org.apache.cordova.file) � Manejo de la cámara (org.apache.cordova.camera)

10.5.3 Plugins JavaScript utilizados

� jquery-2.1.0.min.js � highcharts.js � jquery.bpopup.min.js � jQuery.fastClick.js � jquery.touch.min.js � jspdf.min.js:

10.5.4 Plugins CSS utilizados

� topcoat-mobile-light.min.css

10.5.5 Tiempo estimado de desarrollo

El lapso transcurrido desde que se comenzó la aplicación, hasta su finalización, es de aproximadamente seis (6) meses. El cálculo comprende tanto la recolección de requisitos, como el diseño y creación de la base de datos, así como de la aplicación en sí misma. Cabe destacar que se incluye dentro de la franja temporal nombrada, el tiempo insumido en las pruebas y experimentación con la herramienta PhoneGap, como así también, el consumido testeando los diversos plugins agregados.



10.6 Conclusiones

Para culminar y comenzar a cerrar lo que ha sido todo el trabajo realizado, tanto teórico como práctico, brindaremos nuestra opinión y conclusiones. Desde ya aclaramos que las mismas se han basado en nuestra experiencia personal, siempre tratando de ser lo menos subjetivos posible, contrastando la realidad con los objetivos y premisas planteadas.

Curva de aprendizaje achatada

Uno de los ítems que planteamos al comienzo de la Tesina consistió en poder encontrar una herramienta que nos permitiera mejorar la capacidad de desarrollo, sin tener que invertir tanto tiempo en conocerla y entenderla. Esto ha sido cierto desde un punto de vista. Si bien la aplicación desarrollada llevó unos seis meses hasta su correcto funcionamiento, para ser una herramienta que nunca habíamos utilizado, no podemos decir que fue tanto el tiempo insumido. En posteriores desarrollos es muy probable que la velocidad de producción pueda ser doblada o triplicada, dado que muchos aspectos inciertos o desconocidos han sido cubiertos.

Por otra parte, debemos admitir que ya contábamos con conocimientos previos, referidos a las tecnologías webs básicas (HTML, JavaScript, CSS). Esto amortiguó en gran medida la cantidad de tiempo requerida para el desarrollo. De no haber contado con esas nociones previas, seguramente el mismo se hubiera dilatado considerablemente. Es por esto que la curva puede no resultar tan achatada, dependiendo esto finalmente, de los conocimientos en tecnologías web con los que se cuente.

Aplicaciones multiplataforma

Desde un principio del desarrollo, planteamos el diseño, codificación y pruebas sobre la plataforma Android, por los motivos que en su momento se enunciaron. En el presente capítulo mostramos experiencias (mediante emuladores) en otras plataformas, BlackBerry e iOS, para ser más exactos. Los resultados obtenidos fueron muy positivos y no se descarta, a futuro, poder implementar una aplicación en dispositivos reales sobre dichas plataformas y otras también.

Uso completo y eficiente del hardware

Respecto al uso del hardware del dispositivo, podemos decir que PhoneGap, mediante los plugins de su API, permite controlar la mayoría de los aspectos en lo referido al mismo. Quedaron en el tintero algunas cosas por probar, como ser: el manejo de archivos multimedia (sonido, video) o el navegador incrustado (“InAppBrowser” ). Pero todo aquello que sí fue utilizado y finalmente implementado en la aplicación “DigitalHC” , nos ha dejado más que conformes.

Respecto a la eficiencia, al haber más capas de software entre la aplicación y el hardware del dispositivo (el puente de PhoneGap), es probable que la performance baje un poco. Pero a medida que los dispositivos van en aumento de sus capacidades vemos cómo esa deficiencia se va achicando.



Debe ser de uso libre

Sin lugar a dudas, una de los principales desafíos que los desarrolladores enfrentamos a la hora de emprender un proyecto de software, es el de poder valernos de la utilización de herramientas “libres” para dar respuesta al mismo. A nuestro criterio, este uno de los puntos clave, el cual no sólo hemos cumplido gracias a la característica intrínseca de PhoneGap de ser libre, si no a su integración con otras plataformas/herramientas con la misma filosofía. Por lo tanto, respecto a este ítem, podemos decir que está más que cubierto.

Contar con una comunidad “fuerte” de usuarios

Sin lugar a dudas este es otro punto fuerte de PhoneGap, el cual, a pesar de ser una herramienta nueva, cuenta con amplia difusión y soporte en la comunidad desarrolladora de todo el mundo. Cabe destacar un rasgo interesante: a diferencia de otras tecnologías, cuenta con una gran comunidad de habla hispana, con información y ejemplos bastante vigentes. Esta característica contribuyó en gran medida en poder achatar la curva de aprendizaje de esta herramienta.

Debe aprovechar el uso de las nuevas tecnologías web.

Es muy interesante la manera en que las mejoras introducidas mediante HTML5 y CSS3, son aprovechadas por esta herramienta. Las cuales por supuesto, pueden ser utilizadas en otros desarrollos y con otras tecnologías, ya sean híbridas o web puras. Por lo tanto podemos decir que PhoneGap permite utilizar para nuestro provecho, todas esas nuevas mejoras, facilitando así el diseño y desarrollo de aplicaciones para dispositivos móviles.

Debe favorecer el desarrollo de aplicaciones del tipo contable

Cuando planteamos este requisito, lo hicimos pensando en poder dar con una herramienta de uso y aplicación en el ámbito del desarrollo empresarial. La misma debía facilitar el diseño de aplicaciones que permitieran: ordenar, almacenar y manipular información desde dispositivos móviles o, como nombramos en el título de la Tesina, del tipo handheld. PhoneGap cumple también con este requisito, dado que está basado en lenguajes web, los cuales son multipropósito, y permiten perfectamente cumplir con el cometido. Por supuesto hay algunas aplicaciones para las que no es tan recomendable, este punto es tratado mas abajo.

Pros, contras y ámbitos de uso de PhoneGap

Las ventajas y desventajas de este framework ya habían sido estudiadas a nivel teórico en el capítulo denominado “Explorando el estado del arte”. En este caso, expondremos las más sobresalientes a nuestro criterio, obtenidas luego de haber tenido una experiencia de primera mano con la herramienta. Luego listaremos cuáles son los ámbitos o temáticas de aplicación más comunes y recomendables para PhoneGap, así como en donde es preferible no utilizarlo, o bien, hacerlo a sabiendas de que no es la aplicación a la que más fácilmente se adapta.



Pros

• Es de uso libre y de código abierto.

• Usa lenguajes genéricos, no privativos de cada plataforma.

• Posee una amplia comunidad de desarrollo y amplia documentación.

• Favorece el desarrollo multiplataforma.

• Permite reutilizar el código base para varias plataformas, con menor impacto de modificaciones.

• Se requiere menos habilidades de implementación sobre aplicaciones para móviles dentro del equipo de desarrollo.

• Potente interfaz de línea de comandos para gestionar la creación de aplicaciones.

Contras

• Algunas características de PhoneGap podrían no estar implementadas en todas las plataformas.

• El rendimiento final generalmente es menor que el de una aplicación nativa.

• Complejidad cuando se debe realizar una implementación nativa por una funcionalidad no disponible para determinada plataforma.

• Potenciales problemas de compatibilidad a nivel visual entre diferentes plataformas.

• Bajo rendimiento en cuanto a exigencias gráficas.

• Dificultad para lograr portabilidad.

Ámbitos naturales de uso

• Aplicaciones utilitarias (por ejemplo: una agenda personal). • Encuestas.

• Redes sociales. • Publicidad. • Adaptación de aplicaciones web.

• Aplicaciones que usen sensores (brújula, GPS) • Aplicaciones que envíen y/o reciban datos de un servidor externo.

Ámbitos no recomendables de uso

• Aplicaciones que requieran uso intensivo de la GPU. • Aplicaciones de tiempo real crítico (tiempo real duro).

• Aplicaciones que usen y/o manipulen un volumen de datos muy grande.

• Juegos complejos.

• Aplicaciones que requieran hacer uso directo de llamadas o propiedades del sistema operativo (por ejemplo: optimizadores de memoria).



10.7 Trabajos futuros

Uno de los asuntos pendientes de esta tesina que por motivos económicos no pudo ser cumplido, es la instalación y prueba de la aplicación desarrollada, en dispositivos físicos que usen plataformas diferentes a Android, tales como BlackBerry, iOS, Windows Phone o Firefox OS, por nombrar algunos. Además quedó en el tintero la instalación y configuración de la herramienta PhoneGap en el entorno Windows, dado que en esta ocasión, sólo fueron utilizadas las plataformas Linux y Mac OS X.

Con respecto a aspectos más específicos, se dejó para futuras implementaciones, la utilización de otros medios de persistencia de datos, dado que sólo utilizamos WebSQL, dejando de lado otras opciones como por ejemplo: IndexedDB o WebStorage, entre otros. También se prevé la utilización de otros plugins de la API de PhoneGap, que aunque no fueron requeridos en la actual implementación realizada, no se descarta su utilización en posteriores proyectos

Con respecto a la aplicación “DigitalHC” , queda pendiente su adaptación para resolver la necesidad de algún grupo de usuarios que la requiera, confiando plenamente en que la misma puede lograr ese fin perfectamente. Además también se pretende en algún momento poder publicar esta aplicación en las tiendas oficiales, tema que sólo fue tratado en la teoría pero que queda por ser probado empíricamente.

En relación con las tecnologías que rodearon al desarrollo con PhoneGap, no podemos dejar de nombrar a node, herramienta que es requisito para interactuar con el framework, pero que trae consigo todo un cambio en lo referente a la programación de servidores web y que amerita un estudio complejo e interesante del tema. Si de tecnologías web hablamos, podemos nombrar también algunas mejoras interesantes de HTML5 que despertaron nuestro interés, tales como “canvas” o el concepto de “WebSocket”, pero que por razones de tiempo no fueron abordadas en esta ocasión.

Para concluir con esta sección y resumiendo un poco lo antes expresado, la mayor de las tareas que quedará pendiente a futuro, es la realización de más proyectos para dispositivos móviles con la ayuda de esta valiosa herramienta.



10.8 Reflexión final

A lo largo del desarrollo de esta Tesina hemos estudiado y adquirido una gran cantidad de conceptos. Inicialmente sólo buscábamos dar con una herramienta para el desarrollo de aplicaciones para dispositivos móviles, pero terminamos atesorando muchas cosas más. Uno de los conceptos más interesantes que vimos fueron los tres paradigmas existentes para la generación de aplicaciones (híbrido, web y nativo).

También pudimos afianzar los conocimientos web previos, agregando a los mismos muchas de las nuevas características provistas por HTML5 y CSS3. En referencia a estas tecnologías, también pudimos explorar un poco el basto mundo de los plugins y librerías JavaScript, muchos de los cuales permitieron la realización de nuestra aplicación.

Hablando ahora un poco en referencia al tema central de este trabajo, PhoneGap, podemos decir muchas cosas. Si bien ya hemos enunciado, líneas atrás, varias apreciaciones personales, queremos volcar una opinión final al respecto. Podemos decir sin miedo a equivocarnos que la balanza ha quedado equilibrada a favor del framework. Ha cumplido en general con todo lo que prometió que haría. En un principio, costó bastante encontrar el punto de arranque para comenzar a hacer “girar la rueda”. Una de las cosas que más complicó la historia, fue haber empezado a usar la herramienta en pleno cambio de arquitectura, dado que los primeros meses de uso estábamos con la versión 2.x, y, en poco tiempo nos encontramos adaptándonos a la versión tres que era liberada.

Pasando a otro aspecto importante, un factor inherente a la programación para dispositivos móviles y que también fue sufrido en este desarrollo, son los largos tiempos de espera en la re compilación y emulación de las aplicaciones. En este sentido, PhoneGap permitió probar nuestra aplicación mediante otros métodos, como por ejemplo por medio de Google Chrome, lo cual redujo dramáticamente los tiempos antes nombrados. Por supuesto que por la naturaleza de la aplicación realizada, no se pudo prescindir del emulador y/o un dispositivo físico para realizar ciertas pruebas de algunas funcionalidades.

Finalmente podemos decir que recomendamos ampliamente el uso de PhoneGap, no porque sea una herramienta infalible o porque otra opción no sea mejor. Consideramos que es una puerta a un nuevo mundo, a otra forma de programar aplicaciones para dispositivos móviles. Hemos descubierto un nuevo paradigma llamado “Híbrido” , el cual se presenta como el futuro de la programación, ganando terreno en el contexto de las aplicaciones empresariales día a día. Luego de nuestra experiencia personal y por todo lo expuesto, podemos decir que PhoneGap es una buena manera de empezar a meterse en el basto universo de las aplicaciones para dispositivos handheld.



Glosario

Ansca: Es la compañía detrás del framework Corona.

Apache ANT: (Another Neat Tool), otra ingeniosa herramienta. Es una utilidad creada para la realización de tareas mecánicas y repetitivas, normalmente durante la fase de compilación y construcción (build). Es, por tanto, un software para procesos de automatización de compilación, desarrollado en lenguaje Java y requiere la plataforma Java, particularmente apropiado para la construcción de proyectos Java.

API: (Application Programming Interface), interfaz de programación de aplicaciones, es el conjunto de funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción.

APK: Acrónimo formado a partir de la frase inglesa “Aplication Package”. Es un paquete para el sistema operativo Android y se usa para distribuir e instalar componentes empaquetados para esa plataforma.

Aplicación híbrida: Consiste en un software desarrollado en lenguaje web y empaquetado mediante algún método o herramienta, para ser instalado de manera nativa en una o más plataformas diferentes.

Aplicación móvil: Se dice de las aplicaciones desarrolladas para ser instaladas y ejecutadas en algún dispositivo handheld.

Aplicación nativa: Se refiere a las aplicaciones desarrolladas en el mismo lenguaje que interpreta la plataforma donde la misma será instalada.

Aplicación web: Todas aquellas aplicaciones que se ejecuten desde Internet o localmente, desarrolladas en lenguaje web que y son visualizadas mediante un navegador.

Artefactos de diseño PSD: Las plantillas PSD o Mock Up tienden a utilizar Objetos Photoshop Inteligentes (Photoshop Smart Objects) para permitir al usuario modificar el aspecto final manteniendo el diseño

CSS: Acrónimo de la frase inglesa “Cascading Style Sheets” (hojas de estilo en cascada) es un lenguaje de estilo que define la presentación de los documentos HTML.

Deep linking: (enlazar en profundidad), en la web, consiste en hacer un hiperenlace que lleva a una página o imagen específica de otro sitio web, en vez de llevar a la página principal de ese sitio.

Dirección IP: Es una etiqueta numérica que identifica, de manera lógica y jerárquica, a una interfaz (elemento de comunicación/conexión) de un dispositivo dentro de una red que utilice el protocolo IP (Internet Protocol).

Dispositivos handheld: Dícese de los dispositivos “de mano”, en particular artefactos cómo: smartphones, tablets, Ipads, etc.



DOM: (Document Object Model) modelo de objetos del documento, esencialmente una interfaz de programación de aplicaciones (API) que proporciona un conjunto estándar de objetos para representar documentos HTML y XML, un modelo estándar sobre cómo pueden combinarse dichos objetos, y una interfaz estándar para acceder a ellos y manipularlos.

Fórmula Haversine: Conocida también como fórmula del semiverseno. Es una importante ecuación para la navegación astronómica, en cuanto al cálculo distancia de círculo máximo entre dos puntos de un globo sabiendo su longitud y latitud.

Framework: Conjunto estandarizado de conceptos, prácticas y criterios para hacer frente a un tipo común de problema, que puede ser usado para ayudarnos a resolverlo de forma rápida y eficaz. El objetivo de los frameworks es proporcionar una estructura común, de modo que los desarrolladores no tienen que hacer el código desde cero cada vez y poder volver a utilizar la gran mayoría del mismo.

Feedback: Su significado es el de “retroalimentación”, lo que implica que, ante la transmisión de un mensaje o la ejecución de una acción por parte de un emisor, van a generarse una serie de respuestas o reacciones en el receptor.

GCC: (GNU Compiler Collection) es un compilador integrado del proyecto GNU para C, C++ , Objetive C y Fortran, capaz de recibir un programa fuente en cualquiera de estos lenguajes y generar un programa ejecutable binario en el lenguaje de la máquina donde ha de correr.

GPU: Acrónimo proveniente de la frase en inglés “Graphics Processing Unit” (unidad de procesamiento de gráficos).

Hardware: Todo lo referido a la parte visible de los dispositivos móviles: carcasa, pantalla, memoria, CPU, etc.

Hooks: (Ganchos). Es una carpeta generada automáticamente al crear un proyecto PhoneGap. La misma puede contener scripts con secuencias de comandos que permiten personalizar los comandos de PhoneGap.

Host: Un host es un equipo que está conectado a una red de máquinas y es responsable de la transmisión y almacenamiento de datos.

HTML: (Hiper Text Markup Language) lenguaje de marcado de híper texto, es el lenguaje base para la elaboración y estructuración de páginas web.

IDE: Acrónimo proveniente de la frase en inglés “Integrated Development Environment” (entorno de desarrollo integrado). Es un entorno de programación que ha sido empaquetado como un programa de aplicación, integrando generalmente dentro de sí herramientas como: un editor de código, un compilador, un depurador y un constructor de interfaz gráfica.

JavaScript: Lenguaje de programación que permite a los desarrolladores crear acciones en sus páginas web. No requiere de compilación ya que funciona del lado del cliente, los navegadores son los encargados de interpretar estos códigos.



JSON: (JavaScript Object Notation) notación de objetos JavaScript, es un formato para el intercambio de datos. Básicamente describe los datos con una sintaxis dedicada que se usa para identificar y gestionar los mismos.

Look & feel: (Ver y sentir) es el conjunto de propiedades y características que dan a una interfaz gráfica, una identidad visual única y pueden ser percibidos de manera diferente, de acuerdo con cada usuario.

MB: Megabyte (MB) es una cantidad de datos informáticos. Es un múltiplo del byte u octeto que equivale a 10� B (un millón de bytes).

Media queries: Es un modulo CSS3 que permite adaptar la representación del contenido a características del dispositivo como la resolución de pantalla.

Merge: (Fusión) es una carpeta generada automáticamente al crear un proyecto PhoneGap. La misma permite agregar preferencias diferenciadas a cada plataforma referidas a los estilos (CSS).

Multiplataforma: Capacidad que posee una aplicación para poder ejecutarse en diferentes plataformas de manera transparente.

Node: Intérprete basado en el motor JavaScript V8. Consiste en utilizar JavaScript del lado del servidor. Su meta es permitir a un programador construir aplicaciones altamente escalables y escribir código que maneje decenas de miles de conexiones simultáneas en una sola máquina física.

Notificaciones push: Permiten que la aplicación se ejecute en segundo plano y se active al recibir un mensaje, por ejemplo, “WhatsApp”.

NPM: (Node Packaged Modules) es el gestor de paquetes oficial Node.

Objective-C: Es un lenguaje de programación orientado a objetos creado como un súper conjunto de C para que implementase un modelo de objetos parecido al de Smalltalk. Actualmente se usa como lenguaje principal de programación en Mac OS X, iOS y GNUstep.

Open source: (Código abierto) es la expresión con la que se conoce al software distribuido y desarrollado libremente.

OpenGL-ES: (OpenGL for Embedded Systems) OpenGL para sistemas embebidos. Es una variante simplificada de la API gráfica OpenGL diseñada para dispositivos integrados tales como: teléfonos móviles, PDAs y consolas de video juegos.

Paradigma de programación: Es una propuesta tecnológica que es adoptada por una comunidad de programadores, cuyo núcleo central es incuestionable en cuanto a que únicamente trata de resolver uno o varios problemas, claramente delimitados. Es un estilo de programación empleado.

PNG: (Portable Network Graphics) gráficos de red portátiles, es un formato gráfico basado en un algoritmo de compresión sin pérdida para bitmaps, no sujeto a patentes.

Podcasting: Término que consiste en la distribución de archivos multimedia.



Popup: Ventana emergente que aparece de repente en la pantalla de un dispositivo móvil y de escritorio, tanto en mini ventanas para opciones a elegir como para anuncios de publicidad en la web.

RAM: Acrónimo proveniente de la frase en inglés “Random Access Memory” (memoria de acceso aleatorio). Es la memoria utilizada por los dispositivos para albergar datos y programas en ejecución.

Renderizado: Render en inglés, es un término usado en la jerga informática para referirse al proceso de generar una imagen desde un modelo. Es muy utilizado por programas de diseño 3D.

Responsive web design: También llamado, diseño web adaptativo, es la técnica que se usa en la actualidad para tener una misma web adaptada a las diferentes plataformas y dispositivos. Consiste en una serie de hojas de estilo en CSS3 que usando el atributo “media queries”, convierten una web ordinaria en una web multiplataforma capaz de adaptarse a todos los tamaños de pantalla que existen.

SDK: Acrónimo proveniente de la frase en inglés “Software Development Kit” (kit de desarrollo de software). Consiste en un conjunto de herramientas que le permiten al programador crear aplicaciones para un sistema concreto.

SEO: (Search Engine Optimization) posicionamiento en buscadores. Es un conjunto de acciones que ayudan a mejorar la visibilidad de un sitio web en los resultados de búsqueda de los diferentes buscadores.

Servicio JSONP: JSONP es el acrónimo de “JavaScript Object Notation with Padding”, es decir, una forma de extensión de JSON para soportar llamadas entre dominios.

Software: Conjunto formado por: el sistema operativo y diferentes programas que se ejecutan en el dispositivo móvil y permiten la operación del mismo.

Sprites: Permiten agrupar todos los archivos de imagen de una aplicación en una sola y, mediante código CSS, seleccionar que parte de la imagen mostrar, ahorrando así la carga de múltiples imágenes.

W3C: (World Wide Web Consortium) es una organización o consorcio que rige los estándares y recomendaciones para el desarrollo de la Web.

Web app: Es una aplicación ejecutada desde el navegador web de un dispositivo móvil.

Web semántica: La web semántica es una Web extendida, dotada de mayor significado, en la que cualquier usuario en internet podrá encontrar respuestas a sus preguntas de forma más rápida y sencilla gracias a una información mejor definida.

Webkit: Es un framework para el desarrollo de aplicaciones que funciona como base para el navegador web Safari, Google Chrome, Epiphany, Midori entre otros. Está basado originalmente en el motor de renderizado KHTML del navegador web del proyecto KDE denominado Konqueror.



Widget: Es una pequeña aplicación que se puede instalar en un blog, red social favorita o descargarse, permitiendo recibir contenidos en formato texto, en imágenes, audio o vídeos.

XML: (eXtensible Markup Language) lenguaje de marcas extensible, desarrollado por la W3C, utilizado para almacenar datos en forma legible. Permite definir la gramática de lenguajes específicos para estructurar documentos grandes.



Bibliografía

Sitios Web:

• http://phonegap.com

• http://docs.phonegap.com

• http://cordova.apache.org

• http://jquery.com

• http://jquerymobile.com

• http://topcoat.io

• http://www.w3schools.com

• http://www.phonegapspain.com

• http://www.w3.org/TR/mwabp/

• http://stackoverflow.com

• http://developer.blackberry.com

• http://parall.ax/products/jspdf

• http://dinbror.dk/bpopup

• http://www.highcharts.com

• https://github.com/n33/jquery.touch

• https://github.com/ftlabs/fastclick

• http://www.wikipedia.org

• https://www.youtube.com

• http://developer.android.com

Libros:

• RohitGhatol | Yogesh Patel: Beginning PhoneGap Mobile web Framework for JavaScript and HTML5. APRESS 2012.

• John M. Wargo: PhoneGap Essentials Bulding Cross-Platform Mobile Apps. PEARSON EDUCATION INC 2012.

• John M. Wargo: PhoneGap Aache Cordoba 3 Programming. ADDISON-WESLEYNC 2013.

• Matt Gifford: PhoneGap Mobile Application Development Cookbook. Packt Publishing 2012.



• Juan Diego Gauchat: El gran libro de HTML5, CSS3 y JavaScript. MARCOMBO S.A 2012.

• David Sawyer Mcfarland: JavaScript & jQuery – The Missing Manual. O´REILLY second edition, Octubre 2011.

• Luc Van Lancker: Los API JavaScript de HTML5. ENI EDICIONES 2013

• Benjamin LaGrone: HTML5 and CSS3 Responsive Web Design Cookbook. PACKT PUBLISHING 2013.

• Martin Georgiev, Suman Jana, Vitaly Shmatikov: Breaking and Fixing Origin-Based Access Control in Hybrid Web/Mobile Application Frameworks. THE UNIVERSITY OF TEXAS AT AUSTIN 2014