análisis post mortem del pfc 'sistema de … · de 160kb de rom[6] [7]y 32kb de ram), que...

David Contreras Magaña

Análisis post mortem del PFC "Sistema de comunicaciones entre dispositivos inalámbricos:

conclusiones para buenas prácticas en el desarrollo deaplicaciones móviles

Eloy Javier Mata Sotés

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Grado en Ingeniería Informática

2012-2013

Título

Autor/es

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE GRADO

Curso Académico

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2013

publicaciones.unirioja.esE-mail: [email protected]

Análisis post mortem del PFC "Sistema de comunicaciones entre dispositivos inalámbricos: conclusiones para buenas prácticas en el desarrollo de

aplicaciones móviles, trabajo fin de gradode David Contreras Magaña, dirigido por Eloy Javier Mata Sotés (publicado por la

Universidad de La Rioja), se difunde bajo una LicenciaCreative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.

Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los titulares del copyright.

Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”

2

Agradecimientos: A Óscar, Jesús y Ramón por apoyarme siempre en lo que fue esta aventura.


3


4

Índice de contenidos Agradecimientos: .......................................................................................................................... 2

Índice de contenidos ................................................................................................................... 4

Resumen ........................................................................................................................................ 8

Abstract ....................................................................................................................................... 10

Introducción ................................................................................................................................ 12

Sobre la tecnología empleada ............................................................................................. 12

Sobre la aplicación desarrollada durante el PFC ................................................................. 14

Sobre las aplicaciones desarrolladas durante la fase de explotación ................................. 15

Sobre el sistema de envío de contenidos utilizado ............................................................. 17

1. Fragmentación ....................................................................................................................... 20

1.1. Tamaños de pantalla y formatos. Alternativas y soluciones .......................................... 22

1.2. Capacidad de proceso, terminales y soluciones de compromiso .................................. 25

1.3. Identificación de terminales desde un emisor Bluetooth .............................................. 27

1.4. Identificación de terminales en tiempo de ejecución .................................................... 29

1.5. Interfaz de usuario y usabilidad ..................................................................................... 31

2. Seguridad en JavaME ............................................................................................................. 34

2.1 Firma digital de aplicaciones: ventajas y limitaciones.................................................... 35

Sin embargo... ..................................................................................................................... 35

2.2 Suplantación de la identidad del desarrollador ............................................................. 36

Parte I: La solución más simple que puede funcionar......................................................... 36

Parte II: El señuelo ............................................................................................................... 37

Parte III: La solución real y la violación del segundo principio de Kerckhoffs ..................... 37

2.3 Robo de contenidos: extracción de código y recursos ................................................... 39

2.4 Modificación no autorizada de contenidos .................................................................... 41

3 Optimización .......................................................................................................................... 42

3.1 Gráficos: estrategias que siguen funcionando hoy en día ............................................. 43

3.2 Algoritmos, operaciones a bajo nivel, y buenas prácticas ............................................. 45

3.3 Arquitectura de aplicaciones y escalabilidad ................................................................. 46

4 Monetización de aplicaciones ................................................................................................ 48

4.1 App Stores ...................................................................................................................... 49

4.2 SMSs Premium o de tarificación adicional ..................................................................... 50

4.3 Programación Cross-Platform ........................................................................................ 53


5

5 Conclusiones .......................................................................................................................... 56

5.1 Breve análisis del ecosistema de desarrollo móvil ......................................................... 57

5.2 ¿Qué plataforma elegir? ................................................................................................. 58

5.3 Júpiter y más allá del infinito .......................................................................................... 60

6 Bibliografía ............................................................................................................................. 62

7 Glosario de términos .............................................................................................................. 64

Anexo A: Actas de reunión .......................................................................................................... 74


6

Índice de figuras Figura 1: Netbeans y emulador JavaME................................................................................. Figuras 2, 3 y 4: Aplicación Bluetooth Finder......................................................................... Figuras 5, 6 y 7: Aplicación Bluetooth Finder......................................................................... Figuras 8, 9 y 10: Metro Madrid (17.000 descargas en Softonic).......................................... Figuras 11, 12 y 13: Ejemplo de guía turística (“Laboral ciudad de la cultura”).................... Figuras 14, 15 y 16: Aplicación Montaña Central.................................................................. Figuras 17 y 18: Aplicación Layar........................................................................................... Figura 19: Emisor Bluetooth Bluegiga 2293 ext..................................................................... Figura 20: Dispositivos para pruebas..................................................................................... Figura 21: Código de visualización de imágenes.................................................................... Figuras 22, 23 y 24: Formatos de portada............................................................................. Figuras 25, 26 y 27: Secuencia de portadas........................................................................... Figura 28: Código de cálculo de costes.................................................................................. Figura 29: Base de datos de dispositivos............................................................................... Figura 30: Código de identificación de terminal.................................................................... Figura 31: Código de identificación de Softkeys.................................................................... Figuras 32, 33 y 34: Interfaz en alto nivel.............................................................................. Figura 35: Código de verificación de seguridad (I)................................................................. Figura 36: Código de verificación de seguridad (II)................................................................ Figura 37: Código de verificación de seguridad (III)............................................................... Figura 38: Código de verificación de color............................................................................. Figura 39: Profiler en Netbeans............................................................................................. Figura 40: Opciones en PngGauntlet..................................................................................... Figuras 41, 42, 43 y 44: Secciones de mapa...........................................................................

13

14

14

15

15

16

16

17

20

22

23

25

26

27

30

30

32

36

37

37

41

42

43

44


7

Figura 45: Código control de estados.................................................................................... Figura 46: Código de Factory Method y Abstract Factory..................................................... Figuras 47, 48 y 49: Aplicación SMS Premium Mercedes...................................................... Figuras 50, 51 y 52: Aplicación SMS Premium GaÏnde........................................................... Figuras 53, 54 y 55: Aplicación SMS Tinforma....................................................................... Figuras 56, 57 y 58: Aplicación SMS Cita previa..................................................................... Figura 59: Prensa................................................................................................................... Figura 60: Plataformas de desarrollo..................................................................................... Figura 61: Características de cada plataforma....................................................................... Figuras 62 y 63: Geolocalización y búsqueda en Realidad Aumentada................................. Figuras 64 y 65: Información nutricional y texto para sordos en Realidad Aumentada........

46

47

50

51

51

52

54

57

59

60

60


8

Resumen

En Marzo de 2006 bajo la dirección de Dr. Juan Félix San Juan Díaz, defendí el Proyecto Fin de

Carrera “Sistema de comunicaciones entre dispositivos inalámbricos”. Un proyecto que tuvo

como entregables, entre otros, una aplicación para dispositivos móviles desarrollada con

tecnología JavaME (Java Micro Edition).

Lo particular de la tecnología empleada y la novedad del ámbito de desarrollo, me permitieron

encontrar un puesto de trabajo en una empresa privada donde, usando ese proyecto como

base, se desarrollaron hasta 2011 más de noventa proyectos adicionales dentro del ámbito del

Mobile Marketing[1].

Durante ese tiempo, se pusieron a prueba en escenarios de despliegue reales las soluciones

implementadas durante el desarrollo de ese proyecto académico, encontrándose multitud de

supuestos no previstos, problemas de diseño, escalabilidad, seguridad y un largo etcétera.

Este Trabajo Fin de Grado, toma como “proyecto” el periodo comprendido tanto en la fase

académica como en la empresarial (2006 - 2011), para crear a partir de él un catálogo de

problemas encontrados, análisis de las soluciones disponibles y justificaciones de las

finalmente implementadas.

Un documento con lecciones tecnológicamente agnósticas, pero con claras referencias a

nuevas plataformas como iOS[2] y Android[3], que sirva de ayuda a futuros desarrolladores de

aplicaciones para dispositivos móviles.

Palabras clave: JavaME, iOS, Android


9


10

Abstract

In March 2006, I defended the Project entitled “Communication system between wireless

devices”, which was elaborated under the supervision of Dr. Juan Félix San Juan Díaz. This

project had several deliverables, a mobile application developed with JavaME (Java Micro

Edition) technology, among others.

The peculiarity of the used technology and the novelty of the development field, allowed me

to find a job in a private company where, using that as a base project, we developed more

than ninety additional projects within the scope of Mobile Marketing until 2011.

During that time a variety of deployed solutions developed in this project were tested in real

deployment scenarios, encountering many assumptions which had not been foreseen, as well

as design, scalability and security problems.

This Final Project takes as a "project" both, the academic and the business phases (2006 -

2011), to create a catalogue of encountered problems, an analysis of available solutions and

justifications to be implemented.

This document provides technologically agnostic lessons, but clear references to new

platforms like iOS and Android, which are certainly helpful to future mobile phone developers.

Keywords: JavaME, iOS, Android.


11


12

Introducción

El proceso de análisis post mortem de un proyecto suele iniciarse idealmente después de

concluir éste y con independencia del éxito o fracaso del mismo. Debe recoger tanto aquellas

cosas que fueron bien como las que fueron mal, puesto que los seres humanos tendemos a

descartar los malos recuerdos y a quedarnos sólo con los buenos.

Puede no ser un proceso placentero, la autocrítica sincera nunca lo es, pero ayuda a aprender

de nuestros aciertos y errores pasados, pudiendo ser una herramienta muy útil para nuestros

proyectos futuros.

En el caso concreto de esta memoria, ha sido reconfortante analizar y poner en claro algunas

de las decisiones tomadas durante los últimos años y repensar los procesos de desarrollo y

explotación de Software que durante ese tiempo se produjeron.

Estructurada en cinco apartados recoge algunas de esas decisiones, abarcando temas como el

desarrollo para un ecosistema fragmentado, seguridad o distribución de contenidos,

intentando en cada uno de ellos extraer conclusiones y lecciones que sirvan en escenarios

futuros de desarrollo.

En general enlazar cada caso con plataformas actuales como iOS o Android ha resultado más

fácil de lo que se esperaba, aunque no se ha podido evitar en ocasiones preguntarse si algunos

de los temas analizados pertenecían a la década pasada...o a hace dos.

El desarrollo del escenario móvil ha sido tan brutal y vertiginoso, que todo rastro de la

tecnología analizada en la memoria del proyecto anterior, aun contando con apenas una

década a sus espaldas, ha sido casi completamente borrada del mapa.

Sonroja incluso pensar cómo se hacían las cosas hace apenas cinco años. Exactamente hasta

que Apple,[4] un 9 de Enero de 2007, marcó el punto de inflexión que cambiaría por completo

el mercado. Ese día toda la tecnología sobre la que se trabajó tan duramente durante tantos

años quedó prácticamente obsoleta al instante.

Sobre la tecnología empleada

JavaME es una tecnología desarrollada originalmente por Sun Microsystems[5] a finales de

1999, diseñada para funcionar en dispositivos con fuertes restricciones de memoria (a partir

de 160KB de ROM[6] y 32KB de RAM[7]), que tardó poco tiempo en extenderse al mercado de

los teléfonos móviles donde tuvo bastante éxito en la primera década de este siglo como

plataforma para el desarrollo de aplicaciones y juegos.

Independiente del Hardware[8] subyacente, como en los casos de JavaSE[9] y JavaEE[10], fue

elegida por el alumno como tecnología a emplear para el desarrollo de aplicaciones, entre ellas

la propia del PFC original, en un momento (2005) en el que el mercado estaba totalmente

fragmentado tanto por marcas (Nokia, Samsung, LG, Alcatel, Motorola...) como por modelos

dentro de cada marca.


13

La decisión se demostró acertada con el tiempo, sobre todo en la fase de explotación

comercial, ya que fue la única tecnología que permitió abarcar una amplia cuota de mercado

con relativamente poco desarrollo.

Aparte de JavaME también se barajaron otras alternativas, como C++[11] para Symbian[12], un

entorno que ofrece control total sobre el Hardware del dispositivo, pero compatible sólo con

el 20-30% de la cuota de mercado del momento.

Figura 1: Netbeans y emulador JavaME

Este porcentaje era netamente insuficiente si se analizan el tipo de aplicaciones que se

vendieron durante la fase de trabajo en empresa: Principalmente aplicaciones para el sector

turístico como programas de fiestas o visitas guiadas, donde alcanzar al mayor número de

público objetivo es crítico.


14

Sobre la aplicación desarrollada durante el PFC

A grandes rasgos la aplicación desarrollada con JavaME permitía a un usuario rellenar una

ficha con su perfil personal, almacenarla en su teléfono y buscar de manera automática vía

Bluetooth[13] otros usuarios con un perfil compatible a él.

Figura 2, Figura 3 y Figura 4: Aplicación Bluetooth Finder

Una vez encontrados otros usuarios compatibles, la ficha de contacto quedaba almacenada en

su teléfono, siendo posible además comunicarnos con ellos a través de mensajes de texto

gratuitos vía Bluetooth si se encontraban en el radio de acción del dispositivo.

Figura 5, Figura 6 y Figura 7: Aplicación Bluetooth Finder

Además se permitía consultar un registro de eventos, mensajes, configurar las alertas y avisos,

bloquear a contactos no deseados... y usar el teléfono normalmente mientras seguía

funcionando en segundo plano.


15

Sobre las aplicaciones desarrolladas durante la fase de explotación

Dos meses después de presentar el PFC comenzó el trabajo en la empresa Esidea Grupo

Tecnológico, que en dos años pasó de ser una pequeña desarrolladora de servicios Web a un

referente en el mercado del Mobile Marketing de nuestro país.

Figura 8, Figura 9 y Figura 10: Metro Madrid (17.000 descargas en Softonic)

Se comenzó desarrollando aplicaciones muy básicas, como programas de fiestas (San Mateo y

San Bernabé en varias de sus ediciones), enoturismo, visitas guiadas, etc. y con los años se fue

incluyendo funcionalidad cada vez más compleja como audio guías, mapas, alertas,

notificaciones, actualizaciones, interacción con otros dispositivos y un largo etcétera.

Figura 11, Figura 12 y Figura 13: Ejemplo de guía turística (“Laboral ciudad de la cultura”)


16

Figura 14, Figura 15 y Figura 16: Aplicación Montaña Central (Directorio de establecimientos

con posibilidad de interacción: llamar, guardar contacto, visitar Web...)

En 2011 y con más de noventa proyectos desarrollados, otras tecnologías ya maduras y con

