análisis post mortem del pfc 'sistema de … · de 160kb de rom[6] [7]y 32kb de ram), que...
TRANSCRIPT
![Page 1: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/1.jpg)
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
![Page 2: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/2.jpg)
© 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.
![Page 3: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/3.jpg)
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.
![Page 4: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/4.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
3
![Page 5: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/5.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 6: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/6.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 7: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/7.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 8: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/8.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 9: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/9.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 10: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/10.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
9
![Page 11: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/11.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 12: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/12.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
11
![Page 13: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/13.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 14: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/14.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 15: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/15.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 16: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/16.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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”)
![Page 17: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/17.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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”)
![Page 18: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/18.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 19: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/19.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 20: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/20.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
19
![Page 21: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/21.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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”.
![Page 22: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/22.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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)
![Page 23: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/23.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 24: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/24.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 25: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/25.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 26: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/26.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 27: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/27.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 28: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/28.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 29: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/29.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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].
![Page 30: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/30.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 31: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/31.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 32: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/32.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 33: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/33.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 34: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/34.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 35: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/35.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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)
![Page 36: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/36.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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”.
![Page 37: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/37.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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)
![Page 38: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/38.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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)
![Page 39: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/39.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 40: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/40.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 41: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/41.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 42: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/42.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 43: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/43.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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)
![Page 44: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/44.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 45: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/45.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 46: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/46.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 47: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/47.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 48: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/48.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 49: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/49.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 50: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/50.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 51: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/51.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 52: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/52.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 53: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/53.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 54: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/54.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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.
![Page 55: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/55.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 56: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/56.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
55
![Page 57: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/57.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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)
![Page 58: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/58.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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”)
![Page 59: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/59.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 60: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/60.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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)
![Page 61: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/61.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 62: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/62.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
61
![Page 63: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/63.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
![Page 64: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/64.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
63
![Page 65: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/65.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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]
![Page 66: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/66.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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]
![Page 67: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/67.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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]
![Page 68: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/68.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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]
![Page 69: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/69.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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]
![Page 70: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/70.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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]
![Page 71: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/71.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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]
![Page 72: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/72.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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]
![Page 73: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/73.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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]
![Page 74: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/74.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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]
![Page 75: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/75.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
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
Lugar Edificio Vives, Universidad de La Rioja
Hora de inicio/fin 11:00 – 11:30
Asistentes D. Eloy Mata y D. David Contreras
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
Lugar Edificio Vives, Universidad de La Rioja
Hora de inicio/fin 9:30 – 10:30
Asistentes D. Eloy Mata y D. David Contreras
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.
![Page 76: Análisis post mortem del PFC 'Sistema de … · de 160KB de ROM[6] [7]y 32KB de RAM), que tardó poco tiempo en extenderse al mercado de los teléfonos móviles donde tuvo bastante](https://reader031.vdocuments.mx/reader031/viewer/2022013007/5bc18ff309d3f2840b8cde1b/html5/thumbnails/76.jpg)
Análisis Post Mortem del PFC “Sistema de comunicaciones entre dispositivos inalámbricos”
75