crecientes cuotas de mercado como iOS, Android, o Layar (un navegador de Realidad

Aumentada[14] multiplataforma) pusieron fin al ciclo de vida explotable empresarialmente de

JavaME.

Figura 17 y Figura 18: Aplicación Layar desarrollada en Esidea Grupo Tecnológico (“Semana Friki de Logroño 2.0”)


17

Sobre el sistema de envío de contenidos utilizado

Para el envío de las aplicaciones citadas en el apartado anterior se hizo necesario el uso de un

dispositivo especializado. En general se usaron equipos de la familia WRAP Access Server de la

empresa Bluegiga[15].

Pequeños ordenadores embebidos con Sistema Operativo Linux[16], algunos puertos de

comunicación y de uno a tres chips Bluetooth con los que establecer de siete a veintiuna

comunicaciones simultáneas con otros tantos teléfonos móviles.

Dotados de un Software específico para la realización de campañas de Bluetooth Marketing [17],

podían configurarse parrillas de contenidos en función de la hora y el día y parámetros como:

Número de intentos para establecer la conexión (ante todo, no bombardear al usuario)

Requerimiento de códigos de emparejamiento

Respuesta a solicitudes (por ejemplo, desde una aplicación con la cartelera de un cine,

solicitar un tráiler en concreto).

Alcance del equipo (para obligar a entrar en el establecimiento)

Con posibilidad de enviar cualquier tipo de fichero y formato (el límite en este caso lo pone el

receptor del contenido), a partir de 2008 permitieron reconocer el tipo de dispositivo con el

que se estaba intentando establecer la comunicación, lo que facilitó ajustar mejor los

contenidos como se detallará a lo largo del presente documento.

Figura 19: Emisor Bluetooth Bluegiga 2293 ext

Un año después, la propia Bluegiga desarrolló el Software de control remoto tipo NoIP[18] con

el que gestionar grandes parques de dispositivos, publicaciones, logs[19] (y por lo tanto


18

estadísticas) y similares, lo que permitió ofrecer campañas mucho más escalables justo en el

momento en el que los clientes comenzaban a demandarlas.

Este tipo de Software de control remoto en tiempo real, junto a la posibilidad de hacer que

varios equipos trabajasen de forma sincronizada como si de uno solo se tratase, permitió

además cubrir grandes zonas como centros comerciales o estadios de fútbol.

Más aún: En aquellos recintos de entrada regulada, cubiertos completamente por el alcance

de los emisores, sabiendo el aforo en un momento determinado gracias a la información de las

taquillas y el número de dispositivos visibles (detectables) vía Bluetooth, fue posible establecer

el porcentaje de usuarios que normalmente llevaban el sistema Bluetooth de sus teléfonos

encendido.

Tras analizar miles de ficheros de log, provenientes de proyectos como “Actual”[20] (en el

Palacio de los deportes de Logroño) y similares, se estableció que esta media estaba en torno

al 13-15% del aforo.

Una vez comprobado este dato, fue posible desplegar proyectos en escenarios con entrada no

controlada (como El Corte Inglés[21] en varias ciudades de España), de manera que los equipos,

aun no enviando ninguna campaña de Marketing ni contenido, se convirtieron en

herramientas muy útiles de monitorización.

Por ejemplo, aparte de reportar informes sobre el número de personas en el local en un

momento determinado, o su variación a lo largo de las semanas o los meses, podíamos

determinar para un teléfono dado:

El número de veces al mes, semana o día que acudía al establecimiento.

Puertas de entrada, salida o recorridos dentro del mismo, incluyendo pausas.

Tiempo de estancia en cada visita.

Si cada vez que se detectaba dicho teléfono, se detectaban otros (visitas en pareja o

grupo)

Al no ser la MAC Bluetooth[22] de un teléfono móvil un dato que pueda asociarse a ningún otro

de carácter personal como el número de teléfono, se cumplía escrupulosamente la LOPD[23]

(Ley Orgánica de Protección de Datos) y por lo tanto no era necesario informar al usuario de la

monitorización, ni inscribir ningún fichero en la Agencia de Protección de Datos[24].

Es evidente que la información ofrecida por estos emisores no podía tomarse como fiable al

100% ya que había demasiadas variables de difícil control en estos escenarios, sin embargo

mediciones puntuales a pie de campo demostraron que sí podía obtenerse información útil.

Se podría haber obtenido información mucho más fiable mediante el uso de pequeñas antenas

GSM/GPRS[25] pero su uso no es legal en nuestro país y por lo tanto quedaron totalmente

descartadas.


19


20

1. Fragmentación

Como cada vez que se toma una decisión, la elección de JavaME trajo consigo muchas

soluciones, pero también algunos problemas importantes, de los que se destacarán dos:

Primero: Al abordar el problema de conseguir llegar al mayor número de cuota de mercado

con una solución generalista en un entorno altamente fragmentado, se dio el hecho de que

muchos dispositivos no disponían de determinadas características Hardware (como capacidad

de proceso, memoria, GPS, cámara, etc.) muy útiles para los proyectos.

Esto provocó que, en general, se acabasen desarrollando aplicaciones con el mínimo común

múltiplo de características soportadas por una mayoría razonable de dispositivos del mercado.

Aplicaciones funcionales, sí, pero poco ambiciosas para lo que algunos dispositivos ofrecían en

aquel momento.

Figura 20: Dispositivos para pruebas

Algo parecido a lo que está sucediendo hoy en día con plataformas como Android, donde los

desarrolladores en muchos casos tienen que pagar el precio de dirigirse a una plataforma con

un 70% de cuota de mercado Smartphone[26], cubierta por docenas de marcas y modelos

heterogéneos.

Segundo: Sun no tuvo ni remotamente la capacidad de hacer evolucionar su plataforma a la

velocidad que el mercado demandó, ni tampoco desarrolló un programa de certificación para

todas aquellas empresas que quisiesen fabricar teléfonos móviles y venderlos como

“Compatibles con JavaME”.


21

Esto propició que muchas empresas desarrollasen versiones modificadas de la Máquina Virtual

de Java (JVM)[27] para que funcionasen mejor con sus teléfonos móviles, incluyendo

extensiones y librerías propias, como en el caso de Nokia, lo que provocó que muchas

aplicaciones en teoría compatibles no tuviesen el comportamiento esperado en según qué

terminales.

Se tuvo que lidiar con este caos de dispositivos, características y máquinas virtuales, probando

cada aplicación en docenas de dispositivos reales antes de su despliegue, hasta que en torno a

2009-2011 nuevas plataformas como iOS y Android barrieron del mapa en relativamente poco

tiempo a Java Me, trayendo consigo nuevos problemas y retos.

Este segundo caso recuerda a lo que está sucediendo en la plataforma Android, donde

empresas como HTC[28] desarrollan sobre la capa del sistema operativo extensiones

adicionales, como HTC Sense[29], aunque a nivel del desarrollador esto sólo supone ya una

molestia más que un problema como sucedía en JavaME.

Es justo decir, no obstante, que el desarrollo de Sense responde por parte de HTC más a una

serie de necesidades de marketing y diferenciación que de desarrollo evolutivo de la

plataforma Android, aunque de igual manera se podría esgrimir el argumento de que el coste

de personalización directamente sobre Android es elevado.

En esta primera sección vamos a analizar algunos problemas característicos derivados de estos

dos puntos, donde se refleja e ilustra claramente el día a día del desarrollo con la plataforma,

entre ellos:

Fragmentación en tamaño de pantalla (1.1)

Fragmentación en capacidad de proceso (1.2)

Identificación del tipo de terminal desde un emisor Bluetooth (1.3)

Identificación del tipo de terminal en tiempo de ejecución (1.4)

Usabilidad a través de diferentes marcas y modelos (1.5)


22

1.1. Tamaños de pantalla y formatos. Alternativas y soluciones

Uno de los primeros retos que debe resolver un desarrollador de aplicaciones para dispositivos

móviles es lidiar con la gran disparidad de tamaños y formatos de pantalla que existen en el

mercado.

Durante el PFC y por limitaciones de presupuesto, se trabajó casi exclusivamente con un

terminal Nokia 6630, de 176x208 píxeles de pantalla, de manera que todos los recursos

gráficos se adaptaron para su correcta visualización en este dispositivo, sin demasiadas

posibilidades de prueba en otros terminales.

El primer requisito funcional a añadir en las aplicaciones que se desarrollaron en producción y

con el que no contaba la aplicación del proyecto, fue la inclusión de una pantalla de inicio o

Splash Screen, que permitiese dar contexto al proyecto y soporte a los logotipos de

patrocinadores y clientes.

El desarrollo del código para visualizar una imagen fue relativamente simple, no así la decisión

de mostrar estas imágenes a pantalla completa, ya que dicha característica, por básica que

parezca, sólo estaba disponible en la versión JavaME/MIDP 2.0[30], compatible con en torno al

70% de los teléfonos móviles JavaME del mercado de entonces (2006).

En la siguiente imagen (ver Fig. 21) podemos ver parte de este código. Hay algunas variables

pre-ofuscadas manualmente (“a3” y “a4”) por motivos de eficiencia y seguridad.

Figura 21: Código de visualización de imágenes


23

Un análisis en profundidad del parque de dispositivos reveló que de entre el 30% de teléfonos

no compatibles apenas sí había modelos con tecnología Bluetooth, principal plataforma de

distribución a usar y de la que hablaremos más adelante, por lo que podían “sacrificarse” a

cambio de obtener una experiencia de usuario mejor.

Efectivamente: el impacto visual, sobre todo para un anunciante, de ver su logotipo a pantalla

completa en un móvil no era comparable a hacerlo en una pequeña porción de la misma. Aquí

el cliente manda.

El siguiente problema fue obvio: Elegir tamaños y/o formatos para las pantallas de

presentación. Es este caso, de nuevo un análisis en detalle de las cuotas de mercado de cada

dispositivo en nuestro país reveló que en torno al 90% del total, se repartía en apenas media

docena de tamaños:

128x128, 128x160, 176x208, 176x220, 240x320, 320x240 y 480x320 píxeles respectivamente.

Aunque las cuotas cambiaron con los años en detrimento de los formatos más pequeños, y se

añadieron nuevos tamaños a la lista, ésta puede ser una muestra bastante representativa.

Ahora bien, en ese momento no se disponía de tecnología de reconocimiento de dispositivos

(marca, modelo, etc.) a la hora de enviar las aplicaciones desde un emisor Bluetooth, por lo

que la aplicación debía contener en su interior los recursos gráficos para todos los tipos de

pantalla, eligiendo en tiempo de ejecución aquellos que mejor se adaptasen al dispositivo.

Esto, junto al hecho de que muchos teléfonos móviles no aceptaban aplicaciones de más de

1Mb y de que incluso en caso de no llegar a este tamaño, enviarlo vía Bluetooth podía suponer

una espera inaceptable para el usuario final (en torno a 30 segundos), hacía necesario tomar

algunas decisiones con respecto a qué formatos incluir en el paquete (jar[31]).

En general una buena solución fue, para pantallas que tuviesen el mismo ancho, incluir sólo la

imagen para el formato más alto, pero dejando la información en la zona visible del tamaño

con el alto más pequeño.

Figura 22, Figura 23 y Figura 24: Formatos de portada


24

De esta manera, una misma imagen de 128x160 píxeles podría servir por ejemplo tanto para

una pantalla de 128x160 píxeles, como para una de 128x128 ya que al mostrarse en esta

segunda, simplemente dejarían de dibujarse dos franjas, una en la parte superior y otra en la

parte inferior, pero sin información relevante en ellas.

Se descartaron otras alternativas como manejar logos o partes de una imagen por separado y

maquetarlas manualmente (por código) debido a los requisitos cambiantes en cuanto a

posición de un proyecto a otro con el consiguiente cambio de código, y uso de fondos

comunes sólidos/simples que contuviesen al conjunto: Mejor delegar el trabajo al

departamento de diseño gráfico.

Otra alternativa descartada fue el uso de gráficos vectoriales escalables sin pérdidas (SVG[32])

ya que no resolvían el problema de los formatos, no eran compatibles con prácticamente

ningún modelo de teléfono (sólo Nokia en su gama más alta) y su velocidad de dibujado era

bastante pobre.

Un buen ejemplo actual de cómo una empresa ha resuelto este tipo de problemas lo

encontramos en Apple. Su gama de dispositivos iPhone ha mantenido en una primera fase su

tamaño de pantalla idéntico: 320x480 píxeles para los modelos 2G, 3G y 3Gs.

Cuando se hizo necesario aumentar la resolución de la pantalla, se duplicó manteniendo el

formato: 640x960 para los modelos 4 y 4s. Además no es necesario cambiar ni una sola línea

de código para usar unos recursos u otros en función de si la aplicación se ejecuta en un

terminal 320x480 o 640x960 (también conocidos como retina): Simplemente nombramos los

recursos como “imagen.png” o “[email protected]” y el dispositivo toma los necesarios.

Cuando de nuevo hubo que aumentar el tamaño de pantalla, se mantuvo el ancho intacto (640

píxeles) y se aumentó de nuevo el alto hasta los 1136 (iPhone 5) de manera que nuestra

estrategia puede ser perfectamente válida en este escenario.


25

1.2. Capacidad de proceso, terminales y soluciones de compromiso

Con terminales en el mercado que podían superar fácilmente en términos de capacidad de

proceso en una proporción de veinte a uno a otros, se hace realmente difícil no sólo llegar a

una solución de compromiso en cuanto a qué funcionalidad incluir en ellos, como se

comentaba anteriormente con la regla del mínimo común múltiplo, sino que se hace también

muy complicado prever la experiencia de usuario de la aplicación.

En general, la mayoría de los cuellos de botella y esperas durante el uso de este tipo de

aplicaciones se daban no durante el cálculo de procesos u operaciones complejas, sino durante

la carga y descarga de recursos en memoria como por ejemplo imágenes o Clases[33].

Detectar aquellos puntos críticos en los que un terminal no será capaz de cargar o gestionar

recursos en un tiempo de espera razonable obliga en la medida de lo posible a tener esos

recursos ya cargados, cuando la escasa memoria lo permita.

Un punto ideal de precarga de recursos sin afectar a la experiencia de usuario de la aplicación

lo encontramos durante la visualización de la/s pantalla/s de presentación. Análisis heurísticos

con diferentes tipos de usuarios revelaron que:

2 segundos es el tiempo mínimo de visualización de este tipo de pantallas en el que el

usuario percibe y asimila el mensaje. Ideal cuando existen varias pantallas adicionales

a la principal, que contengan sólo logotipos de anunciantes.

de 2’5 a 3’5 segundos es el tiempo de visualización medio aceptable de cualquier tipo

de pantalla, incluyendo breves textos, como por ejemplo una portada con un cartel de

fiestas.

5 segundos es el tiempo máximo que un usuario está dispuesto a esperar para

empezar a utilizar la aplicación. A partir de este punto empezará a impacientarse, a

pulsar diferentes teclas del teléfono o a preguntarse si la aplicación se ha colgado.

Figura 25, Figura 26 y Figura 27: Secuencia de portadas


26

Si tenemos en cuenta que la carga de una imagen de portada (176x208) en un teléfono como

un Nokia 6630 puede llevar en torno a 1 segundo completo (dependiendo también del tipo de

contenido, paleta de colores, etc.) tenemos en torno a 2 segundos más para cargar en segundo

plano otro tipo de recursos mientras el usuario permanece viendo la pantalla de presentación

y sin que su experiencia de usuario se vea mermada.

Figura 28: Código de cálculo de costes

Y así se hizo: Estructura de navegación, clases auxiliares, iconos y otro tipo de recursos,

siempre que no se sobrepasase la memoria disponible y fuesen elementos de uso intensivo y

recurrente, se dejaban cargados en memoria.


27

1.3. Identificación de terminales desde un emisor Bluetooth

En 2008 y tras más de dos años de trabajo con continuas demandas para generar aplicaciones

más ricas en imágenes y gráficos y con nuevos formatos de pantalla apareciendo cada pocos

meses, se estaba haciendo virtualmente imposible incluir en cada aplicación todos los recursos

necesarios para cubrir una parte razonable de los terminales del mercado.

Justo en ese momento apareció en el mercado la tecnología necesaria para reconocer desde el

emisor Bluetooth la marca y el modelo del teléfono al que enviar los contenidos, de manera

que fuese posible generar diferentes paquetes (.jar) sólo los recursos que el modelo de

terminal de destino fuese a utilizar.

El mecanismo de funcionamiento para esto fue relativamente sencillo: La dirección MAC del

chip Bluetooth de cualquier dispositivo se divide en bloques. Algunos de ellos dan información

sobre el fabricante del terminal, otros sobre la familia del mismo, y los últimos sobre el modelo

de teléfono e incluso sus características.

Esta información no es 100% confiable ya que dos teléfonos móviles idénticos en marca y

modelo pueden tener diferentes bloques MAC para representar esta información (por ejemplo

si han sido fabricados en diferente país, fábrica o serie) pero puede ser una información

heurística aprovechable.

Figura 29: Base de datos de dispositivos

Sin embargo no hay publicada por parte de los fabricantes ni del IEEE[34] (quien asigna las

MACs) una relación de éstas con los teléfonos en las que se incluyen. Si tuviésemos una

manera de asociar esos códigos a un terminal en concreto, podríamos guardar esa información


28

en una base de datos dentro del emisor Bluetooth que nos sirviese en el futuro para decidir

qué paquete enviar al detectar por MAC el teléfono de destino.

Y la tuvimos. La mayoría de los fabricantes asignan como nombre visible Bluetooth (o friendly

name), la marca y modelo del teléfono. Por ejemplo, un terminal Nokia 6630 casi con toda

seguridad saldría de fábrica con el nombre visible Bluetooth “Nokia_6630”.

Con un extenso parque de emisores Bluetooth repartidos por todo el país, con capacidad de

almacenar logs y enviarlos a un servidor central en nuestras oficinas, y con la capacidad de

interrogar a cada dispositivo Bluetooth que pasase por sus proximidades acerca de su dirección

MAC y su nombre visible, ya sólo era cuestión de procesado de datos el extraer la información

que necesitábamos.

Problema (I): El trabajo de recopilar los logs, procesarlos mediante varios scripts[35], e insertar

esta información en las bases de datos de los emisores, requería bastantes horas de trabajo

semanal, ya que aunque muchos procesos se automatizaron, la revisión de los resultados

debía hacerla un técnico.

Problema (II): Una vez un usuario de teléfono activaba por primera vez su emisor/receptor

Bluetooth, tendía a cambiar el nombre visible del mismo. Por ejemplo, de “Nokia_6630” podía

pasarse fácilmente a “6630_David” y por lo tanto ya no coincidir la cadena de búsqueda. La

única manera de tomar una decisión acerca de qué información podíamos extraer de

“6630_David” era muchas veces hacer el análisis personalmente.

Es decir, una persona debía revisar todas las salidas sobre posibles nuevas entradas en la base

de datos y si la información disponible en el friendly name era suficiente, asignar manualmente

la marca y modelo: Un día de trabajo semanal de un técnico, a lo largo de varios años.

Problema (III): Se detectaron casos en los que usuarios de teléfonos de gama baja asignaban a

sus terminales nombres de teléfonos de gama alta. Por ejemplo en el caso de un Nokia 3310,

asignar de nombre visible Bluetooth “Nokia_N95”. La cantidad de problemas que pueden

derivarse de esto, como se puede entender, son muchos y bastante difíciles de depurar.

Problema (IV): Aún en el supuesto de que todo el proceso funcionase correctamente, el

resultado del mismo implica generar muchos más entregables (.jar) que con una sola

distribución. A lo que se vio en el apartado 1.1 sobre tamaños de pantalla habría que sumar

versiones JavaME estándar y versiones JavaME para otras familias (como BlackBerry[36]),

versiones firmadas digitalmente, sin firmar...se tuvo que generar por tanto Software adicional

para crear todas las familias de entregables ya que el compilado manual dejó de ser eficiente.

En resumen, una tecnología que en teoría iba a hacernos la vida más fácil acabó trayendo

consigo nuevos niveles de complejidad para su mantenimiento. En el momento en el que se

dispuso de ella para aumentar la calidad del servicio que se ofrecía, nos vimos arrastrados a

usarla, aunque ello conllevase unos costes adicionales en mantenimiento y despliegues

brutales.

A día de hoy todo esto ha quedado en el olvido afortunadamente, con los nuevos modelos de

distribución de aplicaciones como App Store[37] y Google Play[38].


29

1.4. Identificación de terminales en tiempo de ejecución

Aparte de la carga de recursos, durante la visualización de las Splash Screens hay algunas

operaciones interesantes y computacionalmente muy costosas que podemos realizar. Una de

ellas es el intento por parte de la aplicación de identificar el tipo de terminal sobre el que se

está ejecutando. Tenemos que pensar que hasta la proliferación de las tiendas de aplicaciones

como las anteriormente citadas, App Store o Google Play, los modelos de detección y envío de

aplicaciones más usados eran:

Descarga WAP[39]: El terminal accede a un portal de aplicaciones y mediante su “User

agent”[40] indica marca y modelo y el servidor envía la aplicación que mejor se ajuste.

Envío Bluetooth: El emisor de aplicaciones detecta un dispositivo Bluetooth cerca e

intenta el envío de una aplicación. Hasta que en 2008 se empezaron a desarrollar

técnicas de detección de marca y modelo desde el emisor, el envío debía hacerse “a

ciegas” y mediante un único paquete (.jar).

Pero incluso sabiendo el modelo de teléfono de destino, muchas veces no merece la pena abrir

una nueva rama de compilación cuando con un pequeño “if...else” pueden solucionarse

muchos problemas.

Ejemplo práctico: Soft Keys. Las teclas de acción que hay normalmente justo debajo de la

pantalla del teléfono y que por increíble que parezca, no usaban un código de acceso o

referencia unificado a través de diferentes marcas y modelos.

Poder hacer uso de estas teclas es fundamental para la aplicación, ya que a través de ellas

podremos desplegar menús y seleccionar opciones. Para detectar estos códigos se plantearon

dos técnicas:

En primer lugar: Comprobar si el teléfono dispone de librerías específicas de alguna marca. En

la siguiente imagen (ver Fig. 30), por ejemplo, comprobamos si el teléfono dispone de un

paquete preinstalado solamente los teléfonos Siemens.

En caso afirmativo, sabemos que es un Siemens y sus códigos por marca. En caso negativo,

probamos con Motorola. Si la carga de la clase tiene éxito, pueden darse varios casos

(asignación positiva o negativa). Los comprobamos y asignamos. En caso negativo, seguiríamos

iterando con más marcas.


30

Figura 30: Código de identificación de terminal

En segundo lugar: Si el proceso anterior concluye sin éxito, se itera a lo largo de todo el rango

asignable de teclas (-127, 127) y se comprueba manualmente si alguna de ellas tiene asignada,

como parte de su nombre, la cadena “Soft” (de SoftKey1, SoftKey2, etc.). Aunque esta

información no es rigurosamente cierta en todos los casos, puede suponer una ayuda

importante.

Figura 31: Código de identificación de Softkeys


31

1.5. Interfaz de usuario y usabilidad

Cuando en 2005 se planteó la implementación del PFC en el nivel de la capa de presentación,

se dispuso principalmente de dos tecnologías.

Alto nivel o componentes nativos de la propia plataforma, como listas (List), botones

(Button), campos de texto (TextField), etc.

Bajo nivel o componentes personalizados, desarrollados por el propio programador o

usando librerías de terceros, apoyadas en elementos de dibujo libre de tipo “Canvas”.

En general es recomendable usar componentes de bajo nivel cuando técnicamente no se

puede implementar algún requisito funcional de la aplicación mediante elementos estándar de

la plataforma. En las aplicaciones que se derivaron del PFC durante su fase empresarial,

podríamos ver ejemplos como los mapas de situación, o simplificando mucho, las ya

mencionadas Splash Screen.

Otro escenario muy común de uso de este tipo de componentes son los videojuegos, donde

prima una experiencia de uso inmersiva, no sólo en la pantalla de juego propiamente dicha

sino también en todos los demás elementos del mismo, como menús, pantallas de puntuación,

etc.

Como último ejemplo podríamos citar aquellas aplicaciones que reproducen la funcionalidad

de un elemento del mundo real, como una brújula o un nivelador. En estos casos, cuanto más

se parezca la interfaz de la aplicación al elemento del mundo real, más fácil será para un

usuario entender y prever su funcionamiento.

Sin embargo su uso tiene algunos inconvenientes importantes.

Si nos decantamos por librerías de terceros, en aquel escenario sólo disponíamos de

proyectos inmaduros, con baja compatibilidad entre terminales y altos consumos

tanto de memoria como de capacidad de proceso, cosa que no mejoró con el tiempo:

TwUIk, J2Me Polish o LWUIT, un intento tardío e infructuoso por parte de la propia Sun

de dar respuesta a las demandas de los desarrolladores.

Si nos decantamos por desarrollar personalmente el componente, aparte de hacer

frente a las horas de desarrollo tendremos que sumar horas de mantenimiento y

actualización. Pensemos que si usamos elementos estándar y estos sufren una

actualización por parte de Sun, automáticamente todos los elementos de nuestra

interfaz estarán actualizados y seguirán siendo conformes con las aplicaciones

instaladas en el teléfono, no ocurriendo así con los elementos en bajo nivel, siendo

responsabilidad del desarrollador su actualización.

Sin embargo no son sólo los costes de desarrollo y mantenimiento el verdadero problema, sino

en muchos casos el no respetar las convenciones y metáforas de la plataforma a la hora de

implementar dichos componentes.


32

Es tal la repercusión de esto último que nos decantamos por los elementos de alto nivel, y

seguimos trabajando con ellos salvo en casos de extrema necesidad, decisión que se demostró

muy acertada con el tiempo por varios motivos.

Es verdad que las interfaces en alto nivel en JavaME pueden parecer “acartonadas” y muy

similares de una aplicación a otra debido a que no son personalizables (tipo de fuente, color,

distribución de elementos, etc.)

Figura 32, Figura 33 y Figura 34: Interfaz en alto nivel

Sin embargo los usuarios se sienten cómodos usándolas porque se parecen a las aplicaciones

que vienen por defecto en el teléfono y ya conocen. Es por eso que en muchos casos esperan

ese mismo tipo de componentes, la manera en que se comportan y cómo se interactúa con

ellas.

Si además respetamos las convenciones de cada plataforma, se conseguirá que el usuario se

sienta cómodo con la aplicación, puesto que le resultará familiar y formará parte del “conjunto

de experiencias de usuario” del teléfono.

Un ejemplo de esto sería colocar el botón “Atrás”, en la parte inferior derecha de la pantalla

en los modelos “Nokia” y en la parte inferior izquierda en los modelos “Sony Ericsson”. Muy

fácil de hacer con el elemento de alto nivel “Command.Back” pero más difícil de hacer si el

texto “Atrás” está dibujado sobre la pantalla.

Al hacer uso de convenciones y comportamientos que el usuario ya ha aprendido y conoce, se

reduce la "carga cognitiva" que el usuario debe soportar al usar la aplicación, habiéndose

demostrado sistemáticamente mediante test de usabilidad que las tareas se completan más

rápido y con menos errores.

Algunas de estas lecciones se aprendieron durante un fork de I+D+i de Esidea Grupo

Tecnológico, en forma de Proyecto Fin de Carrera propuesto en 2006 a la Universidad de La

Rioja. Fue desarrollado durante el siguiente año (2007) por el alumno D. Sergio de Torre Blasco

y codirigido por D.ª Miriam Andrés Gómez y el autor del presente documento.


33

Bajo el título “Browser de descarga de contenidos para dispositivos inalámbricos”, se trabajó

durante un año exclusivamente en el ámbito de las interfaces de bajo nivel con JavaME. A

pesar de la calificación del proyecto (Matrícula de Honor) buena parte de los resultados

técnicos del mismo, aunque satisfactorios para un entorno académico, nunca pudieron pasar a

producción en un entorno empresarial.

Sin embargo y como se comentaba, las lecciones aprendidas en esa línea de investigación sí

permitieron posteriormente centrarse en otras, con mucha más convicción, y permitieron

además entender las decisiones estratégicas de otras compañías en el futuro.

Apple, por ejemplo, quien ha tenido todos estos aspectos muy en cuenta a la hora de

desarrollar la interfaz de su sistema operativo iOS. Mediante unas estrictas guías de estilo

(Human Interface Guidelines[41]) define exactamente cómo deben usarse todas y cada una de

las componentes de alto nivel de su sistema, creando una experiencia de usuario muy definida.

De hecho se ha tachado a iOS en muchas ocasiones de haber evolucionado poco a nivel

estético en los últimos años y de ser poco personalizable. Sin embargo sus usuarios reportan

los mayores niveles de satisfacción sobre el uso de sus dispositivos (iPhone/iPad), muy por

encima de otras plataformas.

Google, quien comenzó con un modelo mucho más liberal y permisivo en Android a la hora de

dejar que los desarrolladores implementasen la interfaz de sus aplicaciones, siguió en 2012 los

pasos de Apple creando su propia “guía de estilo”, ante las críticas de muchos usuarios acerca

de la abrumadora heterogeneidad visual y de comportamiento entre aplicaciones.

Más aún, la llegada de modelos Nexus[42] al mercado es un claro ejemplo de la necesidad de

cuidar y supervisar toda la experiencia de usuario, tanto en Software como en Hardware.

Microsoft, tercer gran competidor en llegar a esta última generación de dispositivos móviles,

ha seguido los pasos de sus predecesoras y desde el primer momento define mediante una

línea muy marcada el diseño de la interfaz en sus aplicaciones Metro[43].

De forma parecida a los ejemplos anteriores, Microsoft también ha llegado a la conclusión de

la necesidad de cuidar aspectos Hardware, a través de Nokia, quien posiblemente veamos

cómo es absorbida por el gigante de Redmond a lo largo de este 2013.


34

2. Seguridad en JavaME

Durante los años de explotación del PFC se conjugaron prácticamente todos los problemas de

seguridad que pueden darse en una única plataforma. Muchos de ellos derivados del uso de

una determinada tecnología con fines no previstos, como el uso de Bluetooth para el envío de

programas desde la vía pública, o la instalación de aplicaciones de terceros en dispositivos que

muchas veces se seguían viendo como cajas negras, que se compraban con una serie de

aplicaciones preinstaladas y tras varios años de uso se tiraban con exactamente esas mismas

aplicaciones.

Otros fueron intrínsecos a la propia tecnología, como en el caso de JavaME, un lenguaje

interpretado del que es relativamente fácil extraer información, una vez está compilada y

empaquetada una aplicación escrita en él y lista para ser distribuida.

Se ha visto en el apartado anterior cómo Apple acabó de un plumazo con la mayoría de los

problemas de fragmentación que tenían la práctica totalidad de desarrolladores para

dispositivos móviles del mundo. En seguridad no se quedó atrás.

Al elegir Objective-C[44] como lenguaje para su sistema operativo y aplicaciones y

posteriormente, al crear un punto de distribución de aplicaciones único y estrechamente

controlado (la App Store), terminó también con la mayoría de problemas derivados de la

distribución no unificada de aplicaciones y la relativa facilidad para descompilar Software en la

plataforma por aquel entonces dominante, JavaME.

En este bloque analizaremos:

Las limitadas ventajas de firmar digitalmente aplicaciones (2.1)

Cómo suplantar la identidad de un desarrollador y cómo intentar evitarlo (2.2)

Cómo extraer información y recursos de una aplicación (2.3)

Cómo defenderse de modificaciones en las aplicaciones (2.4)


35

2.1 Firma digital de aplicaciones: ventajas y limitaciones

Firmar digitalmente una aplicación JavaME tiene muchas ventajas, como adquirir privilegios en

el teléfono para leer de la agenda de contactos, crear un evento en el calendario o acceder a la

tarjeta de memoria. Con estas tres características las posibilidades ya se multiplican.

En otros casos, las ventajas se derivan de poder garantizar la identidad del desarrollador.

Imaginemos un emisor malintencionado en las proximidades de otro perteneciente a un

publicador real con el mismo nombre (por ejemplo Logro_Turismo).

En este escenario si un usuario sacase su teléfono para descargar una aplicación, no tendría

manera de determinar si el mensaje de invitación lo recibe del emisor original o del

malintencionado.

Se pueden realizar bastantes ataques vía Bluetooth sólo con tener el receptor en modo visible.

Muchos más si se empareja con otro dispositivo malintencionado. Pero dejar en manos de un

tercero absolutamente todo lo que podemos hacer con nuestro teléfono móvil, y los datos que

contiene, es tan sencillo como instalar una aplicación con un Troyano.

Simplemente una pequeña pista visual dentro del cartel de invitación a la descarga, que nos

avisara de que debemos instalar solamente aplicaciones firmadas por un determinado

distribuidor ya podría reducir el riesgo de ataques.

Sin embargo...

El proceso de firma digital de una aplicación JavaME no es muy diferente al de la firma de un

Applet[45] o cualquier otro programa. Hasta aquí la teoría. Primero hay que elegir la entidad

certificadora para firmar, ya que para empezar muy pocos teléfonos disponían de certificados

de varias compañías. Era raro encontrar una marca o modelo que incluyese certificados tanto

de Thawte[46] como de Verisign[47], las dos principales entidades certificadoras.

Si eligiésemos como entidad certificadora a Verisign, por ejemplo, firmásemos la aplicación y el

teléfono de destino que la intentase instalar no dispusiese más que de certificados de Thawte,

todo este proceso no habría servido para nada o, peor aún, podríamos provocar que la

aplicación no pudiese instalarse en el teléfono, algo habitual también al intentar firmar la

misma aplicación dos veces con dos certificados diferentes.

En muchos casos la solución pasaba por comprar certificados de diferentes entidades y firmar

las aplicaciones en función de los teléfonos de destino. Ya no sólo debíamos hacer

distribuciones en función del tamaño de pantalla, por ejemplo, sino que debíamos hacer

grupos y subgrupos por marcas y modelos según el certificado. Más aún, muchos modelos

directamente no soportaban la instalación de aplicaciones firmadas digitalmente, por lo que se

debía crear un tercer grupo de aplicaciones no firmadas.

En general, el firmado digital de aplicaciones puede decirse que sólo dio buenos resultados a la

hora de hacer despliegues controlados. Un ejemplo de ello es Nokia OVI Store, la tienda de

aplicaciones para teléfonos Nokia, de la que se hablará en el apartado cuatro: “Monetización”.


36

2.2 Suplantación de la identidad del desarrollador

Como se ha visto en el apartado anterior, la firma digital de aplicaciones puede proporcionar

muchas ventajas, algunas de ellas dentro del ámbito de la autoría. En escenarios en los que no

era posible firmar digitalmente aplicaciones, resultaba complicado demostrar de manera

sencilla y rápida dicha autoría.

Puede parecer descabellado tener que hacer esto, pero se dieron casos reales de terceros que

tomaron aplicaciones, cambiaron los logotipos del patrocinador por los suyos propios y el

texto con la cadena del desarrollador y de contacto.

Todo esto fue posible mediante la decompilación del código fuente, casi con seguridad usando

programas como DJ Java Decompiler[48] o similares. Con él, a pesar de la ofuscación, es posible

extraer el código de la aplicación y encontrar fácilmente las cadenas de texto a modificar.

Detectar este tipo de fraudes en un escenario de publicación distribuido, como es el envío de

aplicaciones por Bluetooth, es muy complicado ya que no puede saberse qué contenidos está

enviando un emisor de la competencia que se encuentra al otro lado del país.

Parte I: La solución más simple que puede funcionar

Para este tipo de casos, se incluyó un archivo de texto dentro del paquete (.jar) con

información sobre el desarrollador y su contacto. Al ser posible abrir un fichero .jar como si de

un comprimido se tratase, resultaba sencillo desde un PC abrirlo, examinar el fichero y

comprobar los datos en su interior.

Figura 35: Código de verificación de seguridad (I)


37

Parte II: El señuelo

Para evitar que un tercero malintencionado borrase el fichero, se incluyó, al arranque de las

aplicaciones, un código para cargar el archivo en memoria y comprobar que el texto del

interior del fichero se correspondiese con otro similar en el código, de manera que si no se

encontraba esta información la aplicación se cerrase abruptamente.

Figura 36: Código de verificación de seguridad (II)

Parte III: La solución real y la violación del segundo principio de Kerckhoffs

Puesto que para un atacante que previamente ha descompilado una aplicación no sería

demasiado difícil cambiar también la cadena de comprobación anterior en otro punto del

código, distante del inicio y donde se realizaban operaciones con caracteres (char), se repetía

la operación de carga del fichero por nombre y comprobación con una cadena de texto

determinada usando solamente los códigos ASCII de cada carácter, de manera que no fuese

posible hacer una búsqueda por cadena de texto para modificarla.

Figura 37: Código de verificación de seguridad (III)


38

Al descompilar el código ofuscado, un atacante sólo vería un batiburrillo de declaraciones de

varios caracteres junto a la carga de varios recursos que nada tenían que ver con ningún

fichero, siendo muy complicado entender exactamente qué hace ese trozo de código.

Esta técnica, aunque se demostró efectiva (o mejor dicho, no se reportó ninguna incidencia

desde su puesta en práctica), no es segura puesto que incumple el segundo principio de

seguridad de Kerckhoffs[49]:

“La efectividad del sistema no debe depender de que su diseño permanezca en secreto”

...o dicho de otra manera, el método funcionó en la medida en que permaneció en secreto su

funcionamiento. En otros apartados se verán otras técnicas de suplantación y medidas para

intentar contrarrestarlas.


39

2.3 Robo de contenidos: extracción de código y recursos

Otro problema importante fue la extracción de contenidos desde la aplicación mediante

técnicas de Ingeniería Inversa, y por lo tanto, Know How de su desarrollo. Hay que incidir en la

idea de que el éxito de JavaME no fue del todo previsto y, como consecuencia de esto, la

información sobre el funcionamiento de la plataforma, la documentación, y sobre todo el

código de ejemplo y la proliferación de buenos foros de consulta fue tardía.

En muchas ocasiones la documentación sobre el funcionamiento de las APIs no revelaba

completamente las posibilidades de la plataforma, y por lo tanto se daba el caldo de cultivo

ideal para la implementación de soluciones creativas y “no previstas”.

...es decir: Se daba el escenario opuesto al que podemos encontrar ahora, con millones de

desarrolladores para dispositivos móviles volcados en Internet, publicando artículos en sus

blogs sobre cómo hacer las cosas, y sobre todo, con las principales empresas de desarrollo de

Software y de Hardware entendiendo que el ecosistema de desarrolladores de su plataforma

es posiblemente su mejor recurso.

Volviendo al problema, en JavaMe es muy sencillo a partir de un archivo .class (bytecode)

obtener un .java (código fuente). En otros escenarios en los que se generan .exe sería

necesario usar un des-ensamblador, un debugger, un editor Hexadecimal, etc. pero aquí con

un sencillo descompilador es suficiente.

Para defendernos de este tipo de ataques, podemos:

Usar ofuscadores de código.

Alterar el orden de declaración de los métodos: Que sea diferente al de ejecución.

Insertar bloques de estructuras de código no válidas en zonas “muertas” del programa.

Utilizar Threads de manera intensiva para aumentar la complejidad del código

generado.

Usar predicados opacos: Incluir condiciones que nunca se satisfacen.

Por motivos de rendimiento se descartaron otras alternativas, como el cifrado de parte del

código, ya que su descifrado en tiempo de ejecución tenía unos consumos de tiempo no

asumibles.

La aplicación de todas las técnicas anteriores permitía que, en general, el tiempo de extracción

de información a partir del código fuese mayor que ver la “idea” en ejecución y desarrollar su

implementación.


40

Otra fuente de extracción de Know How está en los recursos gráficos de la aplicación.

Encontrar un tamaño de icono, por ejemplo, que se maquete correctamente a lo largo de todo

el ecosistema móvil es algo complicado. Como lo era determinar los tamaños ideales para las

pantallas de presentación.

Una operación tan sencilla como abrir el .jar con una herramienta como Winzip[50], por ejemplo

(ya que es un fichero comprimido simple) y buscar la carpeta “src”, puede permitirnos

consultar cualquier tamaño de icono o Splash de manera sencilla.

La mejor manera de defenderse de este tipo de ataques consiste en generar archivos binarios

(.bin) que contengan en un formato como Base64[51] o similares, todos los recursos gráficos de

la aplicación.

De esta manera, al iniciarse la ejecución de la aplicación se carga el fichero en memoria, y

mediante código se extraen los bytes correspondientes a cada recurso. Para ello el

desarrollador debe saber el número de byte de inicio y fin de cada recurso. Una vez obtenidos

los bytes, ya es posible generar una imagen del recurso con constructores de tipo

String(byte[]).

En primeria instancia un atacante tendría por lo tanto que extraer el fichero de recursos por

una parte y descompilar el código por otra para poder tener los números de inicio y fin de cada

recurso.


41

2.4 Modificación no autorizada de contenidos

En el apartado 2.2 “Suplantación de la identidad del desarrollador” se ha visto una técnica

sencilla para incluir información de contacto en la aplicación, relativamente difícil de modificar.

Otro mecanismo de suplantación puede realizarse mediante la modificación de recursos

gráficos en la aplicación, por ejemplo, cambiando el logotipo de un anunciante o desarrollador

en una Splash Screen, o modificando los colores corporativos en los iconos de la misma.

Una acción para evitar este tipo de manipulación directa y obligar al menos a descompilar y

modificar, consiste en anotar en el código el color RGB[52] de un pixel de la imagen de portada

(por ejemplo), o los iconos de la aplicación.

De esta manera se comprueba en tiempo de ejecución si el color ha cambiado y de ser así se

cierra la aplicación.

A continuación mostramos un sencillo ejemplo de cómo implementar esto. Nótese que se

hacen varias operaciones adicionales durante el proceso: La primera es comprobar que los

códigos de los colores no son negativos (algunos dispositivos los devuelven así) y la segunda es

aplicar cierto margen de tolerancia entre el color RGB definido durante la fase de diseño y el

detectado por el teléfono, ya que podía variar ligeramente.

Figura 38: Código de verificación de color

De nuevo este sistema viola el principio de seguridad de Kerckhoffs sobre ocultación, pero al

menos añade una capa más de complejidad a la hora de manipular aplicaciones.


42

3 Optimización

La optimización en JavaME es, en el mejor de los casos, dura. En el peor, es la manera más

rápida de introducir nuevos bugs en la aplicación, reducir su portabilidad e invertir docenas de

horas para apenas obtener resultados.

De hecho, en muchos casos fue como un objetivo móvil: Modificaciones, que permitían

ejecutar el código más rápido en el emulador, podían ejecutarlo más despacio en los teléfonos,

o incluso, cambios que aceleraban el rendimiento en unos terminales lo reducían en otros.

En este tipo de escenarios, el punto de partida era, como lo sigue siendo a día de hoy, verificar

la regla del 90/10.

“El 90% del tiempo de ejecución de un programa lo produce el 10% del código”

Y será en ese 10% del código donde centremos nuestros esfuerzos de optimización. Para

averiguar exactamente dónde se encuentra, lo más habitual es usar un Profiler[53].

Figura 39: Profiler en Netbeans

Pero no todo es código. Los gráficos también juegan un papel importante en el rendimiento de

las aplicaciones, por lo que también será un tema a tratar. En este bloque, por tanto, se

abordará la optimización desde tres puntos de vista diferentes:

Gráficos: Estrategias que siguen funcionando hoy en día (3.1)

Algoritmos, operaciones a bajo nivel y buenas prácticas (3.2)

Arquitectura de aplicaciones y escalabilidad (3.3)


43

3.1 Gráficos: estrategias que siguen funcionando hoy en día

Se han comentado algunas estrategias relacionadas con los recursos gráficos de las

aplicaciones como la elección de los tamaños de las Splash Screen, o el empaquetado de

recursos en ficheros binarios. Esta última por cierto, muy útil no sólo para evitar robo de

contenidos sino para optimizar el espacio consumido por los mismos.

Otras operaciones importantes relacionadas con los gráficos y el espacio pueden ser:

Usar paletas de colores indexadas, y no RGB. Entre 8 y 16 si es posible. Las fotografías

en este caso se degradan bastante, pero la pérdida de calidad muchas veces sólo es

detectable por comparación con el original, es decir, que aunque la imagen se visualice

en una pantalla pequeña y con poca calidad, el ojo (o mejor dicho, el cerebro) tiende a

compensar el resultado.

No utilizar técnicas de alisado en las fuentes, ya que aumenta el número de colores.

Las tipografías usadas en videojuegos de los 80’ pueden ser un buen recurso.

Eliminar la metainformación de los archivos de imagen, incluyendo su fecha de

creación, autor, Software utilizado, etc. Esto puede hacerse de manera muy sencilla

con programas como PNGGauntlet[54].

Figura 40: Opciones en PngGauntlet


44

A pesar de todo lo anterior, las restricciones de memoria utilizable para la carga de recursos

gráficos seguían siendo importantes. Un problema típico lo encontramos en la visualización de

planos y callejeros, con dimensiones “elevadas” (por ejemplo, 1200x1200 pixeles).

No era frecuente encontrar teléfonos que pudiesen cargar ese recurso en memoria, de hecho

en muchas máquinas virtuales existía una zona de memoria (Heap[55]) específica para la carga

de recursos gráficos que no solía ser demasiado grande (<1Mb).

Podemos calcular que una imagen de 1200x1200 pixeles en memoria puede pesar (sin

operaciones adicionales)...

1200 pixels x 1200 pixels x 8 (bits de color) = 11.250Kb

...por lo que se hacía necesario partir la imagen en otras más pequeñas y cargar en memoria

sólo aquellas que debían mostrarse, descargando el resto. ¿De qué tamaño? Se observó que

un exceso de particionado no elevaba el rendimiento y sí hacía necesaria la creación de

muchos objetos de tipo Image en memoria (con su consecuente penalización en consumo).

También se observó que los teléfonos que más problemas tenían de memoria eran aquellos

más antiguos y en general con pantallas más pequeñas (128*160 pixeles). Se decidió entonces

que un buen tamaño de imagen sería aquel que fuese lo suficientemente pequeño como para

ser cargado en memoria por un teléfono de gama baja, y lo suficientemente grande como para

no necesitar crear demasiados objetos del mismo tipo.

Tras verificar que la mayoría de teléfonos con pantallas de 128x160 pixeles cargaban sin

demasiados problemas imágenes del mismo tamaño que su pantalla, se decidió generar estas

imágenes a 130x165 pixeles, es decir, ligeramente más grandes que la pantalla, para que en el

peor de los casos sólo se necesitasen cuatro imágenes simultáneamente cargadas en memoria.

Figura 41, Figura 42, Figura 43 y Figura 44: Secciones de mapa


45

3.2 Algoritmos, operaciones a bajo nivel, y buenas prácticas

Como se ha comentado al inicio de este bloque, la optimización en JavaMe solía ser dura. Sin

embargo también era, en general, necesaria. Algunas técnicas de optimización comunes a

otros lenguajes y plataformas que funcionaban bien en JavaMe eran:

Cargar de cada paquete o librería, sólo lo necesario (evitar el “.*”).

Usar siempre el algoritmo más eficiente.

Hacer uso intensivo de variables locales.

Pasar el menor número de parámetros posibles a métodos y constructores.

No hacer comparaciones entre String si pueden ser entre int.

Etc.

Otras técnicas de optimización más comunes en JavaME y que dan una idea del nivel al que

debía llegarse, pueden ser:

Evitar el uso de clases internas e interfaces en la medida de lo posible, aunque esto sea

contrario a las buenas prácticas de Ingeniería del Software.

Usar métodos finales y estáticos siempre que sea posible.

Si hay que hacer muchas divisiones por un mismo número, precalcular la inversa de

ese número y realizar multiplicaciones.

Usar desplazamiento de bits en vez de dividir o multiplicar por potencias de dos.

Intentar hacer comparaciones con 0 frente a otros números.

Usar StringBuffer en vez de String.

Si no es necesario, no refrescar toda la pantalla. Usar setClip() para actualizar zonas.


46

3.3 Arquitectura de aplicaciones y escalabilidad

A otro nivel de abstracción, y tan importantes como la optimización del código vista en

apartados anteriores, encontramos problemas que tienen que ver más con la organización de

clases y paquetes o la gestión a nivel lógico de los mismos.

Debido al ciclo de vida de una aplicación JavaME (MIDlet), una buena manera de abordar su

gestión es pensar en ella como una máquina de estados[56], donde cada estado realiza una

serie de operaciones y finalmente devuelve el control.

Figura 45: Código control de estados

Este modelo es perfectamente compatible con otras estrategias como la separación por capas

(en concreto se solían usar Presentación, Lógica de negocio y Persistencia conformando un

MVC[57] clásico), así como la aplicación de Patrones de diseño.

Entre ellos uno muy útil fue Singleton[58] aplicado a los elementos de tipo Mapa, debido a que

la construcción de un objeto de esta clase era muy costosa en recursos, y podía ser requerido

desde diferentes partes (menús) de la aplicación en cualquier momento, sin saber en el punto

de llamada si ya había una instancia en memoria de ese tipo o no, y debiendo garantizar que

no se generaba más que una, so pena de desperdiciar un gran volumen de memoria.

Otro muy práctico fue Facade[59], sobre todo a la hora de lidiar con el API de comunicaciones

Bluetooth ofrecido por JavaME (JSR82[60]). Se implementó un pequeño paquete con varias

clases que permitieron abstraerse y encapsular la complejidad de este API, reduciendo el

número de llamadas, su secuenciación, operaciones, comprobación de resultados, etc.


47

Observer[61], para la gestión de los cambios que debían producirse cuando un usuario pulsaba

un comando o un área táctil de la pantalla de su teléfono móvil. Muy relacionado con los

objetos de tipo Listener[62] que también pueden encontrarse en Objective-C y similares.

Factory Method[63] y Abstract Factory[64], usados a la hora de internacionalizar las aplicaciones,

y combinados con la carga dinámica de clases en tiempo de ejecución, permitieron usar sólo la

memoria necesaria para la clase con el idioma seleccionado por el usuario.

Figura 46: Código de Factory Method y Abstract Factory

Strategy[65], a la hora de dibujar diferentes textos sobre la pantalla en bajo nivel (Canvas),

encapsulando el algoritmo de dibujado (tipografía, maquetado, interlineado, etc.) y

permitiendo intercambiar fácilmente entre un algoritmo y otro.

De hecho, los objetos de tipo “Tipografía” solían generarse por composición de otros objetos

más pequeños, como los responsables de interpretar los caracteres ASCII de entrada y

devolver las imágenes correspondientes a cada carácter, o los responsables del algoritmo de

dibujado. El uso de composición frente a herencia, en la medida de lo posible, dio siempre

buenos resultados.

Flyweight[66], en aplicaciones como Metro Madrid donde existían varios cientos de nodos,

permitiendo crear sólo un objeto de tipo Nodo e intercambiando sus valores, simulando la

existencia de cientos de objetos, pero consumiendo mucha menos memoria.


48

4 Monetización de aplicaciones

“¿Cuánto puede ganarse con una aplicación para móvil?”. Esa es una pregunta bastante difícil

de responder y que ha variado significativamente en los últimos quince años. Lo que es

indudable es que el desarrollo del sector ha traído consigo nuevas oportunidades de negocio y

ha devuelto un modelo de desarrollo que no se veía desde los años 80’.

A día de hoy, pequeños equipos de programadores trabajando desde sus garajes han

conseguido publicar aplicaciones con millones de descargas en diferentes plataformas y con

millones en beneficios.

El día en que Apple publicó su App Store, un año después de lanzar el primer iPhone, cristalizó

un modelo que permitió democratizar como nunca antes el desarrollo y distribución de

Software para teléfonos móviles.

Siendo justos y haciendo honor a la verdad, no puede decirse que Apple inventase las tiendas

de aplicaciones. Sin embargo y como en otros muchos escenarios conjugó todas las variables

que hicieron posible que el modelo funcionase.

Volviendo a la triste realidad de JavaME, al no existir puntos centralizados de consumo de

Software, tampoco existía un escaparate lo suficientemente atractivo como para alentar a los

desarrolladores a publicar.

Además, estos puntos de distribución, como las empresas que se encontraban tras los

anuncios de televisión que invitaban a mandar un SMS con una palabra clave, solían tener

acuerdos comerciales que escandalizarían a cualquier desarrollador actual. (Hasta el 90% de

beneficios para la empresa de distribución, frente al 30% de Apple, Google o Microsoft).

Sin embargo, posiblemente la mayor barrera para conseguir una buena monetización a través

de la venta vía “Store” o televisión era la nula cultura de consumo de hacerlo. Para muchos

usuarios un teléfono móvil era como una caja negra en la que venían de serie unas

aplicaciones preinstaladas, y dos o tres años después, cuando ese teléfono se dejaba de usar,

lo hacía con exactamente esas mismas aplicaciones.

Los pocos usuarios intrépidos que sí se animaban a descargar aplicaciones por diferentes

medios, normalmente se echaban atrás al comprobar lo tedioso de los pagos vía móvil no

Smartphone. Procesos complejos e interminables, percibidos muchas veces como inseguros,

donde se debía insertar el número de tarjeta de crédito en cada compra, o exponerse al

excitante momento de abrir la factura de teléfono una vez al mes... y todo esto en un

escenario, repetimos, en el que la cultura del pago por contenidos era nula.

Por ello, el mejor modelo de monetización en JavaMe fue siempre el patrocinio. Aplicaciones

gratuitas para el consumidor, de descarga sencilla, impulsiva y en condiciones de proximidad

(Bluetooth), costeadas por anunciantes o administraciones públicas.


49

4.1 App Stores

A pesar del nefasto escenario descrito en el apartado anterior y de que el modelo de

distribución no terminó de cuajar, algunas tiendas de aplicaciones consiguieron resultados

moderadamente esperanzadores para algunos de sus desarrolladores.

Un ejemplo de ello es Nokia OVI Store[67], la tienda de aplicaciones para teléfonos Nokia. Otro

también muy conocido fue GetJar[68] y ya en nuestro país la famosa Softonic[69] con su sección

específica para teléfonos móviles.

Las estrategias que funcionaban bien en este tipo de tiendas siguen funcionando

perfectamente bien en las actuales, debiendo intentar siempre...:

Tener en la medida de lo posible una aplicación “rompedora”. Útil, entretenida, fácil

de usar... (qué fácil es escribirlo).

Pensar no sólo en lo que la aplicación hará por el usuario. También hay que tener en

cuenta qué le hará sentir durante su uso y cómo será el proceso de compra (correo de

bienvenida, feedback de refuerzo tras la compra, etc.)

Cuidar el apartado gráfico, usando recursos profesionales. Especial atención al icono

de la aplicación y a las capturas de pantalla que se publicarán en la tienda. Deben ser

lo más ilustrativas posible, así como las palabras clave que las acompañen.

Conseguir que diferentes blogs y publicaciones especializadas hagan un análisis de la

aplicación, regalando códigos promocionales si es necesario.

Obtener puntuaciones positivas tan pronto como sea posible. Pedir si hace falta a

familiares y amigos que descarguen la aplicación y voten positivamente.

Si se va a hacer algún tipo de inversión en publicitar la aplicación, usar todo el

presupuesto concentrándolo en pocos días, en vez de gastar el mismo dinero a lo largo

de varias semanas.

Este modelo de venta, junto con el de descarga directa patrocinada vía Bluetooth, suponía uno

de los modelos más viables de obtener un retorno de inversión por nuestro trabajo. Aparte de

ellos es interesante citar...:

Las ventas In-App, o realizadas desde dentro de la propia aplicación. Por ejemplo,

compra de niveles extra para un juego.

Publicidad y banners, como los usados por Google, con pago por clic o por visión.

Ventas indirectas, como programas de afiliación o por reporte de datos y uso.

SMSs Premium, caso que se analiza en detalle en el siguiente apartado.


50

4.2 SMSs Premium o de tarificación adicional

Debido a las limitaciones asociadas a los feature phones[70] con soporte JavaME, resultaba

difícil obtener ingresos mediante los citados banners y similares, ya que la mayoría de ellos no

tenían asociada una tarifa de datos que el usuario pudiese utilizar, o directamente la

navegación se realizaba mediante “portales” específicos de la operadora como Movistar

Emoción o Vodafone live! confundiendo más aún al usuario.

En este escenario, un recurso interesante era el alta de números de tarificación adicional a los

que enviar mensajes, como el conocido “7777”. El usuario realizaba el pago de manera sencilla

y transparente y la complejidad técnica era soportada por el operador, a cambio de un

porcentaje que podía estar situado en torno al 60% del coste del mensaje.

La combinación de Marketing de proximidad Bluetooth, aplicaciones JavaME y pago por SMSs

resultó razonablemente rentable, destacando los proyectos en los que se buscaba un factor

emocional que estimulase la toma de decisión de enviar el SMS por impulso.

En el correspondiente a las siguientes imágenes, se expusieron tres vehículos de alta gama en

otros tantos centros comerciales de nuestro país. Al acercarse al vehículo cualquier usuario

podía recibir en su teléfono una mini aplicación muy sencilla, parecida a un pase de

diapositivas, invitando al usuario a participar en el sorteo de esos vehículos.

Por sorteo entre todos los SMSs recibidos

Al que más SMSs enviase

Premio directo durante la promoción

Se fomentaba la participación por impulso ya que el usuario no debía ir al menú de “Nuevo

mensaje”, escribir el número, recordar la palabra clave, etc. Nada de eso. Simplemente pulsar

el botón intermitente “Enviar” y listo. Fácil.

Para aquellos usuarios que no tuviesen un teléfono móvil con Bluetooth, siempre se colocaba

cartelería adicional de refuerzo con información de la campaña.

Figura 47, Figura 48 y Figura 49: Aplicación SMS Premium Mercedes


51

Siguiendo el mismo sistema pero con fines no tan lucrativos, se desarrollaron campañas para

diferentes ONGs donde el importe del SMS era entregado integro a las mismas. De nuevo, el

“no dejar que el usuario tuviese que pensar” en ir a su aplicación de mensajes, escribir, etc.

hacía que la participación se disparase.

Figura 50, Figura 51 y Figura 52: Aplicación SMS Premium GaÏnde

En la campaña correspondiente a las anteriores imágenes, tras la donación se enviaba al

usuario un SMS de confirmación agradeciéndole su participación y proporcionándole feedback

de refuerzo tras su envío, con la frase “Gracias. Tú sí estás vivo”.

Por último y relacionados con los anteriores, aunque fuera ya del tema de este apartado, se

mostrarán algunos proyectos en los que el coste del mensaje era gratuito para el usuario,

como la campaña del Gobierno de La Rioja “Tinforma”. La aplicación servía tanto de catálogo

de servicios de la administración regional, como de plataforma de alta sencilla.

Figura 53, Figura 54 y Figura 55: Aplicación SMS Tinforma


52

En la siguiente aplicación, para el Servicio Riojano de Salud, se facilitaba al usuario pedir cita

previa, guardando sus datos de paciente permanentemente de una solicitud a otra y

generando el SMS por él, ocultando la complejidad de escribir el mensaje:

nº de paciente + fecha (dd/mm/aaaa) + palabra clave (CITAENF|CITAMED|etc...)

Figuras 56, Figura 57 y Figura 58: Aplicación SMS Cita previa


53

4.3 Programación Cross-Platform

En apartados anteriores se han detallado diferentes técnicas para garantizar la compatibilidad

entre familias de dispositivos de una misma plataforma, JavaME, sobre todo en lo relativo a

tamaños de pantalla, códigos numéricos de los teclados, capacidad de proceso, etc.

Sin embargo y aunque JavaME disponía de una buena parte de la cuota de mercado móvil,

seguía habiendo muchas otras plataformas...y muy poco tiempo para desarrollar. En ocasiones

el contexto de despliegue era tan específico, y alejado de JavaME, que se hacían necesarias

nuevas estrategias de desarrollo y puesta en producción.

Imaginemos por ejemplo una feria profesional donde la mayoría de sus visitantes utilizan

dispositivos Blackberry. Ese es un buen escenario en el que monetizar todo el Know How de

una empresa en desarrollo móvil, aun no siendo su núcleo de negocio Blackberry, como era

nuestro caso.

Una estrategia de desarrollo “Cross-Platform” implica desarrollar aplicaciones para diferentes

plataformas, que posiblemente usen diferentes lenguajes de programación y SDKs. En este

tipo de escenarios la primera decisión que hay que tomar evidentemente es qué plataformas

se van a abordar...y esto, para bien o para mal, muchas veces está definido por el cliente.

Después de esto, la siguiente decisión a tomar es qué estrategia Cross-Platform propiamente

dicha se va a abordar:

Soporte directo: Disponer de diferentes programadores especializados en diferentes

plataformas (JavaMe, iOS, Android, Windows Phone[71], etc.). La opción más costosa en

recursos pero con mejores resultados de integración y experiencia de usuario.

Uso de tecnologías Web: Se basa en el hecho de que la mayoría de las plataformas

disponen de algún tipo de intérprete o navegador Web, con soporte para HTML, CSS o

JavaScript. La idea es desarrollar la aplicación como una página Web y embeberla

dentro de un contenedor que pueda ejecutarse en la plataforma, como Phone Gap o

Sencha[72].

Es fácil encontrar programadores con estos conocimientos, el desarrollo es rápido y la

compatibilidad alta, aparte de la velocidad a la que HTML 5 se está desarrollando. Sin

embargo, la usabilidad y el rendimiento son relativamente pobres y el acceso al

Hardware del dispositivo muchas veces limitado (GPS, cámara, acelerómetro, etc.)

Cross-Compilation: La opción más compleja técnicamente pero con resultados más

esperanzadores. Consiste en desarrollar utilizando un lenguaje (Java, C, JavaScript,

etc.) y mediante un motor de recompilado, transcribirlo a los lenguajes de las

plataformas de destino.


54

Ventajas: La velocidad de ejecución es idealmente la misma que en una aplicación

escrita desde el primer momento de forma nativa y el acceso a los recursos Hardware

es, en teoría, completo.

Desventajas: El uso de las palabras “idealmente” y “en teoría” en el párrafo anterior.

En muchos casos los resultados no se ajustan a la realidad publicitada por el

fabricante, y el número de excepciones que hay que plantear en el código incrementan

exponencialmente la complejidad de su escritura y mantenimiento (“Si es iOS, haz A, si

es Android, haz B, si es Windows Phone, haz C...”).

Algunas herramientas para JavaME destacadas en esta categoría son Bedrock[73], de la

empresa Metismo, y Celsius[74] de la empresa Mobile Distillery.

Partiendo de otros lenguajes destaca Titanium [81], SDK que permite el desarrollo en

HTML 5, CSS y JavaScript (como Sencha) pero que en lugar de empaquetar el código en

un contenedor compatible con la plataforma de destino, lo “traduce” a código de cada

plataforma, consiguiendo actualmente algunos de los mejores resultados del mercado.

Figura 59: Prensa. Funcionarios usando mayoritariamente BlackBerry y pacientes usando JavaME.

Un buen escenario donde aplicar estrategias Cross-Platform


55


56

5 Conclusiones

Como se ha visto en este documento, en la mayoría de las ocasiones no se ha seguido la típica

estructura de un post mortem de “Qué ha ido bien – Qué ha ido mal”, sino más bien “¿Qué

hemos tenido que dejar por el camino para que todo salga razonablemente bien?”

Durante todos los años de explotación del proyecto, posiblemente la mayor dificultad radicó

siempre en ponderar las necesidades de negocio con las posibilidades técnicas, al tiempo que

se intentaba llegar siempre al mayor número de usuarios posible...algo que no siempre fue

fácil.

Los primeros años del negocio que trajo asociado JavaME fueron un caos desorganizado, como

casi siempre que irrumpe una nueva tecnología en el mercado. Sin embargo de entre ese caos

fue posible generar proyectos rentables y mantener en nómina a cinco personas durante casi

seis años.

Ahora son muchas las personas que se preguntan “¿Qué plataforma aprender, Android o

iOS?”. Quizás la pregunta debería ser “¿Sigue mereciendo la pena aprender desarrollo para

dispositivos móviles ahora que todo el mundo está haciendo lo mismo, en un mercado maduro,

sí, pero altamente competitivo?”.

Cuando la programación para dispositivos móviles comienza a ser una commodity y es

relativamente sencillo encontrar buenas factorías de Software hacia las que externalizar la

parte de implementación, puede ser el momento de elevar el nivel de abstracción y

desplazarse hacia especialidades dentro del ámbito móvil como la consultoría, estrategia,

Experiencia de Usuario (UX) etc.

A partir de este punto de la memoria, se va a dejar parcialmente de lado su naturaleza post

mortem, para realizar un breve análisis del estado actual del mercado, y reflexionar sobre qué

nos espera del mismo en el futuro.

Breve análisis del ecosistema de desarrollo móvil (5.1)

¿Qué plataforma elegir? (5.2)

Júpiter y más allá del infinito (5.3)


57

5.1 Breve análisis del ecosistema de desarrollo móvil

Renovar la confianza depositada durante el Proyecto Fin de Carrera original en JavaME o no.

Esa fue la primera decisión a tomar en 2006 cuando se comenzó con el desarrollo de proyectos

en la empresa privada.

En aquel momento el ecosistema móvil estaba totalmente fragmentado: JavaME, Symbian,

Flash Lite[75], BlackBerry, Windows Mobile[76], BREW[77]...aunque la percepción era que en pocos

años el mercado se polarizaría hacia dos, o como mucho tres competidores.

Siete años después, toda una vida tecnológicamente hablando, muchas de las plataformas

citadas anteriormente han desaparecido (como en el caso de Flash Lite o BREW), o se han

tenido que reinventar (como BlackBerry y Windows Mobile). Otras han irrumpido con fuerza

tal es el caso de Android, iOS, Qt[78] o HTML5, por lo que el número de alternativas es a día de

hoy, igual o mayor que hace unos años.

Sin embargo, y aunque todo

parece indicar que en este

ecosistema acabarán impo-

niéndose dos, o como mucho

tres competidores, el autor

no puede más que dudar de

esto tras lo vivido los últimos

años en las anteriores gene-

raciones.

En el momento de escribir

estas líneas, Android es la

plataforma dominante en el

mercado con diferencia, al

menos en cuanto a cuota de

mercado y número de

terminales vendidos. Con

seguridad a lo largo del

próximo año superará al

resto de plataformas en

número de aplicaciones

disponibles y número de

descargas.

Por otra parte, iOS sigue imbatible en el segmento de las Tablets, con unas cifras de

fidelización por parte de sus usuarios muy por encima de cualquier otro sistema y con una

empresa a sus espaldas, Apple, con capital suficiente como para seguir compitiendo muchos

años más.

Otros pesos pesados están obteniendo resultados esperanzadores, como Microsoft o RIM con

su rediseñado BlackBerry 10. ¿Dónde estará cada uno de ellos dentro de siete años?

Figura 60: Plataformas de desarrollo (“Mobile Developer’s Guide”)


58

5.2 ¿Qué plataforma elegir?

Difícil pregunta para la que no hay una respuesta definitiva. Posiblemente primero se deberían

plantear otras como “¿Qué pretendo conseguir?”. “¿Soy un futuro desarrollador o una

empresa?”. “¿Cuáles son mis puntos fuertes y débiles?” etc.

Desde el punto de vista empresarial y de negocio, Android se perfila como una de las

plataformas más atractivas debido al volumen de cuota de mercado que está obteniendo,

principalmente a costa de otras plataformas que como en el caso de iOS, siguen creciendo en

ventas pero no al mismo ritmo que su competidor.

Desarrollar para Android supone con seguridad llegar al mayor número de usuarios posible,

pudiendo conseguir numerosas descargas con relativa facilidad.

Una de las principales desventajas de desarrollar para Android es la brutal fragmentación de la

plataforma. Menos de un 20% de dispositivos incorporan la última versión del sistema

operativo, siendo las actualizaciones en muchos casos lentas o inexistentes.

Esto implica aumentar notablemente el número de versiones de nuestra aplicación,

desplegables, etc. y eso sin contar formatos de pantalla y otro Hardware (como sucedía en

JavaME).

Además, la fragmentación en la plataforma Android se da también en las tiendas de

aplicaciones, fragmentándose así el público objetivo, teniendo que hacer un mayor número de

despliegues, innumerables acuerdos de licencia con terceras partes, etc.

El discutible caos de la principal tienda, Google Play, dependiente de la propia Google, sus

problemas persistentes con las búsquedas y etiquetado de aplicaciones, el prácticamente nulo

filtrado de contenidos, bajo nivel de muchas de sus aplicaciones y sobre todo, poca cultura del

pago por contenidos de sus usuarios, hacen que la monetización de aplicaciones sea algo

complicada.

Complicada, aunque posible. Quizás una de las mejores fórmulas que pueden funcionar a este

respecto es la publicidad desde dentro de la aplicación (usando por ejemplo Google

AdWords[79]).

La segunda opción lógica a tener en cuenta es probablemente iOS. La App Store de Apple es a

día de hoy el mejor escaparate comercial del mundo. Esto supone claramente un arma de

doble filo ya que si bien todos los usuarios de iOS atienden al mismo foco, conseguir atención

en este escenario es muy complicado.

Sin embargo una de las mayores ventajas es que el usuario medio de iOS descarga más

aplicaciones de pago que el de Android. Aunque esto es alentador, las probabilidades de

hacerse rico con una aplicación en iOS siguen siendo menores que las de ganar la lotería.

Otra de las principales ventajas de desarrollar para iOS (y sin extendernos mucho ya que no es

el objetivo de la presente memoria), es el control de la fragmentación por parte de Apple. Esto

permite que muchas aplicaciones puedan ejecutarse en diferentes terminales sin problemas, y


59

que se pueda contar con que una amplia mayoría de los usuarios de la plataforma hayan

adoptado las últimas versiones del sistema operativo.

En general son pocas las empresas y desarrolladores que se plantean actualmente una tercera

vía de desarrollo nativo, sin embargo Windows Phone supone un mercado muy atractivo por

un motivo muy en particular.

Al ser una plataforma emergente, Microsoft está cuidando especialmente a su ecosistema de

desarrolladores, eliminando tantas barreras de entrada como le está siendo posible. Aunque

probablemente cambie en un futuro cercano, la competencia entre empresas y

desarrolladores en Windows Phone no es todavía demasiado agresiva.

Es posible por tanto, posicionarse como un referente en este mercado a nivel nacional o

incluso internacional, e intentar repetir fórmulas que funcionaron bien en otras plataformas

unos años atrás.

Aplicaciones de pájaros golpeando cerdos, linternas usando el flash de la cámara, niveladores

de burbuja...son ejemplos que ya están portados a la plataforma de Microsoft, pero ¿Cuántas

buenas aplicaciones aún no tienen equivalente y están esperando a que alguien las publique?

HTML es por su carácter multiplataforma ya comentado anteriormente una buena alternativa

a las tres ya vistas. Fácil de aprender y fácil de implementar, tanto por sí sólo vía Web como

empaquetado en un contenedor vía Sencha o similares.

A pesar de sus limitaciones, puede ser una buena solución de compromiso cuando los plazos o

presupuestos sean ajustados. De hecho, una buena idea puede ser, en caso de necesitar hacer

un lanzamiento multiplataforma, plantear la idea de cubrir el mayor número de terminales con

una Web HTML y combinarla con alguna opción nativa como iOS o Android, o incluso para

mercados emergentes como África o India una aplicación JavaME. Luego y en función del

feedback de los usuarios, se pueden plantear nuevas versiones nativas o cambios de

estrategia.

Figura 61: Características de cada plataforma (imagen de “Mobile Developer’s Guide)


60

5.3 Júpiter y más allá del infinito

Nos encontramos en plena era post-PC. Un escenario en el que las ventas de ordenadores

personales tradicionales caen año tras año en favor de los teléfonos móviles y Tablets, y donde

el uso de Software “tradicional” pierde peso frente a aplicaciones pequeñas, sencillas y

conectadas.

Como siempre que se intentan hacer predicciones, se cometen estrepitosos fracasos. Sólo nos

remitiremos al blog de uno de los diseñadores más premiados de los últimos años en cuanto a

prototipado de soluciones en el mundo de la movilidad.

El Blog de Mac Funamizu es a los dispositivos móviles, lo que “La psicología de los objetos

cotidianos” de Donald A. Norman[80] fue al diseño de interfaces gráficas. Una publicación

futurista, sea lo que sea lo que signifique esta palabra, además de inspiradora,

esperanzadora...

...y casi con toda seguridad, falsa.

Figura 62 y Figura 63: Geolocalización y búsqueda en Realidad Aumentada

Figura 64 y Figura 65: Información nutricional y texto para sordos en Realidad Aumentada

http://www.behance.net/mac_fun


61


62

6 Bibliografía

Java 2 Micro Edition – Manual de usuario y tutorial

Agustín Froufe Quintas, Patricia Jorge Cárdenes

Editorial Ra-Ma, 2004. ISBN: 8478973893

Mobile Developer’s Guide to the Galaxy

Varios autores

http://www.enough.de/products/mobile-developers-guide/ (Creative Commons)

The essential guide to user interface designs (second Ed.)

Wilbert O Galitz

Editorial Wiley, 2002. ISBN: 0471084646

User interface design for programmers

Joel Spolosky

Editorial Apress, 2001. ISBN: 1893115941

http://www.enough.de/products/mobile-developers-guide/


63


64

7 Glosario de términos

En el siguiente apartado se han excluido términos típicamente informáticos, como PC, Kb,

ASCII, Char, API, Thread, etc., entendiendo que ya forman parte del vocabulario común.

Aquellos otros que puedan no ser evidentes, o que el contexto de su cita merezca alguna

aclaración, referencia rápida o información adicional, sí se han incluido. Entre ellos...

Abstract Factory (ref. 64) Patrón de diseño. Contexto: Crear diferentes objetos, todos

pertenecientes a la misma familia. [Wikipedia]

Actual (ref. 20) Festival de música y cine realizado en Logroño, La Rioja, muy conocido por ser

el primero del año en España, celebrándose desde 1991 la primera semana de cada año.

[Wikipedia] [Web]

Agencia de Protección de Datos (ref. 24) Creada en 1993, es la entidad de control encargada

de velar por el cumplimiento de la Ley Orgánica de Protección de Datos de Carácter Personal

en España . Tiene su sede en Madrid y su ámbito de actuación se extiende al conjunto de

España. [Wikipedia] [Web]

Android (ref. 3) Sistema operativo basado en Linux, diseñado principalmente para móviles con

pantalla táctil como teléfonos inteligentes o tabletas inicialmente desarrollados por Android

Inc., que Google respaldó económicamente y más tarde compró en 2005. [Wikipedia]

App Store (ref. 37) Servicio para iPhone, el iPod Touch, e iPad, Mac OS X Snow Leopard y Mac

OS X Lion, creado por Apple Inc., que permite a los usuarios buscar y descargar aplicaciones

informáticas. [Wikipedia]

Apple (ref. 4) Empresa multinacional estadounidense con sede en Cupertino, California.

[Wikipedia]

Applet (ref. 45) Componente de una aplicación que se ejecuta en el contexto de otro

programa, por ejemplo en un navegador web. [Wikipedia]

http://es.wikipedia.org/wiki/Abstract_Factory

http://es.wikipedia.org/wiki/Actual_(festival)

http://www.actualfestival.com/

http://es.wikipedia.org/wiki/Agencia_Espa%C3%B1ola_de_Protecci%C3%B3n_de_Datos

https://www.agpd.es/portalwebAGPD/index-ides-idphp.php

http://es.wikipedia.org/wiki/Android

http://es.wikipedia.org/wiki/App_store

http://es.wikipedia.org/wiki/Apple_Inc

http://es.wikipedia.org/wiki/Applet


65

Base64 (ref. 51) Sistema de numeración posicional que usa 64 como base. Es la mayor

potencia de dos que puede ser representada usando únicamente los caracteres imprimibles de

ASCII. [Wikipedia]

Bedrock (ref. 73) Plataforma de desarrollo Cross-Platform basada en Java y desarrollada por la

empresa Metismo. [Wikipedia Inglés]

BlackBerry (ref. 36) Línea de teléfonos inteligentes desarrollada por la compañía canadiense

Research In Motion o RIM. [Wikipedia]

Bluegiga (ref. 15) Empresa finlandesa ubicada en Espoo fundada en el año 2000 y dedicada a

diferentes tipos de tecnología inalámbrica. [Web]

Bluetooth Marketing (ref. 17) Consistente en la distribución inalámbrica de contenidos

publicitarios informativos en un lugar determinado. Los contenidos pueden ser recibidos en

ese espacio por aquellos que dispongan de un teléfono móvil o equipo receptor con Bluetooth.

[Wikipedia]

Bluetooth (ref. 13) Especificación industrial para Redes Inalámbricas de Área Personal (WPAN)

que posibilita la transmisión de voz y datos entre diferentes dispositivos mediante un enlace

por radiofrecuencia en la banda ISM de los 2,4 GHz. [Wikipedia]

BREW (ref. 77) Binary Runtime Environment for Wireless es una plataforma de desarrollo de

aplicaciones móviles para teléfonos celulares creada por Qualcomm. Actualmente es

soportada por teléfonos con tecnología CDMA. [Wikipedia]

C++ (ref. 11) Lenguaje de programación diseñado a mediados de los años 1980 por Bjarne

Stroustrup. La intención de su creación fue el extender al lenguaje de programación C con

mecanismos que permitan la manipulación de objetos. [Wikipedia]

Celsius (ref. 74) Plataforma de desarrollo Cross-Platform basada en Java y desarrollada por la

empresa Mobille Distillery [Web]

http://es.wikipedia.org/wiki/Base_64

http://en.wikipedia.org/wiki/Metismo

http://es.wikipedia.org/wiki/Blackberry

http://www.bluegiga.com/home

http://es.wikipedia.org/wiki/Marqueting_bluetooth

http://es.wikipedia.org/wiki/Bluetooth

http://es.wikipedia.org/wiki/Brew

http://es.wikipedia.org/wiki/C%2B%2B

http://www.mobiledgroup.com/


66

Clases (ref. 33) Usado en este contexto, refiere a Programación Orientada a Objetos.

[Wikipedia]

DJ Java Decompiler (ref. 48) Decompilador y desensamblador para Java que reconstruye el

código fuente original a partir de código intermedio. [Web]

Donald A. Norman (ref. 80) Profesor emérito de ciencia cognitiva en la University of California,

San Diego y profesor de Ciencias de la Computación en la Northwestern University. Centrado

principalmente en la usabilidad. [Wikipedia]

El Corte Inglés (ref. 21) Primer grupo de distribución de España y el número 40 del mundo por

volumen de ventas con numerosos centros comerciales en nuestro país. [Wikipedia]

Facade (ref. 59) Patrón de diseño. Motivado por la necesidad de estructurar un entorno de

programación y reducir su complejidad con la división en subsistemas, minimizando las

comunicaciones y dependencias entre éstos. [Wikipedia]

Factory Method (ref. 63) Patrón de diseño. Consiste en utilizar una clase constructora (al estilo

del Abstract Factory) abstracta con unos cuantos métodos definidos y otro(s) abstracto(s): el

dedicado a la construcción de objetos de un subtipo de un tipo determinado. [Wikipedia]

Feature phone (ref. 70) Teléfono móvil cuyo precio se sitúa en un rango medio-bajo del

mercado, o sus capacidades son limitadas o básicas, en contraposición con los Smart Phone.

[Wikipedia Inglés]

Flash Lite (ref. 75) Entorno de ejecución creado por Adobe para dispositivos móviles, usando

formato SWF. [Wikipedia]

Flyweight (ref. 66) Patrón de diseño. También conocido como “Objeto ligero” sirve para

eliminar o reducir la redundancia cuando tenemos gran cantidad de objetos que contienen

información idéntica, además de lograr un equilibrio entre flexibilidad y rendimiento (uso de

recursos). [Wikipedia]

http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos

http://www.neshkov.com/dj.html

http://es.wikipedia.org/wiki/Donald_Norman

http://es.wikipedia.org/wiki/El_Corte_Ingles

http://es.wikipedia.org/wiki/Facade_(patr%C3%B3n_de_dise%C3%B1o)

http://es.wikipedia.org/wiki/Factory_Method_(patr%C3%B3n_de_dise%C3%B1o)

http://en.wikipedia.org/wiki/Feature_phone

http://es.wikipedia.org/wiki/Adobe_Flash_Lite

http://es.wikipedia.org/wiki/Flyweight_(patr%C3%B3n_de_dise%C3%B1o)


67

GetJar (ref. 68) Tienda de aplicaciones independiente fundada en Lituania en 2004.

Proporciona más de 350.000 aplicaciones para diferentes plataformas como JavaME,

Blackberry o Symbian. [Wikipedia Inglés]

Google AdWords (ref. 79) es el programa que utiliza Google para ofrecer publicidad

patrocinada a potenciales anunciantes. [Wikipedia]

Google Play (ref. 38) Google Play Store o sólo Google Play (antes llamado Android Market) es

una tienda de software en línea desarrollada por Google para los dispositivos Android.

[Wikipedia]

GSM/GPRS (ref. 25) Sistemas estándar, libres, para telefonía móvil digital. [Wikipedia]

Hardware (ref. 8) Refiere a todas las partes tangibles de un sistema informático; sus

componentes son: eléctricos, electrónicos, electromecánicos y mecánicos. [Wikipedia]

Heap (ref. 55) En la asignación de memoria basada en heap, la memoria es asignada desde un

gran área común de memoria libre (sin usar) llamada heap (también llamada almacén de

libres). [Wikipedia]

HTC Sense (ref. 29) Interfaz gráfica desarrollada por HTC Corporation para dispositivos móviles

que ejecuten el Sistema Operativo Android, Brew o Windows Mobile. [Wikipedia Inglés]

HTC (ref. 28) Anteriormente High Tech Computer Corporation, es un fabricante de

Smartphones taiwanés. La compañía inicialmente hacía dispositivos basados en el sistema

operativo Windows Mobile de Microsoft. En 2009 empezó a equipar sus terminales con

Android y a partir de 2010 también con Windows Phone. [Wikipedia]

Human Interface Guidelines (ref. 41) Conjunto de documentación y recomendaciones sobre

desarrollo de Software, centrado principalmente en la interfaz de usuario. [Wikipedia Inglés]

http://en.wikipedia.org/wiki/Getjar

http://es.wikipedia.org/wiki/Adwords

http://es.wikipedia.org/wiki/Google_Play

http://es.wikipedia.org/wiki/GSM

http://es.wikipedia.org/wiki/Hardware

http://es.wikipedia.org/wiki/Asignaci%C3%B3n_din%C3%A1mica_de_memoria#Asignaci.C3.B3n_de_memoria_basada_en_Heap

http://en.wikipedia.org/wiki/Htc_sense

http://es.wikipedia.org/wiki/HTC

http://en.wikipedia.org/wiki/Human_interface_guidelines


68

IEEE (ref. 34) Leído i-e-cubo en España, corresponde a las siglas de (Institute of Electrical and

Electronics Engineers) en español Instituto de Ingenieros Eléctricos y Electrónicos, una

asociación técnico-profesional mundial dedicada a la estandarización, entre otras cosas.

[Wikipedia]

iOS (ref. 2) Sistema operativo móvil de la empresa Apple Inc. Originalmente desarrollado para

el iPhone (iPhone OS), siendo después usado en dispositivos como el iPod Touch, iPad y el

Apple TV. [Wikipedia]

JAR (ref. 31) Por sus siglas en inglés, Java Archive, es un tipo de archivo que permite ejecutar

aplicaciones escritas en el lenguaje Java. Los archivos JAR están comprimidos con el formato

ZIP y cambiada su extensión a .jar [Wikipedia]

Java EE (ref. 10) Java Platform Enterprise Edition o Java EE (anteriormente conocido como Java

2 Platform Enterprise Edition o J2EE hasta la versión 1.4) traducido informalmente como Java

Empresarial, es una plataforma de programación—parte de la Plataforma Java—para

desarrollar y ejecutar aplicaciones en el lenguaje de programación Java. [Wikipedia]

JavaME/MIDP 2.0 (ref. 30) Mobile Information Device profile o MIDP (JSR 118) es una versión

de J2ME (Java 2 Micro Edition) integrada en el Hardware de celulares relativamente modernos

que permite el uso de programas Java denominados MIDlets. [Wikipedia]

Java SE (ref. 9) Java Platform Standard Edition o Java SE (conocido anteriormente hasta la

versión 5.0 como Plataforma Java 2 Standard Edition o J2SE), es una colección de APIs del

lenguaje de programación Java. [Wikipedia]

JSR82 (ref. 60) Especificación J2ME para un conjunto de APIs inalámbricas Bluetooth.

[Wikipedia Inglés]

Auguste Kerckhoffs (ref. 49) 19 de enero de 1835 – 9 de agosto de 1903. Lingüista y

criptógrafo holandés. [Wikipedia]

http://es.wikipedia.org/wiki/IEEE

http://es.wikipedia.org/wiki/IOS_(sistema_operativo)

http://es.wikipedia.org/wiki/Java_Archive

http://es.wikipedia.org/wiki/Java_EE

http://es.wikipedia.org/wiki/MIDP

http://es.wikipedia.org/wiki/Java_SE

http://en.wikipedia.org/wiki/JSR_82

http://es.wikipedia.org/wiki/Auguste_Kerckhoffs


69

Linux (ref. 16) Es un núcleo libre de sistema operativo basado en Unix. Uno de los principales

ejemplos de Software libre. Licenciado bajo la GPL v2 está desarrollado por colaboradores de

todo el mundo. [Wikipedia]

Listener (ref. 62) Objeto que mantiene una serie de relaciones con otros, llamados “sujetos”,

que notifican sus cambios al “observador/escuchador” (Listener). [Wikipedia]

Logs (ref. 19) Registro oficial de eventos durante un rango de tiempo en particular. Usado para

registrar datos o información sobre quién, qué, cuándo, dónde y por qué un evento ocurre

para un dispositivo en particular. [Wikipedia]

LOPD (ref. 23) La Ley Orgánica 15/1999 de 13 de diciembre de Protección de Datos de Carácter

Personal (LOPD), tiene por objeto garantizar y proteger, en lo que concierne al tratamiento de

los datos personales, las libertades públicas y los derechos fundamentales de las personas

físicas. [Wikipedia]

MAC Bluetooth (ref. 22) Identificador de 48 bits (6 bloques hexadecimales) que corresponde

de forma única a una tarjeta o dispositivo de red. Se conoce también como dirección física, y

es única para cada dispositivo. [Wikipedia]

Máquina de estados (ref. 56) Modelo de comportamiento de un sistema con entradas y

salidas, en donde las salidas dependen no sólo de las señales de entradas actuales sino

también de las anteriores. [Wikipedia]

Máquina Virtual de Java (ref. 27) En inglés Java Virtual Machine (JVM) es una máquina virtual

de proceso nativo, es decir, ejecutable en una plataforma específica, capaz de interpretar y

ejecutar instrucciones expresadas en un código binario especial (el bytecode Java), el cual es

generado por el compilador del lenguaje Java. [Wikipedia]

Metro (ref. 43) Interfaz de usuario del Sistema Operativo Windows Phone, de Microsoft.

[Wikipedia]

Mobile Marketing (ref. 1) La actividad dedicada al diseño, implantación y ejecución de

acciones de márketing realizadas a través de dispositivos móviles. [Wikipedia]

http://es.wikipedia.org/wiki/Linux

http://en.wikipedia.org/wiki/Observer_pattern

http://es.wikipedia.org/wiki/Log_(registro)

http://es.wikipedia.org/wiki/LOPD

http://es.wikipedia.org/wiki/Direccion_MAC

http://es.wikipedia.org/wiki/Maquina_de_estados

http://es.wikipedia.org/wiki/Maquina_virtual_java

http://es.wikipedia.org/wiki/Windows_Phone#Interfaz_de_usuario

http://es.wikipedia.org/wiki/Marketing_m%C3%B3vil


70

MVC (ref. 57) Patrón o modelo de abstracción de desarrollo de software que separa los datos

de una aplicación, la interfaz de usuario, y la lógica de negocio en tres componentes distintos.

[Wikipedia]

Nexus (ref. 42) Línea de dispositivos móviles que utilizan el sistema operativo Android

producido por Google en colaboración con diferentes fabricantes de Hardware. [Wikipedia]

NoIP (ref. 18) DNS dinámico es un sistema que permite la actualización en tiempo real de la

información sobre nombres de dominio situada en un servidor de nombres. [Wikipedia]

Nokia OVI Store (ref. 67) Tienda de aplicaciones de Nokia, lanzada en Mayo de 2009, desde la

que descargar música, aplicaciones, videos, imágenes y otro contenido. [Wikipedia]

Objective-C (ref. 44) Lenguaje de programación orientado a objetos creado como un

superconjunto de C para que implementase un modelo de objetos parecido al de Smalltalk.

[Wikipedia]

Observer (ref. 61) Patrón de diseño. Define una dependencia del tipo uno-a-muchos entre

objetos, de manera que cuando uno de los objetos cambia su estado, notifica este cambio a

todos los dependientes. [Wikipedia]

PNGGauntlet (ref. 54) Optimizador de imagines sin pérdida de calidad. [Web]

Profiler (ref. 53) En ingeniería de software el análisis de rendimiento, comúnmente llamado

profiling, es la investigación del comportamiento de un programa de computadora usando

información reunida desde el análisis dinámico del mismo. [Wikipedia]

Qt (ref. 78) Biblioteca multiplataforma ampliamente usada para desarrollar aplicaciones con

interfaz gráfica de usuario, sobre todo en dispositivos móviles. [Wikipedia]

http://es.wikipedia.org/wiki/Modelo_Vista_Controlador

http://es.wikipedia.org/wiki/Google_Nexus

http://es.wikipedia.org/wiki/DNS_din%C3%A1mico

http://en.wikipedia.org/wiki/Ovi_store#Ovi_Store

http://es.wikipedia.org/wiki/Objective-C

http://es.wikipedia.org/wiki/Observer_(patr%C3%B3n_de_dise%C3%B1o)

http://pnggauntlet.com/

http://es.wikipedia.org/wiki/An%C3%A1lisis_de_rendimiento_de_software

http://es.wikipedia.org/wiki/Qt_(biblioteca)


71

RAM (ref. 7) Memoria de acceso aleatorio (en inglés: random-access memory) utilizada como

memoria de trabajo para el sistema operativo, los programas y la mayoría del Software.

[Wikipedia]

Realidad Aumentada (ref. 14) Término que se usa para definir una visión directa o indirecta de

un entorno físico del mundo real, cuyos elementos se combinan con elementos virtuales para

la creación de una realidad mixta en tiempo real. [Wikipedia] [YouTube]

RGB (ref. 52) En Inglés Red, Green, Blue, en Español rojo verde azul) es la composición del color

en términos de la intensidad de los colores primarios de la luz. [Wikipedia]

ROM (ref. 6) La memoria de sólo lectura, conocida también como ROM (acrónimo en inglés de

read-only memory), es un medio de almacenamiento utilizado en ordenadores y dispositivos

electrónicos, que permite sólo la lectura de la información y no su escritura. [Wikipedia]

Scripts (ref. 35) Un guion, archivo de órdenes o archivo de procesamiento por lotes,

vulgarmente referidos con el término script, es un programa usualmente simple, que por lo

regular se almacena en un archivo de texto plano. [Wikipedia]

Sencha (ref. 72) Conjunto de herramientas de desarrollo de aplicaciones multiplataforma

basada en HTML 5 y JavaScript. [Web]

Singleton (ref. 58) Patrón de diseño. Su intención consiste en garantizar que una clase sólo

tenga una instancia y proporcionar un punto de acceso global a ella. [Wikipedia]

Smartphone (ref. 26) Un teléfono inteligente (Smartphone en inglés) es un teléfono móvil

construido sobre una plataforma informática móvil, con una mayor capacidad de almacenar

datos y realizar actividades semejantes a una mini computadora y conectividad que un

teléfono móvil convencional. [Wikipedia]

Softonic (ref. 69) Empresa fundada a comienzos de 1997 y perteneciente al Grupo Intercom. Su

sede se encuentra en Barcelona, España. [Wikipedia] [Web]

http://es.wikipedia.org/wiki/RAM

http://es.wikipedia.org/wiki/Realidad_aumentada

http://www.youtube.com/watch?v=MqXHRKAKZ1o&t=0m30s

http://es.wikipedia.org/wiki/RGB

http://es.wikipedia.org/wiki/ROM

http://es.wikipedia.org/wiki/Script

http://www.sencha.com/

http://es.wikipedia.org/wiki/Singleton

http://es.wikipedia.org/wiki/Smartphone

http://es.wikipedia.org/wiki/Softonic

http://www.softonic.com/


72

Strategy (ref. 65) Patrón de diseño. Permite mantener un conjunto de algoritmos de entre los

cuales el objeto cliente puede elegir aquel que le conviene e intercambiarlo dinámicamente

según sus necesidades. [Wikipedia]

Sun Microsystems (ref. 5) Empresa informática que se dedicaba a vender estaciones de

trabajo, servidores, componentes informáticos, software y servicios informáticos. Fue

adquirida en el año 2009 por Oracle Corporation. [Wikipedia]

SVG (ref. 32) Los Gráficos Vectoriales Redimensionables (del inglés Scalable Vector Graphics) o

SVG son una especificación para describir gráficos vectoriales bidimensionales, tanto estáticos

como animados (estos últimos con ayuda de SMIL), en formato XML. [Wikipedia]

Symbian (ref. 12) Sistema operativo que fue producto de la alianza de varias empresas de

telefonía móvil. Sus orígenes provienen de su antepasado EPOC32, utilizado en PDA's y

Handhelds. [Wikipedia]

Thawte Consulting (ref. 46) Empresa especializada en certificados de seguridad digitales por

Internet. Thawte fue fundada en 1995 por Mark Shuttleworth en Sudáfrica y ahora es una de

las mayores empresas en su sector. [Wikipedia] [Web]

Titanium (ref. 81) SDK multiplataforma para el desarrollo de aplicaciones móviles, que toma

como código de partida HTML 5, CSS y JavaScript y lo traduce a código nativo Objective-C, Java,

.NET, etc. [Web]

User agent (ref. 40) Cuando un usuario accede a una página web, la aplicación generalmente

envía una cadena de texto que identifica al agente de usuario ante el servidor. Este texto

forma parte del pedido a través de HTTP y generalmente incluye información como el nombre

de la aplicación, la versión, el sistema operativo, idioma, dispositivo, etc. [Wikipedia]

Verisign (ref. 47) Empresa de seguridad informática famosa por ser una autoridad de

certificación reconocida mundialmente. Emite certificados digitales RSA para su uso en las

transmisiones seguras por SSL, principalmente para la protección de sitios en Internet en su

acceso por HTTP. [Wikipedia] [Web]

http://es.wikipedia.org/wiki/Strategy_(patr%C3%B3n_de_dise%C3%B1o)

http://es.wikipedia.org/wiki/Sun_Microsystems

http://es.wikipedia.org/wiki/Svg

http://es.wikipedia.org/wiki/Symbian

http://es.wikipedia.org/wiki/Thawte

http://www.thawte.com/

http://www.appcelerator.com/platform/titanium-sdk/

http://es.wikipedia.org/wiki/User_agent

http://es.wikipedia.org/wiki/Verisign

http://www.verisign.es/


73

WAP (ref. 39) Wireless Application Protocol o WAP (protocolo de aplicaciones inalámbricas) es

un estándar abierto internacional para aplicaciones que utilizan las comunicaciones

inalámbricas, p.ej. acceso a servicios de Internet desde un teléfono móvil. [Wikipedia]

Windows Mobile (ref. 76) Sistema operativo móvil compacto desarrollado por Microsoft, y

diseñado para su uso en teléfonos inteligentes (Smartphones) y otros dispositivos móviles.

[Wikipedia]

Windows Phone (ref. 71) Sistema operativo móvil desarrollado por Microsoft, como sucesor

de la plataforma Windows Mobile. A diferencia de su predecesor, está enfocado en el mercado

de consumo generalista en lugar del mercado empresarial. [Wikipedia] [Web]

Winzip (ref. 50) Compresor de archivos comercial que funciona en Microsoft Windows,

desarrollado por WinZip Computing (antes conocido como Nico Mak Computing). Puede

manejar varios formatos de archivo adicionales. Es un producto comercial con una versión de

evaluación gratuita. [Wikipedia] [Web]

http://es.wikipedia.org/wiki/Wap

http://es.wikipedia.org/wiki/Windows_Mobile

http://es.wikipedia.org/wiki/Windows_Phone

http://www.windowsphone.com/es-es

http://es.wikipedia.org/wiki/Winzip

http://www.winzip.com/win/es/index.htm


74

Anexo A: Actas de reunión

Número de acta 1

Fecha 11 de Diciembre de 2012

Lugar Edificio Vives, Universidad de La Rioja

Hora de inicio/fin 17:00 – 17:45

Asistentes D. Eloy Mata y D. David Contreras

Orden del día Planificación

Temas tratados Formato de la memoria.

Implementación del proyecto.

Entregables.

Conclusiones y decisiones No habrá implementación.

La memoria se ajustará a las 50 p.

Se describirá el proyecto anterior y se finalizará la memoria con algunas reflexiones útiles de cara al futuro.

Número de acta 2

Fecha 25 de Enero de 2013




Orden del día Estado actual de la memoria

Temas tratados Introducción y conclusiones

Formato

Posibilidad de defender el trabajo en Febrero.

Conclusiones y decisiones El progreso es el adecuado

Se intentará terminar la memoria en Febrero por motivos personales del alumno, aunque se defenderá en convocatoria ordinaria.

Número de acta 3

Fecha 28 de Mayo de 2013




Orden del día Aprobación de la memoria y ensayo de la presentación

Temas tratados Revisión de la documentación, formato, etc.

Ensayo general de la defensa.

Conclusiones y decisiones Todo preparado para el depósito y la defensa.

Aprobación para depósito.


75

análisis post mortem del pfc 'sistema de … · de 160kb de rom[6] [7]y 32kb de ram), que...

Documents