Parte III - bibing.us.esbibing.us.es/proyectos/abreproy/11809/fichero/PARTE_3.pdf · En su modelo,...

Parte III

Diseño de la aplicación cliente.

Capítulo 7

Factores clave de diseño.

A la hora de diseñar un programa se necesita un objetivo que ayude a determinar las prioridadesformales del producto desarrollado. En el caso que nos ocupa se desea ante todo que LinceVisiónsea de la mayor calidad posible. La Organización Internacional para la Normalización, ISO (In-ternational Organization for Standardization), en la ISO 8402 de�ne la calidad como:

El conjunto de propiedades y características de un producto o servicio, que le con-�eren aptitud para satisfacer unas necesidades explícitas o implícitas.

Evaluar la calidad de una aplicación software no es sencillo, dada la subjetividad implícita en ladeterminación de las necesidades a satisfacer y la naturaleza cualitativa más que cuantitativa de laspropiedades y características que debe poseer un producto. Por ello se hace necesaria la de�niciónde una serie de características y propiedades base a partir de las cuales poder evaluar las distintascalidades de diferentes aplicaciones[1]. El ISO 9126 (basado en el modelo de McCall1), entreotras, suple esta carencia planteando así un modelo normalizado que permite evaluar y compararproductos sobre la misma base.

En el modelo McCall la calidad queda de�nida a un alto nivel de abstracción por seis carac-terísticas, todas ellas de�nidas en el estándar ISO 9126[3] de 1991:

1. Funcionalidad: Conjunto de características y capacidades del programa que satisfacen lasnecesidades declaradas o implícitas, así como la generalidad de las funciones entregadas y laseguridad del sistema global.

2. Usabilidad: Esfuerzo necesario para el uso y la valoración individual de tal uso, por partede un conjunto de usuarios, es decir, el esfuerzo necesario para aprender a operar con elsistema, preparar los datos de entrada e interpretar las salidas (resultados) de un programa.Esta característica incluye la documentación de la aplicación y la estética de la interfaz conel usuario.

3. E�ciencia: Es la relación entre el nivel de prestaciones de un sistema y el volumen derecursos utilizados en condiciones declaradas. Este punto se ocupa de características comola velocidad de procesamiento, el tiempo de respuesta, consumo de recursos, rendimientoefectivo total y e�cacia.

4. Portabilidad: Es la capacidad de un sistema para ser transferido de un entorno a otro.

1El modelo de calidad de McCall (1977) es uno de los más difundidos e importantes, ya que ha servido debase para otros modelos como el modelo de Boehm y el Software Quality Management (SQM) de Murine. Estemodelo (también conocido como el Modelo de General Electrics de 1977) fue presentado por Jim McCall[2] y suscolegas en 1977 y, como otros modelos contemporáneos, surgió de las fuerzas militares de EE.UU. Concretamentefue desarrollado por las Fuerzas Aéreas dentro del Departamento de Defensa y está dirigido principalmente a losdesarrolladores de sistemas y al proceso de desarrollo del sistema. En su modelo, McCall intenta crear un puentede unión entre los usuarios y los desarrolladores centrándose en un número de factores de calidad del software quere�ejan tanto el punto de vista del usuario como las prioridades de los desarrolladores.

96 Factores clave de diseño.

5. Mantenibilidad: Es el esfuerzo necesario para realizar modi�caciones especí�cas, en dondese incluye el esfuerzo necesario para localizar y arreglar un error en un programa. Estacaracterística es ampliable a la capacidad de ampliar el programa (expansibilidad).

6. Fiabilidad: Capacidad de un sistema para mantener su nivel de rendimiento y de cumplircon sus funciones con la exactitud requerida.

7.1. Funcionalidad

En el apartado �Objetivos� de la Introducción a LinceVisión en la parte primera, se comentarongrosso modo las principales funciones que tiene que ser capaz de desarrollar la aplicación. Acontinuación se presentan estas de forma pormenorizada, que van a condicionar sin duda el diseñodel software. Del mismo modo, también se comentarán aquellas funcionalidades que, a pesar de enun principio puede parecer que podrían ser ejecutadas por la aplicación debido a su naturaleza,por diversos motivos, ya sea bien por su plani�cación en una fase posterior a la de este proyecto,por su complejidad o bien por la falta de recursos, no se han desarrollado.

Las funciones que debe ser capaz de desarrollar la aplicación son:

1. Búsqueda de plataformas.

Consiste en la búsqueda a través de la JSR-272 de las distintas plataformas disponibles enemisión en la zona en la que el usuario se encuentra.

2. Presentación de plataformas.

Consiste en la presentación visual de la información de las distintas plataformas encontradas.

3. Selección de plataforma.

Consiste en la interacción de la aplicación con el usuario de forma que este pueda elegir unade ellas y su selección en el receptor a través de la JSR-272.

4. Búsqueda de ESGs.

Consiste en la búsqueda a través de la JSR-272 de las distintas guías de servicios disponiblesen emisión en la zona en la que el usuario se encuentra.

5. Presentación de ESGs.

Consiste en la presentación visual de la información de las distintas guías de servicios en-contradas.

6. Selección de ESG.

Consiste en la interacción de la aplicación con el usuario de forma que este pueda elegir unade ellas y su selección en el receptor a través de la JSR-272.

7. Lectura y presentación de la información sobre los distintos servicios de televisión presentesen la ESG.

Consiste en la obtención a través de la JSR-272 de la información acerca de los servicios detelevisión, en su almacenamiento para su posterior visualización a petición del usuario y lapresentación de esta información almacenada cuando el usuario así lo requiera.

8. Lectura de la información sobre los distintos eventos programados en la ESG.

Consiste en la obtención a través de la JSR-272 de la información acerca de los programasde televisión y en su almacenamiento para su posterior visualización a petición del usuario.

7.1 Funcionalidad 97

9. Presentación de la información sobre los distintos eventos programados procedente en laESG.

Consiste en la presentación visual de la información obtenida de los distintos programas detelevisión, para un servicio en particular y para varios servicios en forma de cuadro, es decir,la representación de la EPG (Electronic Program Guide).

10. Actualización automática de la información proveniente de la ESG.

Consiste en la recepción de los avisos de actualización procedentes de la JSR-272 y en lacaptura de la nueva información actualizada.

11. Presentación de la información actualizada.

Consiste en la actualización automática de la información presentada visualmente al usuario.

12. Selección y adquisición de un servicio de televisión.

Consiste en la sintonización de un canal de televisión en concreto a través de la JSR-272 yla adquisición del �ujo de audio/vídeo que por este se está emitiendo.

13. Presentación y cese de presentación de un servicio de televisión.

Consiste en la presentación al usuario del �ujo de vídeo que previamente se ha adquiridopara su visualización, así como su cierre cuando el usuario decida seleccionar otro canal orealizar otras actividades no relacionadas con el �ujo de vídeo.

14. Lectura de los servicios interactivos de televoto y link externo procedentes de la ESG y supresentación al usuario.

Consiste en la obtención a través de la JSR-272 de la información acerca de la interactividaddisponible en ese instante y en su disposición grá�ca en la pantalla. Los servicios interactivosa los que la aplicación dará soporte son:

Voto: Servicio interactivo que consiste en permitir al usuario elegir una opción entreun conjunto de ellas. Al usuario se le presenta un tema sobre el que votar y distintasrespuestas. Este elegirá una de ellas y la aplicación internamente procederá a registrarla elección del usuario en el servidor de votaciones. Este proceso de registro debe sertotalmente transparente al usuario independientemente de la vía de retorno de la quese haga uso para el registro, presentándole únicamente si el proceso de registro tuvoéxito o fracasó.

Link externo: Servicio interactivo en el que se envía una dirección web con una descrip-ción asociada y se muestra al usuario en forma de hipervínculo. El usuario, al pulsarsobre este, accederá a dicha dirección a través del navegador del terminal.

15. Ejecución de la funcionalidad de los servicios interactivos.

Es decir, permitir al usuario seleccionar una de las opciones y registrar la opción elegidahaciendo uso del canal de retorno en el caso del servicio de voto, o permitir al usuariocliquear sobre el hiperenlace y lanzar en el terminal el navegador web para acceder a sucontenido en el caso del servicio de link externo.

16. Lectura de los servicios de descarga y sus contenidos asociados procedentes de la ESG, asícomo su presentación al usuario.

Consiste en la obtención a través de la JSR-272 de la información acerca de los servicios dedescarga disponibles en ese instante y en su disposición grá�ca en la pantalla. Un serviciode descarga es un servicio de difusión en el que se está enviando, en vez de un �ujo multi-media basado en tiempo, un �ujo de datos correspondientes a �cheros de distintos formatos(imágenes, archivos de audio, etc.). Estos �cheros pueden adquirirse de la sesión FLUTEcorrespondiente en el �ujo IPDC que viene por la señal DVB-H y pueden almacenarse en eldispositivo móvil.


17. Descarga de los contenidos asociados a un servicio de descarga seleccionado.

Consiste en la adquisición de los archivos disponibles en el servicio de descarga seleccionadoa través de la JSR-272 y su almacenamiento en memoria no volátil en el terminal móvil. LaJSR-272 abstrae a la aplicación cliente del método de difusión utilizado, por lo que no seránecesario en ningún momento interaccionar con la sesión FLUTE en la que los contenidos seestán difundiendo.

18. Con�guración del cliente: plataforma por defecto y lenguaje.

Consiste en dar capacidad al usuario de con�gurar el cliente según sus preferencias. Enconcreto se implementa:

a) Posibilidad de cambiar el lenguaje de la aplicación a otro soportado por esta. Loslenguajes soportados son inglés y español.

b) Con�guración de una plataforma por defecto de forma que cada vez que el MIDlet selance no sea necesaria la búsqueda de las distintas plataformas disponibles, sino que seprocederá directamente a la selección de la plataforma de�nida por defecto.

Así mismo, no se pretende que sea parte de este proyecto la siguiente funcionalidad:

Cualquier tipo de elemento interactivo no referido en la lista anterior.

Selección de salto de vídeo en el tiempo por el usuario y obtención del vídeo a partir delmomento seleccionado.

Consiste en permitir al usuario seleccionar un momento en concreto del contenido mediamostrado y su presentación a partir del salto dado.

Grabación de vídeo.

Consiste en el almacenamiento en memoria local no volátil de la señal de vídeo que se estárecibiendo.

Programación de la grabación de vídeo.

Consiste en permitir al usuario la selección de un momento concreto a partir del cual seempezará a grabar un servicio determinado.

Grabación de vídeo programado.

Consiste en la grabación de vídeo a partir del momento en el que el usuario lo ha programado.En caso de no estar ejecutándose el MIDlet, este tendrá que autoejecutarse a través dePushRegistry2 para comenzar con la grabación.

Compra de servicios/paquetes de servicios.

Consiste en permitir al usuario la compra de un servicio o paquete de servicios determinadoy hacer uso de las habilidades de la JSR-272 para llevarla a cabo.

2PushRegistry es una librería presente en MIDP2.0 que permite que los MIDlets puedan ser lanzados automá-ticamente sin necesidad de ser inicializados por el usuario. PushRegistry introduce dos nuevas vías por las que unMIDlet puede ser activado:

� Activación causada por conexiones de red entrantes (por TCP, UDP o SMS).

� Activación causada por temporizadores.

El segundo caso sería el utilizado para la grabación de vídeo programado.

7.2 Usabilidad 99

7.2. Usabilidad

Se ha descrito la usabilidad como el esfuerzo necesario para aprender a operar con el sistema,preparar los datos de entrada e interpretar las salidas. Esta característica viene determinadaprincipalmente por la calidad de los elementos de entrada y salida así como de la interfaz grá�caque se le presenta al usuario.

En el caso de los dispositivos móviles, la usabilidad es un factor clave a la hora de diseñaruna aplicación, ya que se maximizan los problemas de interacción con el usuario debido a lasrestricciones en los elementos de entrada (teclado y/o pantalla táctil) y salida (pantalla), comotambién en la capacidad grá�ca del dispositivo, entendiéndose esta como los recursos disponiblesy el rendimiento del dispositivo para mostrar una interfaz grá�ca potente.

7.2.1. Operación con el sistema.

Para minimizar el tiempo de aprendizaje del funcionamiento de una aplicación, lo fundamentales que el usuario se encuentre con un sistema de funcionamiento conocido. Si la manera en la queel usuario va a interactuar con el sistema es la misma que en otros muchos sistemas, este sabrásin necesidad de más explicación cómo hacer uso de los elementos que componen la aplicación. Siademás los elementos y la información en la pantalla están distribuidos de una manera lógica yclara, el usuario encontrará la aplicación fácil e intuitiva de usar, que es la meta que se persigue.

La parte de la aplicación en la que se le muestra la información al usuario por pantalla, se esperaa que este dé instrucciones a través del teclado (o pantalla táctil) y se recogen estas peticioneses lo que se conoce como la interfaz grá�ca de usuario o GUI. En la actualidad la mayoría deGUIs siguen el paradigma WIMP3 o post-WIMP, los cuales se componen principalmente de lossiguientes elementos:

un puntero: en el caso de un dispositivo móvil este se corresponde con el teclado y/o pantallatáctil.

una ventana: el área donde se muestra en la pantalla la información. En nuestro caso será elárea de pantalla que controla la máquina virtual de Java.

menús: permiten al usuario ejecutar comandos seleccionándolos de una lista de opciones.En el dispositivo móvil esto se correspondería con la información mostrada en la llamadasoftBar, es decir, la barra horizontal en la parte inferior de la ventana (ver �gura 7.1).Generalmente suele haber dos menús, uno en la parte izquierda y otro en la derecha, loscuales se pueden seleccionar a través de las teclas de selección del terminal. Al seleccionarlos,el menú se despliega verticalmente hacia arriba, donde se muestran los distintos comandosseleccionables.

controles: también conocidos como widgets, muestran la información dispuesta de determi-nada manera, de forma que esta es cambiable por el usuario. La característica de�nitoriade un widget es proveer de un punto de interacción único en el cual se puede realizar unamanipulación directa de un tipo de datos dado. Los widgets son básicamente bloques deconstrucción que combinados en una aplicación contienen todos los datos procesados por laaplicación y la interacción disponible con estos datos. Los widgets se clasi�can en:

� Selección: Son elementos que permiten al usuario realizar cierta acción, como visionarotro tipo de información. Al interactuar con ellos, se lanza un evento que indica la

3WIMP ("window, icon, menu, pointing device" o �ventana, icono, menu, dispositivo puntero�), denota un estilode interacción usando estos elementos. Este estilo de interacción usa un dispositivo físico de entrada para controlar laposición del cursor y presenta la información organizada en ventanas y representada con iconos. Todos los comandosdisponibles se reunen en menús y se accionan con el dispositivo puntero. De esta manera se reduce la carga cognitivaque supone el recordar todas las posibilidades disponibles, reduciendo así el tiempo de aprendizaje.


Figura 7.1: Menús en una interfaz grá�ca.

naturaleza de dicha selección. Dentro de este grupo se enmarcan Botones (donde seincluyen las Cajas de comprobación4 y Botones circulares5), Listas, etc.

� Navegación: Permiten desplazarse a través de la información mostrada en pantalla. Eneste grupo se incluyen las Pestañas y la barra de desplazamiento (también conocidacomo scrollbar).

� Entrada de texto: Controles que permiten al usuario la inserción de información. Secompone de Cajas de texto y Áreas de texto.

� Salida: Muestran información. Aquí se encuentran las Etiquetas, Barras de progreso,Barras de estado, etc.

� Contenedores: Son controles que incluyen a otros controles. Se usan para mostrar in-formación al usuario (a veces en forma de pop-up) y obtener una respuesta en casose ser necesaria (contenedor modal). En esta categoría se enmarcan los Diálogos y lasVentanas modales (también llamados Diálogos modales).

Debido a que la mayoría de GUIs se construyen a partir de estos elementos, desarrollar la GUI dela aplicación haciendo uso de otros supondría un tiempo de aprendizaje mayor o incluso rechazopor parte del usuario ante la complejidad añadida a la interfaz, por lo que en pro de la usabilidadla GUI de la aplicación cliente DVB-H tendrá que seguir el paradigma WIMP.

En el apartado 5.2.1 del capítulo �JavaME� se indica que la librería LCDUI de Java proveede clases de ayuda para el desarrollo de interfaces grá�cas. También se vio que en tal librería sedistinguía entre dos tipos de GUIs: de bajo y de alto nivel. Es la GUI de alto nivel la apropiadasegún los requisitos de usabilidad que se acaban de comentar, ya que cuenta con widgets como losdescritos anteriormente.

7.2.2. Pantalla del dispositivo

La mayoría de los dispositivos móviles están equipados con pantallas de pocas pulgadas, menosde 2,56, aunque debido al aumento de prestaciones en los dispositivos móviles, como funcionalidadde cámara y multimedia, cada vez aparecen dispositivos con mayores pantallas como algunosdispositivos Samsung® y HTC® que disponen de 2,8� o el iPhone® de Apple® con 3,5�. En elcaso de nuestra aplicación no sería una asunción arriesgada considerar que los dispositivos en losque esta se va a ejecutar dispondrán de una pantalla grande, ya que son dispositivos preparadospara actuar como una televisión. Pero aún disponiendo de pantallas más grandes, estas siguen

4Check Box en inglés.5Radio Button en inglés.61 pulgada = 2,54 cm

7.2 Usabilidad 101

siendo lo su�cientemente pequeñas como para que sea necesario tener especial cuidado con estefactor en el diseño de la aplicación.

Colocar mucha información en la pantalla, atestarla de grá�cos o de información irrelevante enforma de texto sólo llevará a una aplicación de uso complejo para el usuario y propensa a errores.Reducir la cantidad de datos en pantalla y tener gran multitud de pantallas distintas produciránel mismo resultado en el usuario. Ambos casos hacen que el usuario no se siente cómodo utilizandola aplicación y no le guste usarla. La aplicación móvil debe diseñarse para que en la pantallaaparezca exactamente la información necesaria para completar la tarea que se esté realizando, lainformación super�ua y los grá�cos no deben incluirse.

7.2.3. Teclado del dispositivo

Del mismo modo que ocurre con las pantallas, los teclados de los dispositivos móviles no son losmás cómodos de utilizar. La mayoría de los dispositivos móviles tienen teclados de 12 botones porlo que realizar cualquier entrada de texto en este tipo de teclados llega a ser desesperante. Si enun ordenador se tiene de media 30 WPM (Words Per Minute, Palabras por Minuto), en tecladosde 12 botones se reducen a 8 WPM como mucho. Los smartphones y PDAs suelen disponer demicro teclados �qwerty�. Con este tipo de teclados se consigue una mayor velocidad de escritura,pero sigue siendo baja. En los dispositivos con pantalla táctil la estrategia suele ser mostrar enesta un teclado qwerty digital, de forma que se pueda pinchar sobre las teclas. De cualquier forma,la entrada de datos por teclado en un dispositivo móvil es lenta y complicada.

Así, durante el diseño es necesario tener en cuenta que la entrada de datos desde el tecladosiempre resultará muy pobre, por lo que debe evitarse en todo momento, salvo en casos impres-cindibles como introducir los datos de la plataforma por defecto. No se debe pedir al usuario queintroduzca datos cuyos valores están dentro de un conjunto conocido. Siempre que sea posiblese deben utilizar listas desplegables con las opciones, agrupar en botones de opción y presentarla ayuda que sea necesaria en cada pantalla en la que haya que introducir datos. Es convenientetambién anticiparse a posibles errores en la entrada de datos desde un teclado móvil. Por ejemplo,no se debe permitir a un usuario introducir caracteres alfanuméricos cuando se necesitan valoresnuméricos.

Afortunadamente dada la naturaleza de la aplicación la entrada por teclado no será un factorcrítico, limitándose esta a las teclas de navegación para seleccionar los distintos elementos en lapantalla.

7.2.4. Sistema de navegación

El diseño de navegación puede de�nirse como la colocación de la información en la aplicación(arquitectura de información) junto con los métodos necesarios para ir de una parte de la aplicacióna otra. El resultado es el sistema de navegación de la aplicación, que puede de�nirse como elconjunto de pantallas de la aplicación y los comandos/botones necesarios para ir de una a otra.El impacto del sistema de navegación en la complejidad y usabilidad de la aplicación es muysigni�cativo.

MIDP proporciona un mecanismo automático de desplazamiento por la pantalla cuando elcontenido no puede visualizarse completamente en la pantalla del dispositivo. Hay que mantenerun equilibrio entre el número de pantallas de una aplicación y el scroll de cada una. Para ello esnecesario conocer características como el número de líneas de texto que cabe en una pantalla y elnúmero de caracteres que cabe en cada línea. De manera general, si disponemos de unas unidadesmínimas de contenido será necesario conocer de qué modo encajan en la pantalla del dispositivo.

Debe evitarse en la medida de lo posible que aparezca esta característica automática cuando,por ejemplo, se le presentan al usuario una serie de opciones; dado que si se desplaza hacia abajose le forzará a memorizar la información de la parte superior y viceversa.

También es importante de�nir una pantalla principal para la aplicación, de modo que losusuarios tengan una referencia fácilmente identi�cable en el sistema de navegación. La estructurade la aplicación debe ser sencilla. Siempre que se pueda se deben agrupar submenús para que la


estructura no sea muy profunda. Además, hay que tener cuidado al incluir enlaces a otras pantallasde la aplicación, no es necesario que desde cualquiera de ellas se pueda ir a cualquier otra. Se suelecolocar un enlace a la pantalla principal en muchas de las pantallas y, en general, a la pantallacorrespondiente de nivel superior. Una estructura en árbol, con los cruces indispensables, suelecumplir las características necesarias.

Una acción indispensable en un sistema de navegación es la que permite volver a la pantallaanterior. Suele consistir en dar un paso atrás en el árbol.

La lista de comandos de cada pantalla debe ser coherente a lo largo de todas las pantallas dela aplicación. Por ejemplo, si se decide colocar en el menú de la pantalla principal el comando desalida en el último lugar, en el resto de pantallas en las que aparezca también debería ser el últimocomando.

7.3. E�ciencia

La capacidad de procesamiento de los dispositivos móviles es limitada, como en general casitodas las características que acompañan a los dispositivos de este tipo, por lo que hay que prestaratención a cualquier aspecto que pueda ayudar a mejorar la ejecución de la aplicación.

Ya que uno de los factores claves para conseguir una aplicación e�ciente es que esta dispongade una alta velocidad de procesamiento, la principal regla es mantenerla lo más simple posible. Sinembargo esto es contrario a la apariencia de la interfaz grá�ca, la cual, para ser lo más atractiva eintuitiva posible para el usuario, suele disponer de imágenes, transiciones y de elementos complejos,los cuales consumen bastantes recursos. Además, dada la naturaleza de la aplicación a desarrollar,cargada de funcionalidad, con un alto procesamiento en tiempo real y con consultas frecuentesa la información almacenada por la JSR-272, mantener la simplicidad de la aplicación es de porsí contraria a su espíritu. Además de disponer de un dispositivo potente con una alta velocidadde procesamiento y amplios recursos, habrá que buscar una solución de compromiso entre ambosextremos.

El rendimiento es de vital importancia y con el que hay que tener especial cuidado, sobre todosi se está utilizando la tecnología Java. A pesar de que JavaME está especí�camente diseñadopara este tipo de dispositivos con carencias, el hecho de tener una máquina virtual ejecutándoseralentiza la ejecución de cualquier aplicación, además de suponer una sobrecarga en el consumode recursos. De hecho, muchos son los autores que, en pro del rendimiento, recomiendan evitaresta tecnología y hacer uso de tecnología nativa para el desarrollo de aplicaciones, impresión másfundamentada aún teniendo en cuenta la defragmentación de dispositivos ya comentada. La reglageneral que se impone es la codi�cación del software en el lenguaje nativo (C++ si es Symbian,C# si se trata de Windows Mobile) del dispositivo al que la aplicación va dirigida. Sin embargohay ocasiones en las que, como la nuestra, JavaME se presenta como un requisito obligatorio, ocomo la única solución a la portabilidad de la aplicación. En este caso, hay ciertas medidas que sepueden tomar durante el desarrollo de la aplicación en Java para mejorar su rendimiento.

El tiempo de respuesta es otro de los factores que in�uyen en la e�ciencia de la aplicación.Es necesario prestar atención a las acciones que tardan un tiempo mayor de medio segundo. Suejecución debería realizarse en un hilo paralelo para no bloquear la interfaz con el usuario. Si,por ejemplo, se realiza una conexión a un servidor desde el mismo hilo que ejecuta el MIDlet yllega una llamada entrante, el usuario será incapaz de contestarla dado que no servirá de nadapulsar ninguna tecla. Si en la pantalla hubiera un comando para cancelar la operación de conexión,tampoco se podría acceder a él. En operaciones que duren más un segundo es necesario indicarlede algún modo al usuario que la aplicación está trabajando. Si piensa que la aplicación se haquedado colgada lo más probable es que intente apagarla. Para mantener al usuario informadose puede utilizar una animación o una barra de progreso. También resulta necesario proporcionarla opción al usuario de cancelar dicha operación. Al acabar operaciones largas se podría alertaral usuario con algún tipo de sonido o vibración: no es normal que un usuario pase más de diezsegundos mirando la pantalla si no contiene información útil para él.

7.3 E�ciencia 103

7.3.1. Medidas a tomar durante la fase de codi�cación para mejorar elrendimiento.

La manera de codi�car afecta al rendimiento de la aplicación. Se van a enumerar diversosconsejos prácticos a seguir durante la codi�cación. En realidad se trata buenas prácticas generales,a seguir en cualquier desarrollo Java, por lo que el cumplimiento de algunas no será del todo posibleen nuestra aplicación. En cualquier caso, siempre que sea posible, hay que intentar llevarlas a cabo.Con ello se pretende:

Disminuir el tamaño de la aplicación.

Para ello debe eliminarse de la aplicación todo aquello que no sea estrictamente necesario.

Aumentar la velocidad.

Es muy importante realizar una buena gestión de la memoria y optimizar las operaciones deentrada y salida.

Gestión de hilos.

La aplicación hace un uso extensivo de hilos, debido a la cantidad de procesos complejos llevadosa cabo de forma paralela. Algunos de estos procesos son:

Refresco de los componentes de la interfaz grá�ca y de la información mostrada en algunode ellos.

Realización de tareas pesadas como la adquisición del �ujo streaming de un servicio de tele-visión, la selección de una nueva ESG del �ujo de datos, cambio de plataforma, renderizaciónde la EPG, etc.

Consulta a bases de datos. No toda la información obtenida de la ESG se mantiene enmemoria volátil, por la escasez de este recurso, así que parte de dicha información se tieneque obtener en tiempo de ejecución a través de la JSR-272, lo que implica una consulta a subase de datos (presumiblemente en RMS).

Comunicaciones externas.

Acceso a información compartida para su actualización.

etc.

Por ello el seguimiento de las siguientes directivas no siempre será posible, pero si recomendable:

Muchos dispositivos no pueden trabajar con muchos hilos. Se debe conocer cuál es el límite.

No hay que abusar. Crear el mínimo número de hilos posible.

Si es posible, reutilizar en lugar de crear.

Intentar minimizar el uso de la clase Timer ya que crea un hilo extra. Si se usa se debe teneren cuenta al establecer el número de hilos que utiliza la aplicación.

No utilizar demasiado synchronized y evitarlo en bloques largos innecesarios. Ligeramentemejor sincronizar métodos que bloques de código.

Si se trabaja con varios hilos, hacer uso de la capacidad de dar prioridad.


Operaciones de entrada/salida.

Las operaciones de acceso al sistema de �cheros (JSR-75) y al sistema de almacenamientoMIDP RMS son muy lentas y consumen muchos recursos. Lo mismo ocurre congetResourceAsStream().

Al trabajar con RMS:

� Leer el registro entero a un bu�er y analizarlo después.

� Para escribir un registro, primero escribirlo a un bu�er y después al registro.

� Si es posible, almacenar en memoria los datos (caché).

Minimizar la cantidad de información que se trans�ere por la red. Si es posible, y no provocaque la aplicación se ejecute demasiado lenta, utilizar técnicas de compresión. En nuestraaplicación los intercambios de información por HTTP serán cortos y escasos.

Aunque no se trabaje con RMS, intentar almacenar datos en memoria siempre que tengasentido.

Limitación de tamaño en el �chero JAR.

Ficheros JAR de gran tamaño pueden no cargar.

Minimizar el número de clases, teniendo en cuenta el tamaño máximo permitido para cadaclase.

Cada clase o interfaz contribuye con, por lo menos, 250 bytes de sobrecarga después de lacompresión.

Eliminar las clases que no se estén utilizando.

Importar solo las clases necesarias.

Evitar la creación de interfaces en la medida de lo posible.

Usar nombres cortos para reducir el bytecode de cada clase.

Todo lo anterior se cumple en mayor o menor medida si se utiliza un ofuscador. Así que eluso del ofuscador es casi imprescindible.

Memoria Heap.

Máxima: Reducir, re-usar y reciclar.

Usar técnicas de pooling7 puede ser una buena opción.

No llamar explícitamente al recolector de basura, System.gc, ya que no se garantiza queeste vaya a ejecutarse.

Liberar los objetos referenciándolos a null.

Usar arrays en lugar de colecciones de objetos.

Si se usan la clase Vector o HashTable hay que intentar asignarles el tamaño correcto. Ambascrecen automáticamente cuando lo necesitan, por defecto en 100 unidades, probablementemás de lo necesario.

No iniciar los miembros de una clase a valores por defecto.

7Conjunto de objetos pre-instanciados que son requeridos bajo demanda. Al �nalizar su uso por la entidad quelo requirió, el objeto volverá al conjunto.

7.3 E�ciencia 105

Usar la clase Exception solo cuando sea necesario, dado que cada vez que se lanza una, secrea un objeto Exception.

Evitar el uso de getters y setters para obtener y dar valores a las variables de instancia.Además de optimizar la velocidad, disminuye el espacio requerido.

Variables.

Usar tipos escalares, siempre que sea posible, en lugar de objetos Java.

Usar variables locales, son más rápidas de acceder que los miembros de clase. Sin embargo,también es cierto que el paso de parámetros produce sobrecarga de la memoria.

Usar int en lugar de long cuando sea posible.

Evitar usar los objetos tipo Date, en su lugar es preferible trabajar con long.

Clase String:

� Tener cuidado al usar String, ya que las clases inmutables provocan mayor recogidadel recolector de basura, disminuyendo el rendimiento.

� Evitar la concatenación de cadenas. Su uso decrementa el rendimiento e incrementa lospicos de memoria. Usar en su lugar StringBuffer.

� Si se van a usar cadenas que no van a variar, es más óptimo usar variables estáticas(static) que constantes (final). Lo contrario es cierto para datos primitivos como unint.

Si se crea el siguiente objeto:

private static final String obj = "objeto";

Cada vez que se usa la constante se crea una instancia temporal de la cadena, mientrasque si simplemente fuera static, se crearía solo una vez.

APIs

Siempre que sea posible, usar o extender las clases de las APIs JavaME.

Si se encuentran problemas de rendimiento con un método dentro de una clase de la API,sobreescribirlo con una versión simpli�cada.

Algunas clases incluyen tantas características que suponen un problema de tamaño y rapidezde ejecución cuando solo se van a usar unas pocas características. En este caso convienesustituir los métodos de dichas clases por otros propios.

Otros.

En las comparaciones y condiciones es preferible comparar con 0, null o false.

Si una clase no se va a extender, declararla como �nal para que el compilador genere códigomás e�ciente.

Optimizar los bucles:

� No calcular el tamaño de algún objeto en la condición del bucle.

� Colocar los objetos invariantes y las cadenas literales fuera del bucle.

� Intentar reducir el número de iteraciones al mínimo.


Permitir habilitar y deshabilitar las líneas de debug.

Acceder a un array es costoso, más si es multidimensional. Los arrays multidimensionales sepueden optimizar volviéndolos unidimensionales.

Siempre que sea posible, utilizar funciones nativas. Por ejemplo, es más rápido usar arrayCopy()que un bucle para copiar arrays.

Cuidado al usar la recursividad. La clase ocupa menos pero también es mucho más lenta.

7.4. Portabilidad.

Teóricamente esta característica se ve solventada por el uso de Java. El concepto de máquinavirtual abstrae a cualquier aplicación de la plataforma sobre la que se va a ejecutar, consiguiendoasí la portabilidad total, en tanto en cuanto exista una implementación de una máquina virtualespecí�ca para la plataforma sobre la que se quiere ejecutar el MIDlet. Afortunadamente en laactualidad las principales plataformas poseen implementaciones de distintas KVM, por lo que estono es un problema.

En la práctica, sin embargo, nos encontramos con multitud de problemas que hacen que laportabilidad en Java no sea del todo universal. A continuación se procede a explicar esto con másdetalle.

7.4.1. Requisitos mínimos de la Máquina virtual a usar por LinceVisión.

Como se vio en la Introducción, uno de los objetivos principales de la aplicación es tener lacapacidad de instalación en cualquier dispositivo móvil sin tener que entregar distintas distribucio-nes, una para cada tipo de dispositivo, y sin necesidad de ninguna adaptación previa del softwaredistribuido. Es por ello que se eligió la tecnología Java para móviles JavaME, ya que a través dela máquina virtual de la que dispone, se consigue la �losofía WORA (Write Once, Run Anywhere)buscada.

Se vio en el capítulo �JavaME� que esta de�ne una serie de características comunes de lasque debe disponer la máquina virtual, a través de la llamada Con�guración y el llamado Per�l.Esto signi�ca que todas las implementaciones disponibles de la KVM de los distintos dispositivosserán idénticas en funcionalidad si implementan únicamente una determinada con�guración con undeterminado per�l. Sin embargo esta funcionalidad es mínima, a veces insu�ciente para el desarrollode aplicaciones móviles potentes y atractivas para el usuario, por lo que se hace necesario que lasdistintas implementaciones complementen esta máquina virtual básica con otras funcionalidadesque habiliten nuevas capacidades. Esto se consigue a través de librerías complementarias formandopaquetes opcionales. El conjunto de con�guración, per�l y paquetes opcionales, incluidos o no segúnel fabricante, es lo que se conoce como entorno de ejecución.

Como también se vio, Java especi�ca muchas de las APIs de librerías complementarias (en lasconocidas como JSRs o Java Speci�cation Requests), pero no su implementación interna ni su pro-fundidad de implementación. También los fabricantes deciden implementar sus propios paquetesopcionales sin seguir la especi�cación de la API en caso de haber una JSR equivalente para tal pa-quete, de forma que este paquete propietario implemente una nueva funcionalidad o complemente,mejore o sustituya la funcionalidad de una JSR de�nida por Java en caso de haberla.

Así surge el mayor problema con el que se encuentra JavaME, lo que se conoce con el nombrede fragmentación de dispositivos. Este término hace referencia a la existencia de determinadoselementos distintivos entre los distintos dispositivos que hacen que la ejecución de una determinadaaplicación en un dispositivo o en otro pueda variar enormemente, o incluso impedir su ejecución.Estos elementos son principalmente tres:

Diversidad de KVMs que encontramos en los distintos dispositivos, que no solo viene dadapor la inclusión o no de un determinado paquete, sino en la funcionalidad implementada en

7.4 Portabilidad. 107

la con�guración, en el per�l y en cada uno de esos paquetes y en la disponibilidad o no dedeterminados paquetes propietarios.

Diferentes características de pantalla.

Diferentes tipos de teclados.

Esta situación hace que se rompa con el paradigma WORA antes mencionado, privando a Javade su mayor virtud. Ya que con solo implementar la aplicación en JavaME no asegura que laaplicación cliente vaya a cumplir tal paradigma, se hace necesaria la de�nición de unos requisitosmínimos que debe cumplir el dispositivo sobre el cual la aplicación va a ejecutarse, sobre todoen lo relativo a las características de la máquina virtual que de�nirán el entorno de ejecución denuestra aplicación. En el cuadro 7.1 podemos ver estos requisitos.

Característica Descripción

CLDC1.1 Con�guración de JavaME.

MIDP2.0 Per�l de JavaME.

JSR-75Paquete opcional para el acceso a datos

almacenados nativamente.

JSR-135 Paquete opcional MMAPI (Mobile Media API ).

JSR-272

Paquete opcional que da soporte a los servicios

difundidos para terminales móviles. Este paquete

presupone la existencia de los paquetes anteriores.

Cuadro 7.1: Requisitos mínimos de la KVM del dispositivo.

Como las distintas implementaciones de la KVM presentan restricciones en las funcionalidadesde�nidas en los estándares de con�guración, per�l y paquetes JSRs, a continuación se detalla quécaracterísticas y elementos son completamente necesarios para el desarrollo de nuestro cliente:

En CLDC1.1: Afortunadamente en los dispositivos que encontramos hoy en día la con�gura-ción CLDC1.1 suele venir implementada en su totalidad. En cualquier caso, no puede haberninguna restricción en la implementación de:

� Re�exión: Necesaria para identi�car en algunas situaciones el tipo de objeto creado.

� Capacidad multihilo: Al realizar el cliente tareas que consumen muchos recursos, estasserán ejecutadas desde un hilo diferente al hilo principal (que controla los aspectos dela interfaz grá�ca), de forma que no bloqueen a la interfaz.

� Buen manejo de excepciones: La JSR-272 en particular lanza varias excepciones en casode error, por eso es obligatorio una buena gestión de estas por la máquina virtual.

En MIDP2.0: Al igual que en el caso de CLDC1.1, la implementación de MIDP2.0 suele sertotal en los dispositivos modernos. En el caso de no serlo, al menos debe encontrarse:

� LCDUI (Limited Connected Device User Interface): Al menos la parte de interfacesgrá�cas de bajo nivel. Necesaria para presentar la interfaz de usuario.

� GFC (Generic Connection Framework): Al menos la capacidad de establecer conexionesHTTP. Necesaria para permitir así la interactividad, una característica troncal delcliente.

� RMS (Record Management System): Necesario para almacenar la con�guración pordefecto.

Paquetes opcionales:


� JSR-75 y JSR-135: Debido a que la JSR-272 se basa en estos paquetes para su imple-mentación, debe estar presente la funcionalidad total. Esto implica que en la JSR-135(MMAPI) no solo debe estar implementada la funcionalidad de reproducción de audio,sino también la de vídeo.

� JSR-272: En la actualidad no son necesarios los paquetes:

◦ Paquete de compra javax.microedition.broadcast.purchase.

◦ Paquete de control javax.microedition.broadcast.control.

◦ Paquete de grabación javax.microedition.broadcast.recording.

El resto de paquetes sí son necesarios. Si se quiere implementar más funcionalidad enel futuro relacionada con el control y grabación del �ujo A/V, así como la compra depaquetes de servicios, estos paquetes serán necesarios.

Como requisitos deseables para un mejor funcionamiento de nuestra aplicación tenemos:

En CLDC1.1:

� JNI (Java Native Interface)8: Necesario para lanzar el explorador desde el MIDlet encaso de link interactivo.

En MIDP2.0:

� LCDUI: El estándar sólo obliga a dar soporte para imágenes de tipo PNG9 opacas,es decir, sin canal alfa (o alpha). Tanto para poder representar los logotipos de lasdistintas cadenas que llegan a través de IPDC, como para obtener una interfaz grá�camás atractiva para el usuario, sería deseable que LCDUI diera soporte a otros tiposMIME10 de imagen así como soporte al canal alfa. También es deseable el soporte deotros tipos de letra diferentes a la fuente propia del sistema, para hacer la GUI másactractiva al usuario.

Paquetes opcionales: Aparte de la implementación total de las JSRs anteriormente comen-tadas, otros paquetes deseables en el dispositivo serían los indicados en el cuadro 7.2.

Paquete Descripción. Motivo.

JSR-234

Paquete opcional AMMS

(Advanced Multimedia

Supplements).

Necesario si se quiere funcionalidad

de control y grabación sobre la señal

de vídeo mostrada.

JSR-205Wireless Messaging API

(WMA) 2.0

Necesario si se quiere interactividad

tipo voto por SMS.

Cuadro 7.2: Paquetes opcionales deseables en el dispositivo móvil.

A pesar de que no se puede asumir que la aplicación vaya a funcionar en cualquier dispositivo,la aplicación cliente tiene que intentar salvar todos los obstáculos anteriormente comentados en lamedida de lo posible de forma que el resultado �nal sea una aplicación lo más portable posible. Estose consigue mediante un buen diseño en el que se tomen determinadas soluciones de compromisoque redundarán en una aplicación de calidad.

8JNI es un framework de programación que permite que código Java que es esté ejecutando en una MáquinaVirtual Java llame o sea llamado por aplicaciones nativas y librerías escritas en otro lenguaje

9PNG (Portable Network Graphics) Speci�cation, Version 1.0. W3C Recommendation, October 1, 1996. http://www.w3.org/TR/REC-png.html. Also available as RFC 2083, http://www.ietf.org/rfc/rfc2083.txt.

10MIME (Extensiones de Correo de Internet Multipropósito) son una serie de convenciones o especi�cacionesdirigidas a que se puedan intercambiar a través de Internet todo tipo de archivos (texto, audio, vídeo, etc.) deforma transparente para el usuario. MIME está especi�cado en seis RFCs : RFC 2045, RFC 2046, RFC 2047, RFC4288, RFC 4289 y RFC 2077.

http://www.w3.org/TR/REC-png.html

http://www.w3.org/TR/REC-png.html

http://www.ietf.org/rfc/rfc2083.txt


7.4.2. MIDlets de con�anza vs MIDlets de no con�anza.

En el capítulo �JavaME� de la parte anterior, en la sección 5.1.3: �Seguridad en los MIDlets�, secomentó cuáles son los mecanismos de seguridad que JavaME de�ne para la protección del sistemaante infracciones. En esta sección se comentó que atendiendo a las características de seguridad delMIDlet, tendremos MIDlets que no sean de con�anza, sujetos unas restricciones de seguridad másestrictas, y otros de con�anza, los cuales podrán operar con más libertad (aunque siempre dentrode unos límites). A continuación se explica con más detenimiento en qué consiste cada uno de ellosy �nalmente se comentará en qué afecta esto a LinceVisión.

Paquetes MIDlet que no son de con�anza (Untrusted MIDlet suite).

Cualquier paquete MIDlet que no sea de con�anza para el dispositivo debe ser ejecutadocomo tal. Si en el proceso de veri�cación de la con�anza en un MIDlet ocurre algún error, debeser rechazado. Se debe ejecutar en un dominio de no con�anza, usando para ello un entorno deejecución restringido, en el que el acceso a APIs y funciones protegidas no está permitido o requierepermiso explícito del usuario.

El dominio de no con�anza debe permitir a los MIDlets no con�ables acceder sin pedir permisoal usuario al conjunto de APIs del cuadro 7.3.

API DESCRIPCIÓN

javax.microedition.rms Clases relacionadas con RMS.

javax.microedition.midletClases relacionadas con el ciclo de vida de un

MIDlet.

javax.microedition.lcdui Clases relacionadas con la interfaz de usuario.

javax.microedition.lcdui.game Clases relacionada con los juegos.

javax.microedition.media Relacionada con multimedia.

javax.microedition.media.controlRelacionada con los controles de reproducción

multimedia.

Cuadro 7.3: Dominio de no con�anza: Conjunto de APIs de obli-gado acceso sin pedir permiso al usuario.

Existen dos APIs cuyo acceso está permitido bajo petición explícita de permiso al usuario.Estas APIs son las que aparecen en el cuadro 7.4.

API DESCRIPCIÓN

javax.microedition.io.HttpConnection Protocolo HTTP.

javax.microedition.io.HttpsConnection Protocolo HTTPS.

Cuadro 7.4: Dominio de no con�anza: Conjunto de APIs que re-quieren permiso explícito del usuario.

Paquetes MIDlet de con�anza (Trusted MIDlet suite).

MIDP 2.0 introduce el concepto de aplicaciones de con�anza, y lo de�ne como:

Paquete MIDlet en el que el dispositivo puede con�ar, tras autenticar y veri�car laintegridad del JAR, y ligar a un dominio de protección. La seguridad para los MIDletsde con�anza se basa en dominios de protección.

Cada dominio de protección de�ne los permisos que deben concederse al MIDlet ligado a dichodominio. El dueño del dominio de protección especi�ca cómo el dispositivo identi�ca y veri�ca quepuede con�ar en un MIDlet y ligarlo a un dominio de protección con los permisos que autoricenel acceso a librerías API o funciones restringidas. Los mecanismos que el dispositivo utiliza para


identi�car y con�ar, o no, en un MIDlet se de�nen por separado. En la especi�cación se describe unmecanismo para identi�car MIDlets de con�anza basado en una Infraestructura de Clave PúblicaX.509 (X.509 PKI, Public Key Infraestructure).

Cuando un dispositivo determina que puede con�ar en un MIDlet, permite el acceso segúnla política del dominio. Un MIDlet que requiere acceso a APIs protegidas debe solicitar los co-rrespondientes permisos. Existen dos atributos según sea el permiso solicitado. En el cuadro 7.5aparecen.

CRITICIDAD ATRIBUTO DESCRIPCIÓN

Crítico MIDlet-PermissionsSin las APIs solicitadas en los permisos

no puede funcionar el MIDlet.

No crítico MIDlet-Permissions-Opt Puede funcionar con o sin ellas.

Cuadro 7.5: Permisos solicitados por un MIDlet.

Estos atributos contienen una lista de uno o más permisos separados por comas. Si aparecenen el descriptor, su valor debe ser idéntico al contenido en el �chero manifest.

El dispositivo tendrá de�nidos un conjunto de permisos por cada API o función cuyo acceso esterestringido. Además cada dominio de protección, formado por conjuntos especí�cos de permisosdel dispositivo, tiene dos tipos de permisos:

Allowed (permitido): Permisos que explícitamente permiten el acceso a una API o funciónprotegida y no requieren la intervención del usuario.

User (de usuario): Permisos que el usuario debe autorizar, cada uno con su forma de inter-accionar con el usuario.

Los permisos de usuario están de�nidos para permitir al usuario denegar o conceder permiso deacceso a una API especí�co. Los modos de interacción son los siguientes:

blanket: Válido para cualquier invocación de una API realizado por un MIDlet hasta quees desinstalado o el usuario decida cambiar los permisos.

session: Válido hasta que termina la sesión actual. La primera vez que se invoca la APIcorrespondiente se debe preguntar al usuario qué hacer (permitir o no). Tras reiniciar elMIDlet debe ocurrir lo mismo.

oneshot: Debe preguntar al usuario cada vez que se accede a la API o función protegida.

El conjunto de permisos de los que disfrutará la aplicación es la intersección de los requeridos porel MIDlet y los asignados por el dominio de protección. El proceso que se sigue para conceder lospermisos a un MIDlet se explica en la �gura 7.2.

Seguridad en LinceVisión.

Se ha visto que en los MIDlet de no con�anza no se permite el acceso a la gran mayoría de APIpor el peligro que ello supone. El acceso a otras API, sin embargo, es posible siempre y cuandoel usuario con�rme dicho acceso. Un ejemplo de este último caso son las comunicaciones HTTP.LinceVisión tiene la capacidad de establecer este tipo de comunicaciones para registrar votos en unservidor de voto HTTP. Esto quiere decir que cada vez que el usuario quiera registrar su voto, elsistema de seguridad de JavaME le va a preguntar si posibilita al MIDlet (es decir, a LinceVisión)establecer dicha comunicación. Este proceso de con�rmación recurrente es molesto y tedioso parael usuario, no bene�ciando en nada a la usabilidad de la aplicación, por lo que hay que evitarlo enla medida de lo posible.

Como también se ha visto la manera de evitarlo es haciendo que LinceVisión sea un MIDletde con�anza. Para ello es necesario ligar el MIDlet a un dominio de protección. MIDP 2.0 sugiereque los dominios estén basados en �rmas criptográ�cas y certi�cados de seguridad, es decir, la


Figura 7.2: Concesión de permisos a un MIDlet.

aplicación debe certi�carse y �rmarse. Esto implica la existencia de una autoridad de certi�caciónen la que el dispositivo confía. Un ejemplo de autoridad de cer�cación es VeriSign®11.

Es aquí donde empieza la problemática entorno al �rmado de MIDlets: no todos los dispositivosreconocen a las mismas autoridades de certi�cación. El hecho de certi�car y �rmar (previo pago)no implica que el MIDlet se vaya a considerar como de con�anza en todos los dispositivos, ya queeso dependerá de si dicho dispositivo confía en dicha autoridad o no. Muchos de ellos solo confíanen un número muy restringido de autoridades de certi�cación, lo que hace que la certi�caciónpara un terminal de un fabricante en concreto sea inútil para la práctica totalidad del resto determinales. Esta circunstancia es otro factor más que agrava el problema de fragmentación dedispositivos, haciendo que los MIDlets no sean totalmente portables entre distintos terminales dedistintos fabricantes.

Para evitar esto se creó un lugar único en el que las aplicaciones se pueden veri�car comono maliciosas y �rmar con un certi�cado cuya disponibilidad se garantiza en muchos entornos(½no todos!) de ejecución. El repositorio central es el Java Veri�ed Program12. Este repositoriopermite subir el MIDlet para proceder a realizarle una serie de pruebas automáticas, permitiendoelegir para qué dispositivos se desea pasar estas pruebas antes de permitir elegir a quién se deseaenviar la aplicación. Quienes se encargan de realizar estas pruebas son entidades comerciales conánimo de lucro. Esto conlleva pagar un precio de alrededor de 300$ por prueba, por dispositivo, loque implica que una aplicación como LinceVisión, que usa una API restringida y que se concibepara ser utilizada en todos los dispositivos, tendría que desembolsar una cantidad de alrededor de30000$[4], lo cual, además de salirse de presupuesto, choca de frente con la �losofía de código libre

11Website español: http://www.verisign.es/12Website: http://javaverified.com/

http://www.verisign.es/

http://javaverified.com/


a la que LinceVisión pretende adscribirse.Ante este panorama, en el que el proceso de certi�cación y �rma de un MIDlet (ya haga uso

del Java Veri�ed Program o no) sigue sin asegurar ni su usabilidad ni su portabilidad, y además serequiere un gran desembolso de dinero, se concluye que no merece la pena hacer que LinceVisiónsea un MIDlet de con�anza.

7.5. Mantenibilidad.

Para conseguir esta característica la mejor estrategia de diseño es la modularidad. Por mo-dularidad se entiende la separación de funcionalidades en distintas entidades (también llamadosmódulos) que desarrollan una función única y determinada y que se comunican entre sí según unainterfaz dada. Con esta separación conseguimos:

Facilidad en la adición de nueva funcionalidad, ya que solo habría que acoplar el nuevo o losnuevos módulos correspondientes y conectarlos con los ya presentes a través de sus interfaces.No haría falta, por tanto, realizar ningún cambio en los módulos anteriores para adaptarsea la nueva funcionalidad.

Mayor �abilidad, ya que es posible la realización de pruebas unitarias sobre cada uno delos módulos, así como pruebas de interconexión entre ellos, por lo que el resultado será uncódigo más libre de errores.

Facilidad en el aislamiento de un error. En caso de surgir, debido a la modularidad, será mássencillo �despegar� los elementos unos de otros para aislar el error. Además, la consola de lamáquina virtual de Java es una buena ayuda para depurar errores.

Es en esta sección, por tanto, donde se debe de�nir la arquitectura del software. Esta arquitecturadebe ser modular y para conseguirlo lo mejor es hacer uso de un patrón de diseño.

Los patrones de diseño son de�niciones de arquitectura de software probadas como la mejorsolución encontrada a un problema dado. Siempre y cuando el problema a resolver sea uno de losya resueltos por un patrón de diseño, se recomienda el uso de este patrón.

Para el caso de aplicaciones que disponen de una interfaz grá�ca de usuario en la que se muestracierta información obtenida de otro sistema (ya sea una base de datos local, un servidor externo,etc.) y sobre la que se aplica cierta lógica, el patrón de�nido es elModel-View-Controller13 (MVC).Este será por tanto el patrón arquitectónico que �ja la arquitectura global de la aplicación.

7.5.1. Modelo-Vista-Controlador.

El patrón MVC (�gura 7.3) tiene su origen en el patrónModels-Views-Controllers (10-Diciembre-1979), que a su vez deriva de Thing-Model-View-Editor (12 de Mayo de 1979). Ambos desarrolladosdentro del grupo de investigación y desarrollo Xerox PARC (Reenskaug, Trygve M. H.). Medianteeste patrón se consigue una separación entre la funcionalidad del núcleo del modelo de negocio, lacapa de presentación y la lógica de control que usan dicha funcionalidad.

Modelo. Representa los datos y las reglas de negocio para acceder o actualizar dichos datos.

Vista. Componente visual que presenta el contenido del modelo y recibe la entrada delusuario. Accede a los datos a través del modelo y especi�ca cómo deben mostrarse. Esresponsabilidad de la vista mantener la consistencia de la presentación cuando el modelocambia. Puede lograrse de dos maneras:

� Mediante técnicas push: la vista se registra en el modelo para que se le noti�quen loscambios.

13Modelo-Vista-Controlador en español.

7.5 Mantenibilidad. 113

� Mediante técnicas pull: la vista es responsable de invocar al modelo cuando necesitapresentar los datos más actualizados.

Controlador. El controlador traduce las interacciones con la vista en acciones que debellevar a cabo el modelo. Las acciones llevadas a cabo por el modelo incluyen la activaciónde procesos de negocio o el cambio de estado del modelo. Basándose en las interaccionesdel usuario y en el resultado de las acciones del modelo, selecciona la vista apropiada pararesponder a la interacción iniciada por el usuario.

Figura 7.3: Esquema conceptual del patrón Modelo-Vista-Controlador.

En ocasiones la separación entre Controlador y Vista no está siempre del todo clara. De hecho,el modelo original MVC prescribía un alto acoplamiento entre controladores y vistas. En algunoscasos puede incluso compensar el incluir las funciones del Controlador de la aplicación en la Vista,resultando un modelo híbrido.

La mayoría de librerías Java para la construcción de GUIs, como AWT, Swing o LCDUIpara interfaces de alto nivel se basan en un modelo MVC, donde la mayor parte de componentes(widgets) de interfaz tienen, además de una vista y un controlador asociado, un modelo de datospor defecto. Su programación por tanto es más sencilla, sin embargo es más complejo en estoscomponentes desacoplar la parte vista de la controladora.

En el caso de la presente aplicación, el patrón MVC se ha modi�cado para desacoplar casicompletamente las capas Modelo y Vista que interactúan a través del controlador y en generalnunca lo hacen directamente entre ellas. Además, en los casos en los que hablemos de un controladorde un widget, la parte controladora y la de vista se van a contener en la misma clase. Los paquetesque contienen las distintas clases correspondientes a cada uno de las entidades del modelo MVCen la aplicación son:

Modelo: es.us.esi.lynx.model

� es.us.esi.lynx.model.facade

Vista: es.us.esi.lynx.gui

� es.us.esi.lynx.gui.epg

� es.us.esi.lynx.gui.SouthContainers

Controlador: es.us.esi.lynx.control

Estos paquetes se comentarán con más detalles en las próximas secciones.

Bene�cios.

La separación entre los datos (Modelo) y la presentación de los mismos (Vista) permite disponerde multitud de vistas que dependen de un único modelo. Además permite cambiar la apariencia dela aplicación sin tener que realizar cambios en el modelo, aunque es posible que haya que realizarcambios en el controlador si se añaden nuevas vistas.


El �ujo de control de la aplicación (Controlador) se mantiene aislado del modelo y de la vista.Para determinar la funcionalidad de la aplicación es necesario explorar el controlador en primerlugar. Proporciona la capacidad de unir diferentes piezas existentes en el modelo para determinarnuevas funcionalidades y permite cambiar el �ujo de la aplicación sin tener que modi�car apenas elresto de capas. Si el modelo y la vista están perfectamente delimitados en módulos, estos se puedenver como bloques de construcción de servicios reutilizables por el controlador. El controlador puedecombinarlos para establecer nuevas funcionalidades.

La capa de presentación (Vista) no necesita conocer cómo se almacenan los datos ni la lógicade la aplicación (Modelo). No importa si los datos están almacenados localmente, en memoria oen algún lugar remoto, etc. Es el modelo quién determina de dónde debe obtener los datos. Laseparación entre capas permite que las tres capas de la aplicación se vean unas a otras como cajasnegras, cuyo funcionamiento está oculto a las demás, y permite construir interfaces bien de�nidasy componentes autocontenidos.

Inconvenientes.

Entre los inconvenientes de usar el patrón MVC se encuentra el hecho de que la cantidad decódigo programado se ve aumentada considerablemente. En dispositivos de capacidad limitada elaumento de líneas de código y el aumento del número de clases puede suponer un empeoramientodel rendimiento.

También es importante añadir que la utilización de este patrón no es simple. Se deben planearbien todos los detalles del modelo, la vista y el controlador para que dichas capas se encuentren lomás desacopladas posibles y la aplicación se bene�cie de las ventajas de utilizar el patrón MVC.

Si la aplicación solo dispone de dos pantallas es posible que la sobrecarga y di�cultad que con-lleva la utilización de este patrón no merezca la pena. Sin embargo, cinco pantallas y la posibilidadde que aumente el número de las mismas en un futuro son razones más que su�cientes para quevalga la pena su uso. En el caso de la presente aplicación el número de pantallas es de catorce(dieciséis si se cuentan los diálogos modales/no modales), con plani�cación de aumentarse, y bajoesta perspectiva el uso del patrón MVC está completamente justi�cado.

7.6. Fiabilidad.

La �abilidad, si bien es un aspecto importante en el desarrollo de cualquier aplicación, depen-diendo de su naturaleza será más crítica o no. En el caso en el que nos ocupa, en el que nuestraaplicación no trabaja con información sensible, es decir, no va a hacer uso de información per-sonal del usuario ni de información empresarial, sino que toda la información con la que trataes la recibida por la señal de difusión, la �abilidad no es uno de los factores claves. La principalpreocupación en cuanto a la �abilidad consiste en el buen funcionamiento de la aplicación dentrodel sistema operativo del dispositivo, de manera que esta no in�uya en ningún modo en el restodel sistema.

Afortunadamente la máquina virtual de Java se preocupa de que esto así sea. La KVM creaun entorno controlado en el que el MIDlet se va a ejecutar, por lo que no hay ningún peligro deque haya algún tipo de obstrucción al buen funcionamiento del resto del sistema por parte delMIDlet. Esto es así excepto en dos ocasiones: cuando se realiza algún acceso al sistema de �cherosa través de la JSR-75 y en el acceso a funcionalidades nativas a través de JNI. En la actualidad,nuestro MIDlet no hace uso de la JSR-75, aunque sí de JNI en el caso en el que se quiera lanzarel navegador para visitar un link interactivo. En este caso bastará con asegurarse en la fase depruebas de que el lanzamiento se hace correctamente.

Así que la �abilidad en LinceVisión viene dada básicamente por el buen funcionamiento interno,el cual se garantiza cumpliendo las siguientes directivas:

Al utilizar librerías externas, asegurarse de que estas son a su vez �ables.

En la actualidad la única librería que el MIDlet utiliza es la de ayuda de construcción dela GUI. La determinación del grado de �abilidad de la librería es subjetiva, ya que depende

7.6 Fiabilidad. 115

de la con�anza que se tenga en el desarrollador o la empresa desarrolladora así como de laaceptación de esta por la comunidad desarrolladora.

Manejo apropiado de las excepciones.

Hay que asegurarse de que todas las posibles excepciones son capturadas y tratadas apro-piadamente, en caso contrario podría producirse una situación de inconsistencia que podríadar lugar al bloqueo del MIDlet.

Control de situaciones de posibles bloqueos como en los casos de establecimiento de comu-nicaciones HTTP o SMS.

Estas conexiones se usarán cuando se quiera ejecutar un voto interactivo. Debido a que estascomunicaciones se quedan en situación de bloqueo en espera a establecer conexión con elservidor y de obtener respuesta a las peticiones, es necesaria la programación de timeoutspara el caso en el que estas situaciones no se produzcan.

Control de posibles situaciones de desbordamiento de memoria.

El desbordamiento puede producirse por dos motivos:

1. Por la no liberación de clases no utilizadas por el recolector de basura debido a quedichas clases están siendo referenciadas por otras a pesar de no necesitarlas más. Estecaso se evita monitorizando el consumo de memoria y la instanciación de clases conuna herramienta de depuración.

2. Por una instanciación masiva de objetos en determinados momentos de la ejecución delprograma al realizar tareas complejas. En este caso lo primero es tener en consideracióncuáles de estas tareas podría provocar un desbordamiento de memoria. Después hayque buscar posibles soluciones para evitar esta situación. En el caso concreto de laaplicación los casos más críticos se darán en:

� La representación la EPG. Será necesario obtener la información relativa a todoslos programas de todos los servicios disponibles y habrá que renderizarla en unacuadrilla, con toda la carga que esto implica.

� La reproducción de vídeo. El vídeo y audio en streaming necesita de un bu�erdonde se irá almacenando el contenido a mostrar al usuario. Aunque en principiola JSR-272 abstrae al MIDlet de toda la complejidad en la obtención del vídeo yaudio, descodi�cación, reservas de recursos, etc, será la aplicación la encargada deliberar los recursos reservados cada vez que el visionado de un vídeo y la audicióndel audio dejen de requerirse.

Capítulo 8

Diseño de la Interfaz grá�ca deusuario.

En el apartado 7.2.1 se vio que para obtener una aplicación de una alta usabilidad lo mejor esconstruir la GUI haciendo uso del paradigma WIMP. MIDP de JavaME provee de una librería,llamada LCDUI, en la que se incluyen componentes (o widgets) WIMP como son Botones, Diálogos,Listas, etc. A continuación se explica con más detenimiento en qué consiste esta librería. Tras suexplicación se comentará por qué, a pesar de lo dicho hasta ahora, esta librería no es la idónea paradesarrollar el cliente DVB-H, así que será necesario encontrar alternativas a LCDUI que sean lomás parecida posible a esta, ya que es a lo que el usuario está acostumbrado. Así, seguidamente sepresentarán diversas alternativas para el desarrollo de la interfaz grá�ca de usuario. Para �nalizarse detallará la librería que �nalmente se utilizará para realizar la GUI de LinceVisión.

8.1. LCDUI de MIDP.

LCDUI se basa en dos clases principales para controlar y visualizar las distintas pantallas quese le mostrarán al usuario. Estas clases son Displayable y Display.

La principal abstracción en la interfaz de usuario es el objeto Displayable (visible) perte-neciente al paquete javax.microedition.lcdui el cual encapsula los distintos grá�cos que sepresentan por pantalla, es decir, este objeto representa una abstracción de lo que el usuario va avisualizar por pantalla. Solo puede, por tanto, visualizarse un objeto Displayable a la vez, y elusuario solo puede interactuar con dicho objeto.

La clase Display es la que proporciona acceso a la pantalla física el dispositivo. Solo estápermitida una instancia de dicho objeto en cada MIDlet, por ello para acceder a dicha instanciase utiliza el patrón Singleton1. Siempre se debe recoger el objeto de tipo Display que gestiona loque muestra la pantalla del dispositivo:

Display myDisplay = Display.getDisplay(this);

La clase Display incluye una serie de métodos útiles para gestionar lo que se va a presentar en lapantalla del dispositivo y la interacción con el usuario. Los métodos más importantes de esta clasesirven para mostrar objetos Displayable en la pantalla física. Con el método setCurrent() sepuede cambiar la vista que actualmente está en pantalla. void setCurrent(Displayable next)esasíncrono por lo que la nueva pantalla no se muestra físicamente hasta que el hilo que maneja lainteracción con el usuario no está inactivo.

En la �gura 8.1 podemos ver grá�camente la jerarquía de clases, para comprenderlo mejor.Existen dos tipos de objetos Displayable:

1Restringe la creación de objetos de una clase a un único objeto. Para ello el constructor de la clase se especi�cacomo privado, siendo la propia clase la encargada de su instanciación y de proporcionar un método para obtenerdicha instancia.

118 Diseño de la Interfaz grá�ca de usuario.

Figura 8.1: Jerarquía de clases de la interfaz de usuario de MIDP.

Canvas: Objeto de bajo nivel que permite a la aplicación tener grá�cos y una serie deentradas.

Screen: Objeto de alto nivel que encapsula una interfaz de usuario completa.

En el primer caso, hablamos de interfaces de usuario de bajo nivel. En el segundo, de interfacesde usuario de alto nivel. En cualquier aplicación estos dos tipos de objetos pueden combinarse sinningún tipo de problemas.

8.1.1. Interfaz de usuario de bajo nivel.

La API de la interfaz de usuario de bajo nivel está especialmente diseñada para aplicacionesque necesitan un control preciso de los elementos grá�cos en la pantalla. Ejemplos típicos de estoserían aplicaciones de dibujo de grá�cos por parte del usuario, juegos, etc.

Con esta API podemos controlar varios aspectos, tales como:

Control de lo que se está dibujando en la pantalla.

Captura de eventos primitivos tales como presión de teclas cornetas del teclado.

Acceso a teclas concretas del teclado y de vías de entrada de datos.

A la hora de realizar cualquier grá�co sobre la pantalla mediante el API de bajo nivel necesitamosde un sistema de coordenadas, el cual sitúa el punto (0,0) origen de coordenadas en la esquinasuperior-izquierda de la pantalla. Así la coordenada x crece hacia la derecha de la pantalla y lacoordenada y crece hacia abajo. Los valores de las coordenadas siempre son enteros positivos.

La clase Graphics contiene la mayoría de funcionalidades para dibujar a bajo nivel. Propor-ciona la capacidad de dibujar grá�cas primitivas (líneas, rectángulos...), texto e imágenes tanto enla pantalla como en un bu�er de memoria. El método paint(), será el método para dibujar.

La clase Graphics tiene una serie de atributos que determinan cómo se llevan a cabo lasdiferentes operaciones. El más importante de estos atributos es el atributo color, que determinael color usado del dibujo que se esté realizando. Este atributo se puede modi�car con el métodosetColor, que recibe tres parámetros enteros que especi�can el color en función de los tres coloresprimarios, o bien el método setGrayScale() que toma como parámetro un único valor entero queestablece el grado de gris en un rango que va desde 0 hasta 255.

Los objetos de tipo Graphics contienen también un atributo denominado font que determinael tamaño y la apariencia del texto, este atributo se modi�ca a través del método setFont().

8.1 LCDUI de MIDP. 119

Las primitivas grá�cas que podemos dibujar son líneas, rectángulos y arcos. La clase Graphicsproporciona métodos para realizar estas operaciones y además, nos proporciona métodos pararellenar las áreas.

El método que permite dibujar una línea es void drawLine (int x1, int y1, int x2, int

y2), los parámetros x1 e y1, indican el punto de comienzo de la línea y x2 e y2 indican el punto�nal. Para cambiar el estilo de la línea tenemos el método setStrokeStyle(), que acepta un valorde los siguientes:

Graphics.SOLID: Línea sólida.

Graphics.DOTTED: Línea de puntos.

El método para dibujar rectángulos es void drawRect (int x, int y, int width, int height),los parámetros x e y especi�can la localización de la esquina superior-izquierda del rectángulo ylos parámetros width y height especi�can el ancho y el alto respectivamente del rectángulo. Pa-ra dibujar rectángulos con las esquinas redondeadas tenemos void drawRoundRect (int x, int

y, int width, int height, int arcWidth, int arcHeight), método que contiene los pará-metros arcWidth y arcHeigth que con�guran el arco de las esquinas del rectángulo. La claseGraphics también tiene métodos para dibujar rectángulos rellenos de un color determinado, elcolor de relleno será el color con�gurado en el atributo color, los métodos para hacer esto sonfillRect() y fillRoundRect().

Figura 8.2: Ejemplo de una interfaz grá�ca de bajo nivel usando Canvas.

Tenemos además los arcos que no son más que una sección de un óvalo. El método que di-buja un óvalo es void drawArc (int x, int y, int width, int height, int startAngle,

int arcAngle), donde los primeros cuatro parámetros de�nen el óvalo del que el arco forma par-te y los últimos dos parámetros de�nen el arco como una sección del óvalo. Para dibujar un óvalo,tendremos que utilizar la clase drawArc, especi�cando un ángulo de 360º. El método para dibujarun arco relleno de color es fillArch().

El texto que se escribe usando la clase Graphics está con�gurado por el atributo font el cualse cambia con el método void setFont (Font font). El objeto Font indica el tipo de fuente, elestilo y el tamaño del texto. Para crear un objeto de tipo Font usamos el método static Font

getFont(int face, int sytle, int size). Una vez que tenemos la fuente usamos el métodosetFont() para que se use la misma en operaciones sucesivas.

El método para dibujar el texto es void drawstring (String str, int x, int y, int

anchor), donde el primer parámetro es el texto a escribir y los dos siguientes (x e y) especi�-can la localización del texto. El último parámetro, anchor, hace referencia al punto a partir delcual se alinea el texto. Este alineamiento es relativo a una de las cuatro esquinas de la caja invisibleque rodea al texto, en combinación la posición horizontal que será la altura base. En la �gura 8.3


aparecen los distintos puntos de anclaje según todas las combinaciones posibles. A parte de estemétodo tenemos algunos otros métodos más para dibujar texto como son los métodos drawChar()y drawChars() usados para dibujar caracteres de texto individuales, también podemos usar elmétodo drawSubstring() que permite escribir una parte de un cadena.

Figura 8.3: Puntos de anclaje para una cadena.

Por último están las imágenes que son objetos grá�cos rectangulares compuestos de píxel decolor o grises. Antes de dibujar una imagen, es necesario cargarla. Las imágenes son cargadasy creadas usando un método de la clase Image denominado public static Image createImage

(String name) throws IOException donde el parámetro indica el nombre del �chero que contie-ne la imagen, este método retorna un objeto de tipo Image que puede ser usado dentro del MIDP.La clase Image representa una imagen grá�ca como puede ser un �chero PNG, GIF o JPEG.También incluye un método para recuperar un objeto Graphics que permite dibujar directamentesobre la imagen boolean drawImage (Image img, int x, int y, int anchor).

8.1.2. Interfaz de usuario de alto nivel.

La API del interfaz de usuario de alto nivel está pensada para aplicaciones profesionales di-rigidas a usuarios trabajando en dispositivos móviles de información. Por tanto la portabilidadde código de un equipo a otro es muy importante, lo cual se consigue empleando un nivel deabstracción alto el cual da lugar a una pérdida de control sobre el dispositivo, así las aplicacionesno de�nen la apariencia de las pantallas, sino que lo hace el sistema; la navegación el scroll de laspantallas y demás operaciones de interacción con el usuario lo realiza el sistema; y las aplicacio-nes no pueden acceder a mecanismos de entrada de datos concretos, como por ejemplo una teclaindividual de todo el teclado.

La clase Screen, que es una clase abstracta, proporciona la funcionalidad básica para unapantalla, que principalmente consiste en un título que aparecerá en la parte superior de esta.Además del atributo de título, las pantallas también pueden tener una línea de texto en movimientoque aparecerá sobre la pantalla. Este texto se con�gura a través de la clase Ticket.

Las funcionalidades de este API se dan a través de cuatro clases las cuales heredan de Screen,que son:

List: Esta clase proporciona una pantalla que contiene una lista de elementos que el usuariopuede seleccionar. Existen tres tipos básicos de listas:

� EXCLUSIVE: Una lista que permite seleccionar un solo elemento a la vez.

� IMPLICIT: Un lista EXCLUSIVE en la que el elemento seleccionado es lanzado comorespuesta a un comando.

� MULTIPLE: Una lista que permite seleccionar uno o más elementos a la vez.

Una vez creada la lista se puede interactuar con ella. Para recuperar el elemento seleccionadoen una lista exclusive o implicit se usa el método getSelectedIndex() que devuelve elíndice del elemento seleccionado dentro de la lista y para listas de tipo múltiple, se usa el


método getSelectedFlags() que devuelve una matriz cuyos valores son de tipo boolean eindican si el elemento correspondiente está seleccionado o no.

TextBox: La clase TextBox implementa un componente de edición de texto que ocupa todala pantalla. A uno de sus constructores se le puede pasar el parámetro constraints describelas limitaciones a aplicar sobre el texto. Estas limitaciones son especi�cadas según unasconstantes:

� ANY: No hay limitaciones en el texto.

� EMAILADDR: Solo se puede introducir una dirección de correo electrónico.

� NUMERIC: Solo se puede introducir un valor entero.

� PASSWORD: El texto es protegido para que no sea visible.

� PHONENUMBER: Solo se puede introducir un número de teléfono.

� URL: Solo se puede introducir una URL.

Figura 8.4: Ejemplo de TextBox.

Alert: La clase Alert implementa una pantalla que muestra un texto informativo al usuario.Esta información se muestra durante un determinado espacio de tiempo o hasta que el usuarioseleccione un comando, según se con�gure. Existen varios tipos de alerta:

� ALARM

� CONFIRMATION

� ERROR

� INFO

� WARNING

Form: Sirve como contenedor para construir interfaces de usuario con otros componenteso Items. Para añadir elementos de tipo Item al Form y componer una interfaz de usuariopersonalizada se utiliza el método int append (Item item). Cada Item añadido a un Form

posee un índice dentro del Form y este índice es el número que retorna el método append.Para hacer referencia a un Item se usa este índice.

Para eliminar un Item de un Form se usa el método void delete(int index). Se puedeinsertar un Item en un punto concreto del Form con el método void insert(int index,

Item item). Para modi�car un Item debemos usar el método void set(int index, Item

item). Para recuperar un determinado Item disponemos del método Item.get(int index),�nalmente, para saber el número total de Items en un Form tenemos el método int size().La clase Form está pensada para aquellos casos en los que una pantalla con una únicafuncionalidad no es su�ciente, sino que es necesario que contenga un pequeño número de


Figura 8.5: Ejemplo de Alert.

elementos de interfaz de usuario, o Items. Si el número de Items fuese tal que no entrasenen una sola pantalla, el propio sistema se encarga de implementar un scroll que permita subiro bajar a lo largo de la pantalla para visualizar a los distintos Items. En cualquier orden ynúmero, un Form puede contener los siguientes Items:

� StringItem: Esta clase representa un elemento que contiene una cadena de texto, esusada para mostrar texto en un Form. Está compuesta de dos partes, una etiqueta y untexto.

� ImageItem: La clase ImageItem es similar a StringItem pero está diseñada para mos-trar imágenes en lugar de texto. Con este elemento se puede mostrar un texto juntocon la imagen y se puede determinar cómo la imagen se posiciona en el Form respectoa otros elementos.

� TextField: Esta clase proporciona un editor de texto diseñado para ser usado dentrode los Forms (esta es la principal diferencia con respecto a la clase ) por lo demás setrabaja con ella igual. Al igual que a los TextBox, se le pueden añadir restricciones ala hora de insertar texto.

Figura 8.6: Ejemplo de TextField.

� DateField: Presenta al usuario una interfaz intuitiva para introducir fechas y horas.Es necesario indicarle el modo de funcionamiento del componente. Estos modos defuncionamiento son:

◦ DATE: Se introduce solo una fecha (día, mes y año).◦ TIME: Se introduce solo una hora (horas y minutos).◦ DATE_TIME: Se introduce el día y la hora.

� Gauge: La clase Gauge implementa una barra grá�ca que puede ser usada para visualizarun valor dentro de un rango. Un objeto de tipo Gauge tiene un valor máximo que de�ne


Figura 8.7: Ejemplo de DateField.

el rango del objeto (de 0 al máximo) y un valor actual que determina el estado actualde la barra. La clase Gauge puede funcionar interactivamente y no interactivamente.Si funciona de forma no interactiva, simplemente se muestra la barra, mientras que sitrabaja de forma interactiva, se usará la barra como método para introducir un valorpor parte del usuario, manipulando la barra.

Figura 8.8: Ejemplo de Gauge.

Se puede acceder al valor actual del Gauge y cambiar dicho valor con int getValue()

y void setValue(int value), también es posible manipular el valor máximo con losmétodos int getMaxValue() y void setMaxValue(int value).

� ChoiceGroup: Esta clase presenta una lista de elementos los cuales el usuario puedeseleccionar. Esta clase es similar a la clase List, pero la clase ChoiceGroup está pensadapara ser usada dentro de un Form. A parte de esto, no hay muchas más diferencias entreambas.

Soporte de eventos.

Puesto que el MIDP implementa una interfaz de usuario de alto nivel, con una abstracción muyalta no se facilita una técnica concreta de interacción con el usuario, sino que se implementa unainfraestructura básica para manejar las interacciones del usuario a través del patrón Observer. Estepatrón describe cómo deben comunicarse los componentes de una aplicación entre sí. Proporcionaun método para que un componente pueda emitir mensajes a los componentes que estén interesadosen recibirlos y que previamente se hayan registrado mediante una interfaz del tipo Listener. Unainterfaz de este tipo de�ne los métodos necesarios para manejar los eventos que produzca el emisor.La implementación del patrón se logra gracias a las clases Command y CommandListener.

En una aplicación MIDP se de�nen una serie de comandos (objeto Command) y la forma degestionarlos por parte del usuario mediante botones, menús o cualquier otro mecanismo que pueda


Figura 8.9: Ejemplo de ChoiceGroup.

existir en un dispositivo (objeto CommandListener). Para asociar o eliminar comandos de un objetoDisplayable, este proporciona los siguientes métodos:

public void addCommand(Command c). Añade el objeto Command al objeto Displayable.Lanza una excepción NullPointerException si el comando es null.

public void removeCommand(Command c). Elimina el objeto Command del objeto Displayable.Si el comando es null no hace nada.

Al añadir un objeto Command a un objeto Displayable, se mapea a una softkey2 del teléfonodirectamente o aparece bajo las etiquetas de opciones o menú.

La clase Command proporciona dos constructores:

public Command(String label, int cmdType, int priority).

public Command(String shortLabel, String longLabel, int cmdType, int priority).

Sus argumentos son:

shortLabel: Texto corto que se muestra en pantalla cuando el comando está mapeado a unasoftkey.

longLabel: Texto largo que se muestra cuando el comando es mostrado dentro de un menú.Normalmente si no cabe en una línea se muestra la etiqueta corta.

label: Texto que se muestra al usuario en la pantalla para identi�car el comando. En estecaso la etiqueta corta y la larga se unen en una, siempre mostrándose el mismo texto.

commandType: Tipo del comando o signi�cado del comando. Según el tipo, el comando tendráuna funcionalidad u otra. Existen varias funcionalidades:

� OK: Veri�ca que se puede comenzar una acción.

� CANCEL: Cancela la acción.

� STOP: Detiene la acción.

� EXIT: Sale del MIDlet.

� BACK: Envía al usuario a la pantalla anterior.

� HELP: Solicita la ayuda.

� ITEM: Un comando especi�co de la aplicación que es relativo a un determinado item dela pantalla actual.

2Botón localizado en la pantalla de un dispositivo que realiza una función en función del texto que apareceasociado.

8.2 Por qué LCDUI no es una solución apropiada. 125

� SCREEN: Un comando especi�co de la aplicación que es relativo a la pantalla actual.

priority: Permite al sistema emplazar al comando en función de su prioridad, de formaque si hubiese demasiados comandos que no entrase en una sola pantalla se presentarían enesta por los de mayor prioridad, pasando los otros a un submenú adicional. Dentro de estesubmenú, a mayor prioridad (número más bajo), el comando se situará en una posición másaccesible dentro del menú (suele ser la posición más alta).

Existe un comando especial que es el List.SELECT_COMMAND, el cual está pensado para albergarla selección realizada de entre las posibles existentes en un objeto List.

Los objetos Displayable que quieren capturar los eventos que producen los comandos asocia-dos a ellos deben extender la interfaz CommandListener, que solo tiene un método:

public interface CommandListener {void commandAction (Command c , Di sp layab le d ) ;

}

El método commandAction() especi�ca qué hacer cuando un comando especí�co es invocadopor el usuario. Para no bloquear la pantalla es necesario que devuelva el control rápidamente. Enel caso en el que la lógica asociada a un comando requiera de un tiempo largo de procesamiento,para no bloquear la interacción con el usuario se habría que lanzar un nuevo hilo que lleve a cabodicha lógica.

La clase Displayable proporciona un método para poder registrar qué Listener se encargaráde procesar los eventos producidos:

public void setCommandListener(CommandListener listener );

El uso y disposición de comandos a lo largo de las distintas pantallas debe ser uniforme,entendiendo esta cualidad como el mantenimiento de la prioridad y de las etiquetas de los comandosde un mismo tipo en todas las pantallas en las que aparecen. Una buena regla de diseño es estableceraquellos comandos más usuales como prioritarios. Estos comandos serán aquellos relacionados conla lógica asociada a una acción concreta accesible desde el objeto Displayable que en ese momentose está mostrando. Menos prioritarios serán aquellos comandos relacionados con la navegación através de la interfaz grá�ca, como el comando BACK, EXIT, etc.

8.2. Por qué LCDUI no es una solución apropiada.

En el apartado 7.2.1 se vio que para obtener una aplicación de una alta usabilidad lo mejores construir la GUI haciendo uso de la API de MIDP LCDUI para interfaces de alto nivel. Sinembargo esto último plantea un problema. En las interfaces LCDUI de alto nivel las aplicacionesno de�nen la apariencia de las pantallas, sino que lo hace el sistema. Esto implica que la aplicaciónno dispondrá de un aspecto único entre el resto de MIDlets disponibles en el mercado, sino suapariencia será el de la interfaz nativa, por lo que variará de un dispositivo móvil a otro. El hecho detener un aspecto único en todos los dispositivos en los que la aplicación se va a ejecutar es un factorclave en el desarrollo de esta aplicación, ya que la apariencia de la GUI es uno de los principalesaspectos distintivos de cualquier aplicación móvil, que crea imagen de marca y que ayuda a laaplicación a despuntar en el mercado con mayor facilidad. De hecho, todas las aplicaciones clienteDVB-H actualmente disponibles no hacen uso de los elementos grá�cos nativos, sino que poseenuna GUI propia. Así, se concluye que el uso de la librería LCDUI para interfaces de alto nivel noes recomendable si se quiere un aspecto homogéneo y distintivo.

Esto implica que es necesario el desarrollo de una interfaz de bajo nivel, pero a la vez, dichainterfaz debe disponer de los widgets anteriormente comentados para una mayor usabilidad. Laprogramación de widgets en una interfaz de bajo nivel (en la cual estos componentes se dibujan apartir de rectángulos, elipses y líneas rectas y curvas como se ha visto en la sección 8.1.1) es unalabor ardua, extensa y complicada, a todas luces excesiva para el alcance de este proyecto. Así


que nos encontramos con dos factores claves de diseño opuestos, es decir, el cumplimiento de unova en detrimento del otro.

Afortunadamente, actualmente existen librerías, de código libre y a libre disposición del desa-rrollador, que a partir de una interfaz LCDUI de bajo nivel construyen componentes de alto niveltotalmente personalizables. Estas librerías satisfacen justamente dos necesidades primordiales eneste proyecto:

La necesidad de una librería de ayuda al desarrollo de interfaces grá�cas homogéneas ypersonalizables que sigan el paradigma WIMP

La necesidad de de desarrollar una aplicación de código libre, lo que implica que no puedeincluir librerías obtenidas previo pago de licencia.

A continuación se presenta un análisis de varias librerías que cumplen estas características y unadescripción de la librería �nalmente utilizada.

8.3. Librerías de libre distribución para la interfaz grá�ca deusuario.

Como se ha visto en la sección anterior surge la necesidad de hacer uso de una librería queabstraiga todo el proceso de construcción de la GUI de bajo nivel y ayude a la realización de unainterfaz rica y compacta que satisfaga las necesidades y requisitos visuales del usuario, a la vezque su proceso de construcción sea lo más sencillo y rápido posible. De esta forma se conseguiráuna interfaz grá�ca de usuario con las siguientes características deseadas:

Una interfaz homogénea entre todos los dispositivos.

Una experiencia de usuario similar para todos los dispositivos.

Una apariencia distintiva con respecto a otras GUIs presentes en el mercado.

Un comportamiento personalizado para esta aplicación en particular.

Una aplicación �exible a futuras modi�caciones.

Como uno de los principales requisitos del cliente es ser de código abierto, nos encontramos con lanecesidad de utilizar una librería de libre distribución y uso. Es por ello que la búsqueda de unalibrería factible se ha limitado a aquellas que cumplen esta característica. Para elegir una libreríaen concreto entre todas las encontradas se ha sometido a cada una a una evaluación en la que seha tenido en cuenta principalmente los siguientes factores:

Soporte para una amplia gama de terminales móviles que incluyan CLDC1.0 y MIDP2.0,de distintos resoluciones y tamaños de pantalla, ya que en un principio se desconoce eldispositivo sobre el que el MIDlet se ejecutará.

Soporte para pantallas táctiles, ya que principalmente los dispositivos en los que el clientese ejecutará proporcionará esta ventaja.

Apariencia moderna y de alto nivel, con funcionalidad atractiva para el usuario, como laposibilidad de transiciones dinámicas entre pantallas. Si el usuario se encuentra con unainterfaz de apariencia anticuada, su actitud ante el cliente será prejuiciosa y poco receptiva.

Posibilidad de introducción de texto desde el teclado físico y/o virtual a través de elementosimplementados en la misma librería, haciendo el mínimo uso posible de la habilidad paraintroducir texto nativa del dispositivo. Utilizar esta última característica supone un cambiode pantalla a otra cuyo �look&feel� será distinto al elegido para la GUI, ya que será innatoal sistema operativo del dispositivo.

8.3 Librerías de libre distribución para la interfaz grá�ca de usuario. 127

Un uso fácil e intuitivo de la librería elegida, para minimizar el tiempo de aprendizaje de lascaracterísticas de las que dispone como también su tiempo de programación.

Una librería �able y libre de errores. Es difícil saber a priori si la librería posee errorescríticos. Se puede obtener una idea aproximada a partir de la opinión de otros usuarios yel calado que ha tenido entre la comunidad desarrolladora de aplicaciones para terminalesmóviles. Que la librería aún siga actualizándose para corregir bugs en versiones anteriorestambién es un buen indicio de una librería �able.

Una librería potente, ya que el cliente será muy exigente con la interfaz debido a que re-querirá la visualización de vídeo; y versátil para poder personalizar la funcionalidad de suselementos. A la vez se desea que la librería sea lo más ligera posible (característica que sueleser inversamente proporcional a la potencia), ya que el cliente �nal será un MIDlet cuyo ta-maño será grande y muy exigente con la capacidad de procesamiento del dispositivo móvil.La interfaz grá�ca de usuario clásicamente es aquella parte de la aplicación que suele consu-mir más recursos en cuanto a memoria. Cuanto menos contribuya la librería a la sobrecargade memoria y procesado, mucho más rápida será la aplicación y más capacidad de reaccióntendrá.

A continuación se hace un pequeño estudio de aquellas librerías encontradas, donde se resaltansus bondades y defectos según el criterio antes mencionado.

8.3.1. jMobileCore.

jMobileCore[4] es una librería albergada en SourceForge.net distribuida bajo licencia LGPL[5].Se distribuye en forma de librería de código abierto, junto con ejemplos. También posee un forode consulta e intercambio de opiniones, aunque está inactivo desde enero del 2008.

Cuenta con una serie de componentes3 al estilo AWT�[6], es decir, posee una serie de elementoslistos para usar como etiquetas, áreas de texto, listas, botones, etc. No solo se encarga de la interfazde usuario, sino que también facilita la programación multihilos y el acceso rápido a datos a travésde clases que abstraen el sistema de gestión de registros RMS.

En la �gura 8.10 se presentan dos pantallas del MIDlet ejemplo distribuido junto con la librería.Como ventaja cabría destacar que facilita la programación de la GUI ya que se reutiliza el

concepto ya conocido de AWT, lo que redundaría en un desarrollo más rápido. Sin embargo comoinconvenientes caben destacar varios:

La librería es muy básica, no tiene componentes más complejos como tablas.

No soporta eventos de pantalla táctil.

La entrada de texto no da soporte a la combinación de teclas mayúsculas/minúsculas.

No tiene la posibilidad de distribuir los componentes en la pantalla de otra forma que no seauno bajo otro.

La apariencia no está muy conseguida y está algo anticuada. Además los elementos no sonpersonalizables.

El foro está inactivo.

3widgets en inglés


Figura 8.10: Etiquetas, cuadros de texto e imágenes en jMobileCore

8.3.2. SwingMe.

SwingMe[7] es un producto de la empresa Yura que se distribuye bajo la licencia LGPL. Sedistribuye en forma de proyecto de código abierto para NetBeans. Todavía es un proyecto en activoen el que se actualiza con distribuciones corregidas.

SwingMe sigue la �losofía de Swing�[8], por lo que a la hora del diseño se cuenta con com-ponentes como etiquetas, cajas de texto, listas, etc. En la �gura 8.11 se pueden observar estoselementos.

Figura 8.11: Elementos disponibles en SwingMe

Como ventajas tenemos que:

Swing� es una tecnología conocida y de fácil implementación, por lo que se disminuye eltiempo de estudio y desarrollo.

Posee elementos complejos, como menús desplegables en distintos niveles y pestañas.

Cuenta con distintas posibles distribuciones de elementos4.

4layouts en inglés


La apariencia de todos los elementos son hasta cierto punto personalizables.

Soporta eventos en pantalla.

Como inconvenientes presenta:

Los elementos de la librería no son tan versátiles como se querría.

La apariencia de los elementos está anticuada.

La librería no soporta características de alto nivel como transiciones.

No se distribuye ningún manual de ayuda ni hay ningún foro en el que comentar las dudas.

8.3.3. J4ME.

J4ME o Java For Me[9] surge de la necesidad de la compañía ScoreOut de diseñar una libreríaque les ayudara en el desarrollo de uno de sus productos, un juego de golf en Java. La libreríaconseguida se ha puesto a disposición pública a través de la licencia Apache 2.0[10]. La librería sedistribuye en forma de paquete en el que se contiene tanto la librería compilada en un archivo JARjunto con el JAD descriptivo como el código fuente. En el mismo paquete se incluye también elJavaDoc con la descripción de cada clase y método ofrecido así como varios ejemplos de uso.El proyecto J4ME, si bien sigue en activo, apenas se ha actualizado, corregido o modi�cadodesde principios de 2008. Posee un foro en activo para dudas y sugerencias, aunque presentapoca colaboración.

Al igual que las librerías anteriores, J4ME ofrece una serie de componentes de fácil uso alestilo de AWT, como son etiquetas, cajas de comprobación, botones, etc. Además ofrece algunasclases de ayuda de las que carece JavaME para funciones matemáticas y para hacer expirar lasconexiones en caso de bloqueo.

Figura 8.12: Distintos estilos para la GUI creada con J4ME.

Como ventajas cabría destacar:

Soporte para pantallas táctiles.

Aunque la apariencia no es moderna, es bastante profesional.

Dispone de algunos componentes complejos como barras de carga y algunas clases de ayudaa la programación, como el marco para el acceso restringido de usuarios5.

5logging en inglés


El javaDoc y el foro ayudan a un desarrollo rápido y �able.

Como desventajas:

La librería es algo básica, carece de componentes más complejos como componentes deelección desplegables (se muestran en una nueva pantalla) o pestañas.

La escritura en las cajas de texto se tiene que realizar desde el editor de texto propio deldispositivo móvil.

El desplazamiento vertical y horizontal6 por la pantalla es mejorable.

La librería no soporta características de alto nivel como transiciones.

A pesar de que la estética de los elementos no es mala, debería ser aún más versátil. Solo esposible el cambio de color en el estilo.

La licencia Apache es menos utilizada que GPL, por lo que en el caso de querer utilizarotros componentes de libre distribución en el cliente DVB-H, pueden existir con�ictos entrelicencias.

8.3.4. Apime.

Apime[11] es un marco para la ayuda al desarrollo de GUIs para JavaME ofrecido por la empresaJava4Ever, bajo la licencia GPL[5]. Se distribuye en un paquete que contiene tanto la libreríaempaquetada en un archivo JAR como el código fuente. También se incluyen varios ejemplos deutilización y el JavaDoc de la librería en castellano. Apime es una librería desactualizada. No seha realizado prácticamente ningún cambio desde su concepción y no dispone de ningún foro deayuda y dudas.

La navegación en la interfaz se realiza a través de un puntero de ratón, es decir, se va des-plazando el ratón con las teclas de dirección (para pantallas no táctiles) hasta el componentedeseado.

Figura 8.13: Componentes de elección y puntero de ratón en Apime.

Como las anteriores librerías, se basa en una �losofía de componentes estilo AWT. Las carac-terísticas ventajosas de Apime son:


6scrolling en inglés


Se permite la introducción de texto con formato (mayúsculas/minúsculas, letras/números)en los mismos componentes de la librería.

Posee algunos componentes de alto nivel como barras de progreso y ayuda visual7.

No obstante, presenta bastantes desventajas:

La apariencia es muy anticuada.

Se requieren más componentes de alto nivel y una mejor y más variada capacidad de distri-bución de elementos en la pantalla.

Se desea más versatilidad y mayor poder de personalización de componentes, estilos, etc.

Librería de poca �abilidad.

Los componentes de elección y las cajas de texto son bastante mejorables: el texto se solapacon el borde del componente.

Carece de características de alto nivel como transiciones.

8.3.5. Fire.

Fire[12] es un conjunto de herramientas para el desarrollo de GUIs en JavaMe a través de hojasde estilos en cascada8 y xHML llevado a cabo por la empresa BlueVibe. Se distribuye bajo licenciaLGPL[5]. El proyecto se alberga en SourceForge.net y el 23 de Marzo de 2009 se sacó la versión2.2. Sin embargo, para el tiempo en el que esta evaluación se realizó, esta versión aún no estabadisponible. Es por ello que la evaluación se hará en función de las características de la versión 2.0.Como se acaba de apuntar, Fire es un proyecto aún en activo con un foro de ayuda, informacióny dudas también en activo.

La librería se distribuye en forma de paquete en el que se contiene tanto la librería compiladaen un archivo JAR junto con el JAD descriptivo como el código fuente. En el mismo paquete seincluye también un MIDlet de ejemplo.

Figura 8.14: Links, pop-ups y formularios en Fire2.

Fire está más enfocado a la presentación de contenido típicamente Web que a otro tipo deaplicaciones, es por ello que hace especial hincapié en aquellos elementos como links, formularios,imágenes dinámicas, etc.

Características deseables de Fire son:7tooltip en inglés8Cascade Style Sheet o CSS


Soporta eventos en pantallas táctiles.

Librería �able sujeta a constantes mejoras.

La licencia LGPL es menos restrictiva que GPL a la hora de distribuir el software que haceuso de la librería libre.

Sin embargo, Fire presenta muchas desventajas:

No existe posibilidad de utilizar distintos layouts: se asume que los elementos irán uno trasotro.

La apariencia es de tipo web, anticuada y excesivamente �ja sujeta a casi ninguna persona-lización.

El enfoque de Fire es la presentación de contenido web, lo que no se corresponde con lanaturaleza del cliente DVB-H a desarrollar.

La introducción de texto en cajas de texto tiene que pasar a través del editor inherente aldispositivo móvil.

8.3.6. MWT.

MWT, o Micro Window Toolkit�[13]es un marco para el desarrollo de interfaces grá�cas paraJavaME de la empresa Sun Microsystems, Inc. Se distribuye libremente bajo licencia LGPL yse alberga en SourceForge.net. El paquete en el que se entrega contiene tanto el código fuente,como la librería ya comprimida en un �chero JAR junto con su descriptor JAD. Además incluyetres MIDlets de ejemplo y una extensa documentación, que comprende el JavaDoc de la libreríaasí como diversos tutoriales. Como todo proyecto en SourceForge.net, presenta un repositorio decambios y de un foro de ayuda, sugerencias y errores, pero todos están prácticamente inactivos.

Al contrario que la mayoría de librerías encontradas, MWT no sigue una �losofía AWT, sinoque está más enfocada en el desarrollo de aplicaciones de juego o de otro tipo similar para JavaME.Por lo tanto, no presenta componentes ya prede�nidos listos para usar, sino que hay total libertada la hora de elegir cómo será la presentación �nal de la información en la pantalla. Es por ello queel desarrollo con MWT es más complejo que con otras librerías.

Teniendo en cuenta el tipo de aplicación que se desea desarrollar en este proyecto, MWT nosatisface las necesidades por muchos motivos. Su única ventaja es que permite un control total delo que el usuario va a visionar en la pantalla del dispositivo móvil, por lo que es muy versátil a lahora de presentar el vídeo. Sin embargo, presenta múltiples inconvenientes por los cuales el uso deMWT no sería apropiado para el cliente DVB-H:

No soporta pantallas táctiles.

Su enfoque es más para juegos JavaME.

No tiene elementos listos para usar, por lo que el tiempo de programación se incrementaconsiderablemente.

Su uso está muy limitado al tipo de dispositivo móvil en el que se pretende utilizar, esdecir, le afecta considerablemente el cambio de características del dispositivo como tamañoy resolución de la pantalla.

Poco �able, los MIDlets ejemplo no funcionaron bien en el emulador. En la �gura 8.15 semuestra un ejemplo.

Las teclas de navegación corresponden al teclado numérico y no a las dedicadas generalmentepara ello.


Figura 8.15: Mal renderizado de la interfaz grá�ca por MWT.

8.3.7. MicroEWT.

MicroEWT�[14] es un producto desarrollado por la compañía Esoco albergado en SourceFor-ge.net y bajo la licencia GPL. El paquete en el que se entrega contiene tanto el código fuente,como la librería ya comprimida en un �chero JAR junto con su descriptor JAD. Además incluyeun MIDlet de ejemplo, sin embargo no contiene nada de documentación. La única documentacióndisponible está a través de las páginas Wiki del proyecto en la página web de la empresa desarrolla-dora. Esta documentación no es exhaustiva pero sí completa, ya que dispone de una introduccióncon información su�ciente para un desarrollo rápido, un manual más completo, el JavaDoc de lalibrería y un formulario FAQ bastante escaso. También posee un foro, pero que lleva inactivo desdevarios meses atrás.

MicroEWT sigue una �losofía basada en AWT, enfocada al desarrollo de aplicaciones de ven-tanas. Así, como se observa en la �gura 8.16, la aplicación presenta una estética similar a la deuna antigua aplicación de escritorio de Windows.

Figura 8.16: Capturas de pantalla de distintas ventanas programables con MicroEWT.

Ventajas a destacar de esta librería son:

Soporta pantallas táctiles.

Al seguir la �losofía AWT, ofrece componentes como etiquetas, listas y botones listos para


usar.

Dispone de distintos layouts con los que poder distribuir los elementos a lo largo de lapantalla.

Las ventanas se pueden superponer unas a las otras, es decir, se permite el solapado deventanas.

Las principales desventajas de esta librería son:

La apariencia está muy anticuada.

Las cajas de texto no permite la introducción alternada de mayúsculas/minúsculas.

Se desearía componentes reutilizables más complejos.

Al no disponer de un foro activo, se corre el riesgo de encontrar errores insalvables en lalibrería.

Carece de características de alto nivel como transiciones.

Se desea más versatilidad y mayor poder de personalización de componentes, estilos, etc.

8.3.8. Synclast.

Synclast�[15] es un producto de la empresa homónima licenciado bajo GPL. Se presenta enun paquete en el que solo viene el código de la librería. Para hacer uso de la documentación esnecesario acceder a la página web de la empresa desarrolladora. En ella encontramos tanto unbreve manual como el JavaDoc de la librería. También hay un pequeño FAQ que resuelve dudasde carácter general, pero no técnico.

Figura 8.17: Dos ejemplos de las interfaces obtenidas con Synclast.

Esta librería es de extrema simpleza, por lo que resulta poco potente. También presenta com-ponentes al estilo AWT, aunque bastante limitados. Para los requisitos del cliente DVB-H, estalibrería no es su�ciente, entre otras cosas por los siguientes motivos:

El estilo está poco conseguido.

No permite la introducción de texto alternado en mayúsculas/minúsculas.

Apenas hay documentación relativa.

Poca potencia: carece de características de alto nivel, los componentes son demasiado simplesa excepción de algunos como la posibilidad de adición de tablas y el poder de personalizaciónde cada uno de los componentes es muy limitado.


8.3.9. Kuix.

Kuix (Kalmeo User Interface eXtension)�[16] ofrece un marco para la creación de interfacesgrá�cas en JavaME puesta a disposición por la empresa Kalmeo bajo las restricciones de la licenciaGPL. Se distribuye desde su web en forma de paquete en el que se contiene tanto el código fuentecomo el comprimido en JAR con el JAD, un MIDlet de ejemplo igualmente en código abierto,así como el JavaDoc relativo a la librería. Además del JavaDoc, existen una serie de pequeñostutoriales y guías de ayuda que no se distribuyen en el paquete, sino que se acceden a través de lapágina web. Dichos tutoriales ayudan al desarrollador a familiarizarse con la librería, y si se quieredesarrollar interfaces grá�cas simples las explicaciones contenidas en ellos debería ser su�ciente.Si se requiere ahondar más en la librería para extraer más potencial de ella sería necesario haceruso del JavaDoc.

Kuix sigue una �losofía Swing, por lo que la programación de las interfaces grá�cas se hace através de la adición de pequeños widgets reutilizables. Una de las cualidades más reseñables de Kuixes que permite la de�nición del estilo de cada uno de los componentes a través de hojas de estilosy archivos XML. Además se pueden organizar estos componentes en la pantalla a través de unarchivo XML. Haciendo uso de estas características, la programación resulta menos tediosa y másrápida, además de que es más sencilla ya que no es necesario conocimientos del lenguaje JavaMepara la creación de la estética de la aplicación. Al estar separado la componente estética de la lógicade la aplicación, un diseñador grá�co podría ocuparse de la primera parte independientemente,es decir, sin necesidad de implicar a un programador de MIDlets. Tan solo necesitaría saberlas características de cada uno de los componentes, para lo cual Kuix provee documentaciónen formato JavaDoc. Sin embargo, es necesario que el diseñador grá�co y/o programador tengaconocimiento de creación de hojas de estilo y metalenguaje XML. Si no se tuviera, siempre seríaposible programarlo en JavaME.

En caso de duda, Kuix ofrece a través de su web un foro en el que, además de informacióngeneral e informar sobre errores encontrados, se pueden hacer consultas técnicas. Dichas consultasson resueltas por otros usuarios, lo que no asegura ni respuesta ni una solución segura.

Cuando se hizo esta evaluación, Kalmeo ponía a disposición en su web la versión 1.0.2 de Kuix.En el día en el que este documento se escribe se encuentra ya la versión 1.2. Si se quisiera acceder alo último de la librería, se puede acceder al repositorio donde se alberga el proyecto[17] a través deSubversion9[18], el cual se puede integrar en cualquiera de los principales entornos de desarrollo10.

Figura 8.18: Menú desplegable en varios niveles en Kuix y otros de sus componentes: pestañas,botones, cuadros de texto, etc.

Kuix resulta una librería muy ventajosa de la que cabe destacar:

9también conocido como svn10Integrated Development Enviroment o IDE



Posee componentes complejos, como cuadros de diálogo, pestañas y barras de progresión decarga.

Provee de características de alto nivel como transiciones.

A través de las hojas de estilos se puede de�nir de una manera sencilla muchas característicasreferentes al estilo de los distintos componentes de los que Kuix dispone.

Debido a esta característica es muy personalizable.

Apariencia moderna y atractiva.


Permite distintos modos de distribución de elementos en la pantalla.

Librería �able, sujeta a constantes cambios para mejorarla.

Sin embargo presenta las siguientes desventajas:

Documentación pobre.

Foro no lo su�ciente activo.

Si se quiere hacer uso de las hojas de estilos y de los archivos descriptivos en XML, esnecesario aprender el formato y directivas de cada uno de ellos propias de Kuix. Si se estáfamiliarizado con hojas de estilo y XML esta labor no debería resultar muy complicada.

8.3.10. LWUIT.

LightWeight User Interface Toolkit�[19] es una librería desarrollada por un grupo de Sun Mi-crosystems�, y puesta a libre disposición bajo los términos de la licencia GPLv2[5] con la excepciónde ruta de clases11. Se distribuye en un completo paquete que incluye desde el código abierto, adiversos ejemplos de uso, un MIDlet de ejemplo en código abierto, la librería ya comprimida enun archivo JAR junto con su archivo descriptivo JAD, una guía para el desarrollador y hastaun pequeño programa para ayudar en la creación de los distintos estilos que se pueden aplicar alMIDlet.

La guía del usuario es algo incompleta si se quieren desarrollar aplicaciones que son exigentescon la interfaz grá�ca, pero es una buena primera aproximación para la programación en LWUIT.Si se quiere más información será necesario consultar el javaDoc de la librería, que también sedistribuye en el mismo paquete. Además, para otro tipo de consultas LWUIT cuenta con un forobastante activo donde colaboran los mismos desarrolladores. El foro también sirve para informaracerca de errores encontrados en la librería, los cuales son corregidos o considerados para futurascorrecciones por los creadores. El proyecto sigue aún en activo y cada cierto tiempo se pone adisposición una nueva compilación con una nueva versión mejorada. Si no se quiere esperar adicha compilación, a través de la página web del proyecto se puede acceder al repositorio dondese recoge[20] para descargar las versiones actualizadas de las clases que componen la librería. Conun cliente svn[18] se puede acceder a dicho código. También existe un blog creado por otro de losdesarrolladores en el que se encuentran útiles trucos y consejos.

LWUIT sigue la misma �losofía de Swing. Como ya se ha comentado en librerías anteriores,se incluyen componentes listos para usar familiares para todos aquellos programadores de Swing,como son listas, cuadros de diálogos, etiquetas, botones, etc. Para aliviar la laboriosa tarea dede�nir colores, tipo de grafía, transparencias y otras características del estilo de cada uno delos componentes, se dispone de un editor de recursos, una pequeña aplicación para PC para la

11classpath exception


Figura 8.19: Menú creado con LWUIT y sus componentes: lista, etiquetas, cuadros de texto, etc.

de�nición de estilos. Para la ayuda del control de hilos dentro del MIDlet que usa LWUIT, estede�ne un hilo principal que controla todas las tareas relacionadas con la interfaz grá�ca, así elusuario puede desentenderse de refrescar la interfaz.

Las características encontradas en LWUIT que son apropiadas para el cliente a desarrollar son:


Posee componentes complejos, como cuadros de diálogo y pestañas.

Provee de características de alto nivel como transiciones o navegación suave (smooth scro-lling).

Es extremadamente versátil: todos y cada uno de sus componentes son modi�cables parasatisfacer las necesidades del desarrollador. En el caso en el que ni aún modi�cando elcomponente sea su�ciente, se puede crear uno nuevo a partir del ya dado por LWUIT o crearuno completamente nuevo.

Debido a esta versatilidad, es muy personalizable.




Autodetección de cambio en la dimensión de la pantalla y redimensionado automático de lainterfaz.

Librería �able y probada, sujeta a constantes cambios para mejorarla. Al ser Sun la compañíadetrás de LWUIT, hay cierta garantía de calidad.

Foro activo donde los mismos creadores se implican.

Integración de la API de multimedia MMAPI.

Como características deseables de las que carece la librería encontramos:

Se echa en falta componentes más complejos como barras de tareas o de carga.

Más documentación relativa a la programación en LWUIT.


8.3.11. J2ME Polish.

J2ME Polish[21] más que una librería es un entorno de desarrollo al completo para la ayuda dela creación de interfaces grá�cas de usuario para JavaMe. Este entorno de desarrollo ha sido creadopor la empresa alemana Enough Software y puesto por esta a libre disposición bajo los términosde la licencia GPL. Dicho entorno de desarrollo puede ser integrado en forma de complemento12 enlos principales entornos de desarrollo integrados (IDE) que existen en el mercado, como NetBeanso Eclipse. Así, directamente se puede crear un proyecto del tipo Polish desde su inicio en el IDE,el cual ya contará con las características y componentes puestos a disposición por este software.

J2ME Polish cuenta con una extensa comunidad de desarrolladores. Posiblemente de entretodas, esta sea la solución más utilizada, tanto para productos de software libre como aquelloscon �nes comerciales. Esto es posible debido a que Polish se distribuye tanto bajo licencia GPLcomo por licencia comercial. En la página web de J2ME Polish se encuentra una gran cantidad deinformación relativa a su utilización. Así en su sección documentación encontramos una guía deinstalación, un manual sobre cómo migrar proyectos antiguos a proyectos de tipo J2ME Polish,una guía de diseño, otra visual como introducción a J2ME Polish y una guía para la compilación yempaquetado del MIDlet según el terminal móvil objetivo, así como otras acerca de otras caracte-rísticas independientes de aquellas relacionadas con la interfaz grá�ca como es soporte al sistemade gestión de registros. Además de todo esto, como cabe esperar también se pone a disposición elJavaDoc de las APIs.

A lo largo del tiempo Enough Software ha ido confeccionando una base de datos que recogeinformación acerca de un gran número de los dispositivos móviles existentes en el mercado. Dichainformación comprende desde las APIs de las que dispone cada uno de ellos, como errores especí�cosencontrados en dichas APIs y hasta posibles soluciones o apaños para evitar tales errores. Paraerrores propios de J2ME Polish, también se dispone de un activo foro y un pequeño FAQ. Ademásen dicho foro se puede realizar consultas de carácter técnico.

J2ME Polish también provee al usuario de una serie de widgets como son etiquetas, botones,cajas de texto, etc que este puede combinar y distribuir en la pantalla a su antojo. Al igual queKuix (8.3.9), J2ME Polish cuenta con un sistema de de�nición de estilos para cada uno de estoscomponentes a través de CSS, al igual que se distribuyen según lo especi�cado en un documentoXML. Esto cuenta con la ventaja de independizar la creación de la parte grá�ca de la lógica de laaplicación.

Figura 8.20: Menú creado con J2ME Polish y dos de sus componentes: tablas y pestañas

Con J2ME Polish no solo es posible crear de manera más sencilla interfaces grá�cas, sino quetambién provee de APIs para la ayuda al desarrollo de otras tareas implicadas en la programación

12plug-in en inglés


de MIDlets. En concreto, se incluye una API para guardar datos persistentemente haciendo usode RMS, otro para la internacionalización (es decir, soporte para distintos lenguajes en una mismaaplicación) y otra para facilitar el acceso remoto a funcionalidad situada en el servidor desde elterminal móvil, haciendo uso de la invocación remota de métodos13 o del procedimiento de llamadaremotas14 con la ayuda de XML.

Teniendo en cuenta todo lo anterior, se concluye que J2ME Polish es una herramienta muypotente que satisface casi cualquier necesidad relativa al desarrollo de MIDlets. Es por ello queresulta muy apropiada para el cliente DVB-H a desarrollar, ya que además de todas las ventajascon las que cuenta Kuix (8.3.9), suple las carencias que en este se encontraban. Dichas ventajasson:


Posee componentes complejos, como tablas, pestañas, árboles y barras de progresión decarga.

Provee de características de alto nivel como transiciones.

A través de las hojas de estilos se pueden de�nir de una manera sencilla muchas caracterís-ticas referentes al estilo de los distintos componentes de los que Kuix dispone.

Debido a esta característica es muy versátil y personalizable, además de �exible.




Librería �able, sujeta a constantes cambios para mejorarla. El hecho de ser la herramientamás utilizada sirve como rea�rmación de estar ante un software útil y seguro.

La única desventaja a resaltar de J2ME Polish es que es tan potente que llega a resultar algocomplejo. Además, si se quiere hacer uso de las hojas de estilos y de los archivos descriptivos enXML, es necesario tener conocimiento sobre ellas y cómo se de�nen estas características en J2MEPolish. Si se está familiarizado con hojas de estilo y XML esta labor no debería resultar muycomplicada.

8.3.12. Conclusión, uso y resultado.

Tras el estudio previo de varias librerías puestas a disposición bajo licencias de libre distri-bución, entre todas las tres que satisfacen en mayor medida los requisitos del cliente DVB-Ha desarrollar son Kuix (8.3.9), LWUIT (8.3.10) y PolishME (8.3.11), siendo esta última la quepresenta mejores prestaciones.

Por ello en un principio se decidió que J2ME Polish fuera la herramienta a utilizar para eldesarrollo de la GUI del cliente DVB-H. Sin embargo, después de añadir el entorno de desarrolloal IDE utilizado, la integración de este no era del todo satisfactoria. La migración de proyectosresultó bastante complicada y, a la hora de compilar el proyecto, el IDE era incapaz de reconocerlos distintos per�les proveídos por J2ME Polish para los que el proyecto se realiza. Es decir, elIDE no reconocía las distintas con�guraciones J2ME Polish para los distintos terminales móvilespara los cuales la aplicación se desarrolla.

Aún así, no fueron estos problemas los que hicieron que se descartara J2ME Polish comosolución. El mayor problema que presenta esta librería es el enorme tamaño que adquiere elMIDlet incluso tras ser comprimido en un �chero JAD. Así, una aplicación sencilla que haciendo

13Remote Method Invocation o RMI14Remote Procedure Call o RPC


uso de LCDUI15 típicamente ocupa alrededor de 200Kb, con el uso de J2ME Polish asciende aalrededor de 800Kb. Esta sobrecarga para una aplicación sencilla no es mayor problema, peroteniendo en cuenta que el cliente presenta bastante complejidad en su lógica, semejante aumentopodría signi�car un MIDlet �nal de un tamaño excesivamente grande, más de lo permitido porcualquier KVM16 a la hora de instalarlo.

Con J2ME Polish dejado a un lado, se decidió utilizar LWUIT sobre Kuix principalmente portres razones. La primera se re�ere al hecho de que LWUIT asegura poder integrar vídeo en suinterfaz grá�ca sin ningún problema, mientras que en Kuix hubiera sido necesario un estudio paracomprobarlo. La segunda es que LWUIT presenta un foro más dinámico que el de Kuix donde losmismos desarrolladores están implicados, además de disponer de un weblog con trucos y consejos.Por último, la tercera y última razón se debe a una mayor con�anza en LWUIT que en Kuix, yaque tras LWUIT se encuentra Sun Microsystems, una gran empresa �rmemente establecida en elsector, y, lo que es más importante, creadora de la tecnología Java, tecnología sobre la que giratodo el proyecto.

8.4. LightWeight User Interface Toolkit.

8.4.1. De�nición y características principales.

LightWeight User Interface Toolkit o LWUIT es una librería �ligera� para la creación de inter-faces grá�cas de usuario avanzadas, inspirada en Swing y diseñada para dispositivos de capacidadlimitada, como son los terminales móviles. Se distribuye bajo licencia GPLv2 con la excepción dela ruta de clases.

LWUIT se caracteriza por ser una librería altamente portable, es decir, puede ser utilizada enun amplio número de dispositivos que hay ahora en el mercado, independientemente del tamañode la pantalla en el que se mostrará la interfaz grá�ca o de la resolución de esta. Así LWUIT estápreparado para funcionar desde un amplio número de dispositivos móviles de distintos fabricantes(como Nokia�, Motorola�, LG�, etc) con distintas plataformas (Simbian, BlackBerry, Linux,etc) a otros dispositivos electrónicos como set-top boxes o decodi�cadores de TDT. Por lo tantoes portable entre MIDP (siendo necesario como mínimo MIDP2.0), CDC, SE, BB Java17, etc.Desafortunadamente, su comportamiento en plataformas Windows Mobile no es completamenteconsistente.

Siguiendo una �losofía Swing (y por tanto WIMP), LWUIT provee una serie de componentesreutilizables con los que el usuario ya estará familiarizado si es que ha programado otras interfacesgrá�cas de usuario, ya sean web o applets. Dichos componentes están distribuidos según unajerarquía. Así los componentes se agrupan en contenedores de componentes, y los contenedores sepueden agrupar dentro de otros contenedores, ya que un contenedor es otro componente a su vez.En la �gura 8.21 se muestra la jerarquía de clases de los componentes. Como se observa, muchosde los componentes tienen el mismo nombre que su equivalente en LCDUI para interfaces de altonivel (vistos en la sección 8.1.2), ya que conceptualmente cumplen con la misma función y su usoes similar.

Las clases Form y su clase heredera Dialog se corresponden con la representación de la pantallaque el usuario va a visualizar. Contrariamente a lo que parecería, Form sería el equivalente de laclase Screen de LCDUI para interfaces de alto nivel y no de Form, Dialog se corresponderíacon Alert. Como en LCDUI, una pantalla se construye mediante la adición al Form de distintosComponents según cierta disposición (o Layout), pero a diferencia de este, para mostrar ciertoformulario o diálogo en un momento dado en vez de llamar a setCurrent() tendríamos queinvocar a su método show(). Este método avisa al hilo principal de LWUIT, del que se hablará acontinuación, de que hay que mostrar este formulario en pantalla y ya el hilo se encarga de realizar

15Liquid Cristal Display User Interface16Kilo Virtual Machine, es decir, la máquina virtual de Java para JavaME.17BlackBerry Java

8.4 LightWeight User Interface Toolkit. 141

Figura 8.21: Jerarquía de clases de componentes.

esta tarea. El siguiente código muestra la creación y la con�guración del típico formulario �HolaMundo�:

// 1. Create a Form

Form mainForm = new Form("Form Title");

// 2. Set LayoutManager

mainForm.setLayout(new BorderLayout ());

// 3. Add a Label to the center of Form content pane

mainForm.addComponent(BorderLayout.CENTER , new Label("Hello World"));

// 4. Add Command key

mainForm.addCommand(new Command("Run", 2));

// 6. Show it

mainForm.show ();

No obstante, para que el anterior código funcione, lo primero que hay que hacer es inicializarla librería mediante el método estático de la clase de LWUIT Display:

Display.init(MIDlet midlet );

LightWeight UI Toolkit incluye la habilidad de adición de distintos �temas�, los cuales se puedenintercambiar en tiempo de ejecución. Esto es, se pueden diseñar distintos estilos visuales o temasque darán una apariencia u otra a la aplicación según el tema seleccionado. Para cargar un temahabría que ejecutar:

// Get Style Properties File

Resources r = null;

try {

r = Resources.open("/res/ResourceFile.res");

} catch (IOException ex) { }

// Get a specific Theme from Resource bundle

Theme myTheme = r.getTheme(r.getThemeResourceNames ()[0]);

// Set retrieved Theme

UIManager.getInstance (). setThemeProps(myTheme );

Como se ha comentado anteriormente, LWUIT también soporta una jerarquía de componentesy contenedores y una abstracción de la capa de herramientas GUI inferior. El término �ligero�indica que los componentes incluidos en la librería dibujan su estado en el código Java sin ningúntipo de renderizado propio del dispositivo donde se ejecuta.

Las interfaces internas y las clases abstractas de las que dispone LWUIT procuran la abs-tracción de las interfaces y APIs del per�l de la capa inferior. Esto permite la portabilidad y la


migración tanto de actuales como de futuros per�les y dispositivos. Por ejemplo, Graphics seríauna abstracción de los objetos grá�cos en el per�l de la capa inferior. Aún así a veces es necesariotener en mente cómo es esta capa inferior, ya que mucho de sus conceptos se heredan en estalibrería. Por ejemplo, el tratamiento en la colocación del texto sigue la misma �losofía que la vistaen las interfaces de bajo nivel de LCDUI (sección 8.1.1), el cual se explicaba haciendo uso de la�gura 8.3. El mismo concepto de punto de anclaje sigue utilizándose en LWUIT.

La librería LightWeight Toolkit intenta evitar la mentalidad �mínimo común denominador�implementando algunas características que no se incluyen en las plataformas de bajo nivel yaprovechando las mejores ventajas de las plataformas de alto nivel.

8.4.2. Ámbito y portabilidad.

La librería LightWeight UI Toolkit es estrictamente una librería de componentes de interfaz deusuario y no intenta abstraer los servicios de las capas inferiores como aquellos relacionados con co-municaciones o almacenamiento. Tampoco intenta solventar otros problemas de la UI relacionadoscon los grá�cos nativos, etcétera.

Para habilitar la portabilidad, la librería LightWeight UI Toolkit implementa una �na ca-pa propia en lo alto del �lienzo�18 del sistema nativo. Esta abstracción se consigue mediante eluso de varias clases llave que ocultan las clases especí�cas equivalentes a las susodichas clases,como son Graphics, Image y Font. Cuando se trabaja con la librería LightWeight UI Toolkites crítico el uso de estas clases abstractas para todo. Para evitar posibles corrupciones, no hayningún modo de acceder a las instancias reales de estas clases de capas inferiores (por ejemplo,javax.microedition.lwuit.Graphics). En la �gura 8.22 observamos esta �na capa para la abs-tracción.

Figura 8.22: LWUIT constituye una capa que se apoya sobre otras capas de Java de más bajonivel. La capa �Glue Layer� hace referencia a la �na capa de abstracción de las clases nativas.

LWUIT saca el máximo provecho de aquellos dispositivos con más carencias en el renderizadográ�co, como aquellos que no soportan el anti-aliasing en tiempo de ejecución, o aquellos que nofuncionan debido al tamaño de las imágenes. Para ello, la librería LWUIT se distribuye junto conun formato de �chero de recursos opcional que mejora la utilización de recursos. En la sección8.4.4 se explica con más detalle.

8.4.3. Eventos e hilos.

Para incrementar la compatibilidad, la librería LightWeight UI Toolkit gestiona y encapsulacompletamente todo lo referente a los hilos relacionados con la interfaz grá�ca. LWUIT tiene unúnico hilo principal llamado �EDT� (inspirado en el Event Dispatch Thread de Swing y AWT).Todos los eventos y las llamadas de repintado son gestionadas por este hilo. Esto garantiza quetodos los eventos y llamadas de repintado sean en serie, asegurándose así de que no se correrá

18canvas en inglés. Canvas es la clase en Java que representa el área a dibujar en la pantalla, es decir, la pantallaen sí misma.

8.4 LightWeight User Interface Toolkit. 143

ningún riesgo de un problema con los hilos. También habilita la portabilidad a aquellos per�lesque tengan un modelo de hilos con pequeñas inconsistencias.

El EDT sólo se encarga de aquellas tareas relacionadas con la interfaz grá�ca, es por eso queel resto de tareas que la aplicación pueda realizar deben ejecutarse en otro hilo aparte. De no serasí, se corre el riesgo de bloqueo del hilo principal, quedándose bloqueada la pantalla del usuario.LWUIT provee métodos en una de sus clases para serializar retro-llamadas dentro del EDT, paraasí poder sincronizar los distintos hilos.

8.4.4. El editor de recursos.

LWUIT permite los siguientes elementos como recursos:

Imágenes.

Animaciones.

Fuentes de mapas de bits.

Paquetes de localización (L10N).

Temas.

Los recursos se pueden agrupar en un paquete (un �chero binario que se puede cargar y usaren el dispositivo). En este paquete se pueden combinar distintos tipos de recursos dentro delmismo �chero, consiguiendo así tanto una mayor facilidad de distribución como una mejora enla compresión. Una aplicación puede disponer de más de un paquete de recursos. Hay que tenercuidado puesto que el �chero de recursos se cargará completamente en memoria en tiempo deejecución (debido a las restricciones de entrada/salida de JavaME), por lo que los �cheros derecursos se deben agrupar en función de las necesidades del �ujo del programa.

El editor de recursos es una herramienta para GUIs concebida aparte que permite a los expertosen interfaces grá�cas, desarrolladores y traductores abrir, crear y editar paquetes de recursospara LWUIT. El editor de recursos se diseñó como una herramienta visual que provee de unaprevisualización en �tiempo real� de todos los cambios realizados en la interfaz grá�ca, permitiendoasí una rápida personalización de los componentes.

Los recursos se agrupan en paquetes de recursos. Cada paquete dispone de varios �temas� conel que se de�ne el �look&feel� de la aplicación. Un �chero de tema es muy similar en espíritu alas hojas de estilo (CSS), siendo mucho más sencillo que estas y está estructurado además comoun �chero de propiedades de Java. Un �chero de tema se compone de pares clave/valor. La claveactúa de un modo similar a como lo hace un selector de CSS que indica el componente o atributoafectado por el valor del tema.

En la �gura 8.23 se observa un ejemplo de los temas de los que dispone un paquete de recursos.Se ve que solo hay un tema disponible, llamado BlueDifuminate.

Cada componente LWUIT tiene un estilo asociado con él. Este estilo se puede manipularmanualmente y puede ser personalizado mediante el uso de un conjunto de de�niciones para untipo de componente en concreto. Para indicar el estilo del componente, lo que es opcional, se pre�jael nombre de este al atributo, ajustando así más la selección del atributo. El valor de una entradaen el tema depende del tipo de la entrada. Algunas, como bgImage, esperan que se le asocie unobjeto imagen y otras como Font, esperan una de�nición de una fuente. La mayoría solo necesitande un valor numérico. Por ejemplo, para hacer que el fondo de todos los botones de la aplicaciónsean rojos, se puede utiliza la siguiente entrada:

Button.bgColor=ff0000

En la �gura 8.23 apreciamos distintos pares atributos/valor para distintos componentes, como elcolor de fondo (bgColor) de los botones (Button) o el tipo de fuente (font) de la barra de título(Title).


Figura 8.23: Ejemplo de pantalla del editor de recursos.

Capítulo 9

Diseño de la interactividad enLinceVisión.

Se llama interactividad a la capacidad de ofrecer contenidos adicionales a los programas detelevisión. De esta manera, el usuario podrá ver informaciones asociadas al contenido audiovisualcomo la programación de los canales. Pero, además, también podrá realizar otras acciones comoparticipar en concursos, votaciones, comprar o participar en programas de televisión a través dela interfaz grá�ca de la aplicación.

La interactividad permite a los canales de televisión ofrecer un importante conjunto de serviciosinteractivos al ciudadano, que permitan explorar nuevas formas de hacer televisión, incorporandofunciones avanzadas de comunicación y participación, y servicios sociales para el desarrollo de lasociedad de la información. Por el lado de los usuarios, la interactividad va a permitir acceder anuevos contenidos, a una televisión mucho más rica y completa, con la posibilidad de participar ein�uir en los programas de televisión.

Figura 9.1: Esquema de interactividad remota en DVB-H.

La información relativa a la interactividad está contenida dentro de la ESG, que se distribuyepor el canal de difusión mediante una señal DVB-H. Esta información se codi�cará en la ESG conun formato u otro, o ni siquiera tendrá formato de�nido, dependiendo del estándar que se utilice

146 Diseño de la interactividad en LinceVisión.

para la descripción de la ESG. La tecnología utilizada en el canal de difusión que se contempla eneste proyecto es IPDC.

9.1. Tipos de interactividad.

La interactividad puede ser de dos tipos:

Interactividad local:

El espectador interactúa con la información que está almacenada en el receptor, la cual serenueva con cierta periodicidad.

Con la interactividad local el usuario puede acceder a contenidos interactivos pero no puedeenviar datos de vuelta. Ejemplos de aplicaciones interactivas locales son la navegación porlas Guía de Programación (EPG), estadísticas, o información sobre los participantes en unprograma.

Interactividad remota:

El espectador interactúa con un proveedor de servicios exterior, al que se conecta medianteun canal de retorno. Este canal de retorno será a través de la red móvil (UMTS/GSM-GPRS)a la que el dispositivo móvil está conectado.

La interactividad con canal de retorno permite no solo ver contenidos adicionales a la pro-gramación y navegar por ellos, sino también enviar respuestas por parte de los usuarios,e incluso comunicarse con otros usuarios. La interactividad con canal de retorno es la quepermite a los usuarios participar en concursos, votar, o enviar mensajes a otros usuarios.

En la �gura se muestra un esquema de este tipo de interactividad.

A su vez, se pueden establecer tres categorías de servicios interactivos:

Servicios de información:

Son aquellos que ofrecen una información independiente de la programación audiovisual quese está emitiendo en ese momento

Servicios ligados a la programación:

Son aquellos que complementan con información suplementaria la programación audiovisualemitida

Servicios transaccionales:

Son aquellos que ofrecen la posibilidad de enviar y recibir información de forma personalizaday exclusiva

Tipos de Servicio Interactividad LOCAL Interactividad REMOTA

Servicios de

información

Navegación por la informaciónpresente en la Guía electrónicade la programación.

Descarga de archivosdifundidos..

Juegos.

Cuadro 9.1: Relación entre los tipos de Servicios interactivos y deInteractividades.

9.1 Tipos de interactividad. 147

Tipos de Servicio Interactividad LOCAL Interactividad REMOTA

Servicios ligados a la

programación

Estadísticas.

Noticias desarrolladas.

Información ampliada sobre el

programa.

Participación en concursos.

Votaciones.

Visita servicio web (páginaweb, descarga de archivosalojados en el servidor, etc.).

Pago por visión.

Servicios

transaccionales

Reservas de plazas.

Consultas bancarias.

Compras.

Cuadro 9.1: Relación entre los tipos de Servicios interactivos y deInteractividades.

En el apartado 7.1, �Funcionalidad�, se ha comentado aquellas interactividades que LinceVisiónva a implementar. Estas interactividades son:

Voto. El voto es un servicio interactivo generalmente ligado a la programación que consisteen una cuestión sobre la que se va a realizar la votación y un conjunto de respuestas asociadasa dicha cuestión. La información principal en relación al voto es:

� Texto identi�cativo de la votación.

� Tipo de votación.

� Pregunta de la votación.

� Identi�cador de servicio o programa al que la votación está asociado.

� Respuestas de votación.

� Una URL asociada a cada una de las respuestas. Esta dirección se corresponderá conel destino con el que la aplicación tendrá que establecer una conexión para registrar larespuesta de votación a la que esta dirección está asociada.

Tenemos dos tipos de votaciones según el tipo de canal de retorno utilizado para registrarla opción elegida por el usuario:

� Votación vía HTTP: Se establece comunicación mediante el protocolo HTTP con unservidor web en el que se registra las votaciones de todos los usuarios.

� Votación vía SMS1: Se establece comunicación mediante el sistema de mensajes cortos(SMS). El mensaje corto construido se mandará a un servidor de mensajes cortos en elque se registra las votaciones de todos los usuarios.

Link externo2. El link externo es un servicio interactivo generalmente ligado a la progra-mación que consiste en una dirección web que el usuario puede visitar para obtener cierto

1Para que LinceVisión soporte la votación vía SMS es necesario que el dispositivo móvil disponga de la API JSR-205 (WMA2.0). En el apartado 7.4, �Portabilidad�, se habla con más detenimiento del porqué de esta circunstancia.

2Este tipo de interactividad solo puede soportarse si la máquina virtual incluye JNI. Además, es necesario perso-nalizar esta interactividad para cada máquina virtual de cada dispositivo, ya que es necesario programar la llamadaal método nativo, ya que será distinta dependiendo del sistema operativo del dispositivo y de la implementación dela librería JNI de la que dispone la KVM. En el apartado 7.4, �Portabilidad�, se habla con más detenimiento delporqué de esta circunstancia.


servicio, ya sea consultar una página web o descargar un archivo alojado en un servidor web.Al usuario se le presentará dicha dirección en forma de hipervínculo sobre el cual el usuariopuede cliquear para acceder. Esta acción provocará que LinceVisión lance el navegador delterminal, que ya se encargará de mostrar y gestionar el servicio web visitado. La informaciónque debe llegar en la ESG relativa al link externo es:

� Texto identi�cativo del link.

� Texto descriptivo del link externo.

� URL asociado al link.

Servicio de descarga. Junto con la ESG se pueden distribuir por el canal de difusióndistintos archivos de los que el usuario puede disponer, como son �cheros de audio, imágenes,etc. Estos archivos se enviarán del mismo modo que la ESG, es decir, haciendo uso delprotocolo FLUTE3. Para que el usuario tenga conocimiento de estos archivos y el clientepueda acceder a ellos, en la ESG se envía información relativa a ellos. Como los archivos seestán distribuyendo en la misma señal de difusión esta interactividad no hace uso del canaldel retorno.

Un caso de mención aparte sería la navegación por la Guía electrónica de programas (EPG)4.La EPG en sí no es interactividad. La interactividad relacionada con la EPG es la habilidad denavegar a través de ella, es decir, la posibilidad de que el usuario interaccione con la aplicación através de menús que conducirán a la selección de un tipo de información determinada contenidaen la EPG. De esta forma el usuario podría �ltrar la información que quiere recuperar de la EPGsegún cierto criterio dado por los menús. Un ejemplo sería que el usuario quisiera ver un listadode los programas de un mismo tipo, como programas deportivos. Esta última característica no secontempla en la realización de este proyecto. En LinceVisión se dará soporte a la representaciónde la información contenida en la EPG, tanto en forma de lista para una EPG de un sólo canalcomo en forma de cuadro para una EPG de canal múltiple, pero no se permitirá la navegación porella. En el capítulo 10 se habla con más detenimiento acerca de su representación.

9.2. Problemática en torno a la interactividad.

La JSR-272 provee de métodos para la obtención de información acerca de los servicios detelevisión y de descarga presentes en la ESG seleccionada. También provee de métodos para larepresentación de la señal de vídeo y audio relativa a un servicio de televisión. Sin embargo,la JSR-272 no provee de métodos para la obtención de la información relativa a lainteractividad contenida en la ESG, a excepción del servicio de descarga, EPG y pagopor visión. Esto supone un gran problema, ya que esto implica que no existe ninguna maneraestándar de acceder a dicho contenido interactivo presente en la ESG, por lo que cualquiermanera de acceso a dicho contenido será siempre dependiente de la implementaciónconcreta de la JSR-272.

Esto se debe a que la JSR-272 es un estándar abierto que pretende establecer un marco comúnpara todas las tecnologías que pueden subyacer a la JSR-272, de forma que sólo especi�ca el máximocomún divisor de todas ellas. La JSR-272 se concibió para ser independiente de la tecnología dedifusión que se utilice (ya sea IPDC, OMA BCAST, DMB...), de esta manera dos dispositivos queimplementen distintas especi�caciones para la recepción de servicios de difusión móviles puedeninteroperar siempre que tengan instalada la plataforma JavaME y utilicen la API JSR 272. Comolas especi�caciones para la difusión de servicios no son coincidentes en cuanto a la de�nición degran parte del contenido interactivo (los tipos de interactividad que existen, la información relativaa cada uno de ellos, su modelo de datos en la ESG, etc.), se hace imposible que la JSR-272 de�naun sistema común y único de uso de la interactividad para todas las tecnologías de difusión. Por

3Más información sobre �ute en la sección 3.3.2 del capítulo �IPDC�.4Para más información sobre la EPG, diríjase a la sección 3.4.1.1.

9.2 Problemática en torno a la interactividad. 149

ello se dejó el estándar abierto para que cada implementación de la JSR-272 para una tecnologíade difusión en concreto añada nueva funcionalidad particular a dicha tecnología.

Dejando el estándar abierto a nuevas extensiones convenientemente pensadas para un tipo detecnología subyacente concreta, se consigue dar un mayor alcance a la JSR-272 así como satisfacera la mayoría de clientes, pues la funcionalidad principal, es decir, la visualización del �ujo de vídeoy audio y la obtención de información acerca de los servicios de televisión, se ve del todo satisfecha.Para conseguir esta expansibilidad, la JSR-272 provee de mecanismos de integración de funcionali-dad añadida de los que puede hacer uso cada implementación para soportar nuevas características,como la posibilidad de poner a disposición al cliente el contenido interactivo de la ESG, pero eldesempeño de esta funcionalidad añadida será siempre particular de dicha implementación. Losmecanismos de extensión se consiguen mediante la adición de nuevas clases MetadataSets y denuevas clases ServiceGuideDatas, en caso de ser necesarios, o la ampliación de las ya existentes.

Así pues, cualquier cliente de la JSR-272 puede estar seguro de que dispondrá de esta funcio-nalidad básica, pero no podrá asegurar que el resto de contenido mandado en la señal de difusiónvaya a estar disponible. Para ello tendrá que conocer la implementación concreta de la JSR-272de la que está haciendo uso, averiguar si provee de alguna funcionalidad adicional y particulari-zarse para dicha implementación. La parte de interactividad no obtenible a partir de la de�niciónestándar de la JSR-272 presente en la aplicación que se desarrolla en este proyecto está pensadapara usarse con una implementación cuya tecnología de difusión subyacente sea IPDC.

Sin embargo, al utilizar esta tecnología subyacente surge un nuevo problema: el estándar IPDCno recoge la interactividad (y con �interactividad� nos estamos re�riendo a aquella que no es EPG,servicios de descarga o pago por visión) como una parte de él, es decir, en su especi�cación de laESG no de�ne ningún modelo de datos para la interactividad, ni los tipos existentes, etc. En lasección 3.4.1 del capítulo sobre IPDC, se vieron todos los datos que se envían en la ESG, y ningunode ellos se correspondía con la información relativa a la interactividad. IPDC sigue la mismaestrategia que la JSR-272: integra un mecanismo de extensión para que un servidor de contenidosespecí�co de�na tipos de contenido particular en la ESG. Es obvio que dicho contenido sólo lopodrá entender una implementación de JSR-272 que tenga conocimiento de él. Este mecanismo deextensión se consigue mediante las indicaciones del anexo D del estándar IPDC para la descripciónde la ESG5: �Extensibility of the ESG Schema�.

No obstante, la especi�cación también recoge un tipo de datos básico, llamado �Related Ma-terial �, que concuerda con la interactividad que hemos llamado Link Externo. Concretamente,el tipo de datos RelatedMaterial se utiliza en varios tipos de fragmentos para habilitar la loca-lización de recursos media que están relacionados con los fragmentos XML de la ESG (es decir,fragmento Content, Service o ServiceBundle). Los campos que encontramos en un tipo de datoRelatedMaterial son:

Campo Descripción

HowRelated

Especi�ca la naturaleza de la relación entre el fragmento

descrito ( fragmento Content, Service or ServiceBundle) y los

recursos media relacionados.

MediaLocatorEspeci�ca la localización del recurso media. Se de�ne como

un tipo de datos de MPEG-7, MediaLocatorType.

PromotionalText Especi�ca la información promocional acerca del link.

PromotionalMediaEspeci�ca la información promocional que no es de tipo

texto, como un logo.

Cuadro 9.2: Campos de RelatedMaterial.

Sin embargo, la JSR-272 no especi�ca ningún mecanismo para obtener dichos campos conte-nidos en RelatedMaterial, a excepción del campo MediaLocator, el cual se puede obtener a través delas variables de instancia de CommonMetadataSet SERVICE_REL_MATERIAL y PROGRAM_REL_MATERIAL,según si este RelatedMaterial está asociado a un fragmento Content o a un fragmento Service.

5ETSI TS 102 471 V1.2.1.


Así pues, como ya concluimos anteriormente, es necesario hacer uso de una implementación dela JSR-272 ad hoc extendida de forma que se pueda obtener tanto la interactividad de tipo voto(que habrá que de�nir completamente ya que el estándar de ESG de IPDC no lo contempla) comopara obtener el resto de información relativa al Link Externo. A su vez, esta implementación dela JSR-272 basada en IPDC tendrá que ponerse de acuerdo con el proveedor de contenidos acercadel nuevo contenido interactivo particular añadido en la ESG.

La aplicación de la que este proyecto versa va a hacer uso de la implementación de la JSR-272desarrollada a la par por el área de Telemática, departamento de Automática, de la Universidadde Sevilla. Ambos desarrollos se contemplan dentro del proyecto 3C-048 contenido en el proyectoMinerva, del que ya se habló en el capítulo 1º, sección 1.4.

9.3. Interactividad de tipo Voto y Link externo.

En coordinación con el equipo de desarrollo de la JSR-272 del área de Telemática de la Univer-sidad de Sevilla, se ha diseñado y acordado un mecanismo para la obtención de interactividad detipo voto y link externo a través de dicha implementación de la JSR-272. En principio solo se vaa contemplar la interactividad asociada a un fragmento Service, siendo ampliable a un fragmentoContent en una etapa posterior.

Para ello, se ha ampliado la clase Service de la JSR-272, disponiendo esta ahora del siguientemétodo:

public Interactivity [] getInteractivities () throws IllegalArgumentException;

Este método devuelve un array de objetos Interactivity asociados a dicho Service. La claseInteractivity es una abstracción de cualquier tipo de interactividad contenida en la ESG, dela que heredarán las clases que representen a una interactividad concreta, de momento, las clasesBallot y ExternalLink. En la �gura 9.2 se re�eja un diagrama UML de dichas clases.

Figura 9.2: Diagrama UML de las clases de interactividad.

En la clase Interactivity se de�nen los tipos de interactividad posibles mediante las constan-tes: TYPE_BALLOT y TYPE_LINK. Para saber qué tipo de interactividad es la devuelta por el métodogetInteractivities() de Service, solo habrá que preguntarlo a través del método getType().

9.4 Presentación de contenido interactivo tipo Voto y Link externo. 151

Además se de�ne que una interactividad puede encontrarse en un estado determinado. Estos es-tados están descritos por las constantes:

STATE_ACTIVE: La interactividad aún está activa y el usuario puede hacer uso de ella.

STATE_DONE: El usuario ya ha hecho uso de la interactividad.

STATE_CANCELLED: El usuario ha prescindido de la interactividad.

Del mismo modo, para averiguar en qué estado se encuentra habrá que invocar a su métodogetState().

La clase Ballot hereda de Interactivity y representa una votación. Como se aprecia en eldiagrama, se de�nen dos tipos de votaciones con las constantes HTTP_BALLOT y SMS_BALLOT, repre-sentando cada una los dos tipos de votaciones comentados anteriormente. En esta clase encontra-mos métodos para obtener la información relativa al voto, como el tema a través de getQuestion()y las posibles respuestas a través de getAnswersText().

La clase ExternalLink hereda de Interactivity y representa un link externo. En esta claseencontramos métodos para obtener la descripción del link a través de getDescription() y suURL a través de getHiperLink().

9.4. Presentación de contenido interactivo tipo Voto y Linkexterno.

El propósito de este apartado es mostrar diferentes propuestas para la presentación al usuarioy sus modos de interacción con la información interactiva proveniente en la guía de servicioselectrónicos (ESG). Así mismo se intentará resaltar las posibles ventajas e inconvenientes quepresenta cada una de las opciones estudiadas, de forma que sirva de ayuda y guía a la hora dedecidir la presentación �nal que se incluirá en el cliente DVB-H a desarrollar.

Las características buscadas en una interfaz grá�ca de usuario (GUI) para la presentación deservicios interactivos son:

Alta portabilidad: se busca un funcionamiento único o lo más parecido posible en un amplioabanico de dispositivos, lo que signi�ca una total abstracción de la GUI con respecto a lascaracterísticas HW y SW del dispositivo. De no conseguirse, se busca una alta versatilidadde la GUI para que pueda adaptarse a los distintos dispositivos de la manera más simple.

Alta visibilidad de los elementos interactivos: la disponibilidad del servicio interactivo tieneque ser de fácil percepción por el usuario y de fácil acceso.

Facilidad de interacción por parte de usuario: se pretende una presentación sencilla e intui-tiva.

Sin embargo se presentan varios escollos a tener en cuenta a la hora de programarlos:

Poca versatilidad a la hora de crear interfaces grá�cas con JavaME. Esta viene determinadapor las librerías y/o herramientas que se utilicen para ayudar a la creación de GUIs.

Complejidad de programación.

Diversidad de dispositivos: distintos tamaños de pantallas, de colores, etc.

Limitaciones del middleware que presenta el dispositivo: implementaciones de APIs incom-pletas, limitación de acceso a archivos, etc. En concreto, nos afecta principalmente que existao no la característica de superposición de grá�cos en la JSR-272. Como se explica en el apar-tado del capítulo 2º, la superposición de grá�cos es una habilidad obligatoria. Sin embargo


puede suceder que al interrogar si dicha implementación posee de dicha habilidad6 la res-puesta sea negativa. Esta posible limitación es un factor crítico a la hora de considerar eldiseño de la presentación de la interactividad.

Limitaciones de recursos del dispositivo: poca memoria RAM, bajo rendimiento del proce-sador, etc.

9.4.1. Presentaciones en distintos clientes ya desarrollados.

En este apartado se encuentra los distintos modos de interactuar con algunos clientes ya im-plementados, comerciales o de prueba, que han sido estudiados.

SalmonStream.

SalmonStream es un cliente de prueba de la empresa Axel Technologies. Es capaz de interpretarla información interactiva contenida en la ESG y presentarla en pantalla. Cuando un elemento conel que el usuario puede interactuar se detecta en la ESG, en la barra inferior (soft bar) apareceun botón (soft key) con la etiqueta �Interactivity� en la parte derecha (Figura 9.3). Al seleccionaresta opción (bien pulsando directamente sobre el botón si la pantalla es táctil o bien pulsando elbotón del teclado situado en la parte inmediatamente inferior, en el caso de poseer un terminal conbotonera, ya tenga pantalla táctil o no) cambiará la pantalla que en ese instante se está mostrandoa una nueva donde se mostrará la información relativa al elemento interactivo. Esto quiere decirque la pantalla en la que se mostraba el vídeo que en el momento en el que el elemento interactivosurgió deja de ser visible para dar lugar a la nueva con la información del elemento interactivo.Así en el caso del voto, aparece una nueva pantalla con una lista de elección no desplegable en la

Figura 9.3: SoftKey mostrando la opción de interactuar en SalmonStream.

que el usuario puede elegir su opción al pulsar sobre uno de los elementos de dicha lista (Figura9.4). En el caso de utilizar la botonera, mediante las teclas de dirección se puede navegar a travésde los elementos de la lista, de forma que al situarse sobre la opción elegida el pulsar el botón deselección tendrá el mismo efecto que pulsar sobre la pantalla táctil.

Como ventajas cabe destacar:

Sencilla programación.

Poca sobrecarga en el terminal: no es necesario refrescar la pantalla para mostrar la nuevainformación mientras el vídeo continúa reproduciéndose.

6Esta información se obtiene a través de la propiedad del sistema microedition.broadcast.supports.overlay. Másinformación en la sección 6.5.1 del capítulo 6: �JSR-272�.


Figura 9.4: Menú interactivo de SalmonStream.

Alta portabilidad.

Como desventajas:

Para el usuario es difícil notar que un nuevo elemento interactivo está disponible a su servicio,ya que su atención está concentrada en el vídeo.

El vídeo se deja de mostrar al usuario mientras interactúa, lo que puede disuadirle de hacerlopara poder seguir viendo el programa.

EyePhone.

EyePhone es un cliente de prueba de la empresa Thompson. Cuando un elemento con el que elusuario puede interactuar se detecta en la ESG, se informa al usuario de este evento presentandouna pequeña imagen de aviso, consistente en un triángulo de color amarillo situado en la esquinainferior derecha de la imagen logotipo del servicio que se visualiza en dicho instante, como seobserva en la Figura 9.5.

Figura 9.5: Aviso de nuevo elemento interactivo en EyePhone.

Al pulsar sobre el aviso, aparece la información relativa al elemento de interacción en la parteinferior de la pantalla, sustituyendo a la información presentada relativa al servicio y programa


que en ese preciso momento se está emitiendo en la parte superior. Esto implica que esta opciónde presentación es solo posible en terminales que poseen pantallas táctiles. También hay que notarque en ningún momento el vídeo se deja de mostrar, sino que es el espacio inferior reservadopara mostrar información, el que va actualizando su contenido. En la Figura 9.6 se muestra lapresentación de la información relativa a un elemento interactivo de tipo voto.

Figura 9.6: Desplegable para el voto en EyePhone

El voto se presenta como un desplegable de distintas opciones donde el usuario selecciona unay lo con�rma pulsando el botón de voto.


El servicio interactivo no molesta al usuario ni obstruye el visionado del vídeo.

Facilidad de interacción.

Como desventajas:

Para el usuario es difícil notar que un nuevo elemento interactivo está disponible a su servicio,ya que su atención está concentrada en el vídeo.

Si el vídeo está en pantalla completa, el usuario no se percatará del servicio interactivo quetiene a su disposición.

Poca portabilidad: solo disponible para terminales con pantallas táctiles.

Penthera Viewer.

Penthera Viewer es un cliente comercial de la empresa Penthera. Es capaz de interpretar lainformación interactiva contenida en la ESG y presentarla en pantalla. Para ello hace uso deetiquetas y botones sobrepuestos en el vídeo que se está mostrando por pantalla, como se ve en laFigura 9.7.


El servicio interactivo es fácil de notar por el usuario: el servicio se le presenta directamentesin necesidad de que el usuario tenga que acceder a él.

Facilidad de interacción: un sólo click es necesario.

Alta portabilidad.

Como desventajas:


Figura 9.7: Interfaz de voto en Penthera Viewer

El servicio interactivo obstruye el visionado del vídeo y puede importunar al usuario, ya quepuede cubrir una parte importante de la imagen.

Para el caso de dispositivos sin pantalla táctil, la interacción se tiene que hacer a través delteclado numérico y no a través de las soft keys, mucho más comunes a la hora de selección.

Al usuario no se le da la posibilidad de cancelar la presentación del servicio interactivo (sepresupone que durará en pantalla el tiempo estimado).

Programación compleja.

9.4.2. Otras posibilidades de presentación para LinceVisión.

Aquí se presentan otras posibilidades de presentación consistentes en mejoras de las ya explica-das mediante la adición de algunos nuevos elementos o la combinación de algunos ya presentados.

Diálogos de alertas.

Esta aproximación consiste en mostrar en pantalla, cuando se detecte un nuevo servicio in-teractivo, un cuadro diálogo de alerta en el que se informe al usuario de dicho evento. En él sedará opción de lanzar el servicio interactivo o de cancelarlo. Este pop-up sería mostrado al usuariotanto en el caso de estar visionando la emisión a pantalla completa como a pequeña pantalla. Ala hora de mostrar los datos del servicio interactivo se dispone de varias opciones:

1. Mostrarlos en una nueva pantalla, tal y como ocurre en el caso de voto en SalmonStream(Figura 9.4), con las ventajas e inconvenientes ya explicados que esto conlleva.

2. Mostrarlos en un área destinada para ello, como ocurre en EyePhone (Figura 9.6), con lasventajas e inconvenientes ya explicados que esto conlleva. Además, en el caso de que elcliente hubiera estado visionando la emisión a pantalla completa esto supondría volver almodo pequeña pantalla

Como ventajas esta aproximación presenta:

Extrema facilidad de apreciación por parte del usuario de disponibilidad de servicio interac-tivo.

Posibilidad de descartar el servicio.

Las posibles desventajas son:

Los pop-ups son generalmente molestos, ya que interrumpen el visionado.

Uso del servicio interactivo en dos pasos.


Menú interactivo en espacio informativo.

Esta aproximación sería parecida a la ofrecida por EyePhone (apartado 9.4.1) solo que con unamejora: en vez de informar al usuario de la disponibilidad de un servicio interactivo mediante unpequeño icono sobre el que usuario puede pulsar, directamente el espacio inferior reservado paramostrar la información relativa al servicio y programa que en ese momento el usuario está visionan-do, sería cambiado por un menú interactivo con la información obtenida del servicio interactivo.Dicho menú sería navegable usando las teclas de dirección o pulsable en pantallas táctiles.

Como ventajas presenta:

Mayor impacto visual en el usuario: para él, seria más sencillo percatarse del servicio dispo-nible.

Más versatilidad: válido para pantallas táctiles y con teclado.

Más facilidad de acceso al servicio interactivo: un sólo click sería necesario.

Como desventajas:

No presenta ninguna solución para el aviso de interactividad presente en el caso en el queel usuario esté visionando el programa a pantalla completa. Una forma de resolver esteproblema, solo en este caso de pantalla completa, podría mostrársele al usuario un avisocomo el explicado en el apartado 9.4.2 de forma que si el usuario acepta le lleve al modopequeña pantalla con el menú interactivo en el espacio informativo.

Menú interactivo sobre pantalla de vídeo.

Esta aproximación sería parecida a la ofrecida por PentheraViewer (apartado 9.4.1) solo quecon una mejora: el menú presentado sería navegable usando las teclas de dirección o pulsable enpantallas táctiles. Además, se añadiría una opción para cancelar este menú, de forma que al pulsarsobre esta opción el menú desapareciera y el vídeo emitido se volvería a ver sin nada que lo tape.

Como ventajas presenta:

Mismo impacto visual que el obtenido con la solución PentheraViewer.

Más versatilidad: válido para pantallas táctiles y con teclado.

Misma facilidad de acceso al servicio interactivo: un sólo click sería necesario.

Menos molesto para el usuario ya que tiene la posibilidad de hacer desaparecer el menú.

Como desventajas:

Sigue conservándose la misma desventaja encontrada en PentheraViewer: es posible queincluso a pantalla completa, el menú interactivo ocupe una zona en la que se muestra infor-mación visual importante (ej. el rostro del actor de situarse el menú en la parte superior).

En el caso en el que el usuario esté visionando la emisión a pequeña pantalla, la informaciónde interacción superpuesta al vídeo ocuparía la mayoría del espacio dedicado a este, por loque el usuario dejaría de ver el programa con las molestias que esto conlleva.

9.4.3. Presentación �nal elegida.

Tras evaluar las posibilidades se ha decidido que la mejor opción es seguir un formato parecidoal explicado en el apartado anterior como �Menú interactivo en espacio informativo�. Es la quepresenta más ventajas y los inconvenientes son relativamente fáciles de salvar.

Surge un problema cuando existe más de un contenido interactivo disponible en un momen-to determinado. En este caso el área informativa reservada es insu�ciente para mostrar toda la

9.5 Servicios de descarga. 157

información relativa a cada contenido interactivo. Para solventar este inconveniente se ha opta-do por presentar una lista noti�cativa de los contenidos interactivos disponibles, de forma que elusuario pueda seleccionar el contenido deseado (tanto pulsando sobre el elemento de la lista comoeligiéndolo a través de las teclas de navegación). Al seleccionarlo, este se mostrará en una nuevapantalla, tal y como ocurre en el caso de voto en SalmonStream. Al volver a la pantalla anterioren el área de noti�cación se seguirá mostrando todas las interactividades disponibles en caso deque el usuario quiera hacer uso de otra.

9.5. Servicios de descarga.

Los servicios de descarga si están contemplados en la especi�cación de la JSR-272. Estosservicios se representan con la misma clase que la utilizada para los servicios de televisión, Service.Del mismo modo que en los servicios de televisión, los servicios de descarga tendrán asociado uncontenido determinado para un momento concreto (representado por la clase ProgramEvent), esdecir, para un servicio existen varios eventos programados en los que se encuentra disponible ciertocontenido. Este contenido será un archivo descargable en el caso de un servicio de descarga. Laforma de recuperar la información es obviamente la misma al utilizarse las mismas clases, a travésde CommonMetadataSet.

En LinceVisión los servicios de descarga se tratarán paralelamente a los de televisión. Delmismo modo que se presenta una lista con los servicios de televisión, se presentará una lista conlos servicios de descarga con todos aquellos contenidos disponibles en ese momento.

Capítulo 10

Diseño de la representación de laEPG.

10.1. Introducción.

En el capítulo anterior se ha comentado que no se va a implementar la interactividad relacionadacon la EPG, es decir, la navegación a través de la información contenida en ella. Sin embargo síque esta se va a mostrar al usuario, ya que es una de las funcionalidades que LinceVisión va aimplementar. En este capítulo se habla de posibles técnicas de representación de la EPG en lapantalla del dispositivo móvil y de los tipos de representaciones �nalmente elegidos.

Debido a que la información contenida en la ESG se transmite en forma de datos más quede manera visual, es posible implementar nuevas técnicas de ordenado y de representación deestos datos, proveyendo al usuario de una nueva y más grata experiencia visual. Estas técnicaspermiten al usuario encontrar los programas de los que desean obtener información de una manerarápida y e�ciente con muy poco conocimiento previo del sistema subyacente. Para ello una base dedatos se mantiene dentro del dispositivo que muestra la EPG. Los usuarios podrán acceder a estainformación para su representación en la pantalla cuando así lo deseen, guiados por la informacióny el estilo de los datos recibidos.

Un servicio incluye datos de los programas de su propia cadena, o incluirá datos tanto de supropia cadena como de otras. En cualquier caso, los datos en la EPG siempre tienen el mismoformato.

Existen diversas estructuras para la representación de la EPG. Estas son:

En el espacio: se distribuye la información en dos dimensiones.

En el tiempo: la información va cambiando conforme el tiempo avanza.

A través de links: el usuario va navegando de información a información a través de links.

Una combinación de cualquiera de las tres anteriores.

En la �gura 10.1 se muestra diversas con�guraciones a la hora de representar la EPG.El éxito en la representación de una EPG depende fuertemente de los recursos disponibles

en el receptor, como de su capacidad de almacenamiento y de procesado, como también de sucapacidad grá�ca (es decir, el tamaño y resolución de su pantalla). Así que hay que tener encuenta las restricciones existentes en la representación de la EPG según el medio. Por ejemplo, enuna estructura espacial (la más común) algunas de las restricciones a tener en cuenta son:

La representación de la información no puede exceder los límites del rectángulo donde seencuadra.

160 Diseño de la representación de la EPG.

Figura 10.1: Estructuras de presentación de EPG.

Si hay más información de la que se puede representar, el usuario debe poder desplazarsepor ella. Esto puede implicar la adición de otra dimensión, como el tiempo (es decir, lainformación contenida en el rectángulo cambia con el tiempo), o links.

La imagen debe mantener la proporción anchura/altura conforme el usuario se desplaza porla EPG.

Conforme mayor sea la información que la EPG contiene, más capacidad de almacenamiento,menús más avanzados y más versatilidad de disposiciones en la pantalla serán necesarios. Se haceindispensable entonces encontrar una solución de compromiso que haga la experiencia del usuariocuando navegue a travér de la ESG lo más satisfactoria posible.

10.2. Representaciones propuestas por la especi�cación de laEPG.

En el documento ETSI EN 300 707 V1.2.1: �Electronic Programme Guide (EPG)�, se muestrandistintos ejemplos posibles representaciones de la información contenida en la EPG. En la �gura10.2 se muestran estos ejemplos.

Todas las representaciones de la �gura 10.2 siguen una estructura espacial, excepto en el últimocaso en el que se combina espacial con link.

10.3. Representación en LinceVisión.

Al ser LinceVisión una aplicación destinada a los dispositivos móviles, hay que tener muypresente las restricciones que este tipo de dispositivos presenta, siendo estos principalmente tres:

Poca memoria volátil disponible.

Poca capacidad de representación de grá�cos.

Pantallas de dimensiones pequeñas.

La primera restricción nos obliga a no obtener toda la información de la EPG difundida, puesesta información puede ser bastante cuantiosa (la programación recogida puede extenderse en el

10.3 Representación en LinceVisión. 161

1. Programas de un solo canal.

(Programa en emisión y siguiente

+ un mensaje de la cadena emisora).

2. Programas de un solo canal.

(Programas del día

+ un mensaje relacionado).

3. Programas en emisión de varias

cadenas.

4. Disposición en forma de Menú

usando una representación

de Mapa de Bits.

Figura 10.2: Ejemplos de representación de EPG en la especi�cación.

tiempo varios días). Lo más sensato es obtener la programación desde el momento actual hasta el�n del día.

La segunda restricción obliga a confeccionar menús simples, que no necesiten de mucha capa-cidad de procesamiento para ser presentados al usuario.

La tercera es sin duda la que más inconvenientes presenta a la hora de implementar un menúpara la representación de la EPG. Debido a las pequeñas dimensiones de la pantalla, es poco eltexto que en ella se puede mostrar. Esto obliga a:

No incluir la descripción de todos los programas que se muestran, por lo que habrá queimplementar un mecanismo de links para acceder a la información. Se pre�eren links másque una estructura temporal porque mediante los links es el usuario el que controla cuándoquiere obtener la descripción del programa.

Representar sólo la información que se pueda enmarcar en la pantalla de forma que el usuariopueda entenderla fácilmente, es decir, no hacer uso de texto y/o cuadros excesivamentepequeños. Esto implicará que la información �nalmente mostrada sea bastante escasa, loque conlleva a incluir un mecanismo de desplazamiento a través de ella para que el usuariopueda obtener una información más completa de la EPG.

Por todo lo anterior se ha decidido mostrar la EPG en dos formatos:

Uno que es menos exigente con el dispositivo, pero que muestra menos información. Este secorrespondería con el segundo ejemplo representado en el apartado anterior. En él se tieneuna lista de los distintos programas para un canal concreto. En la parte inferior se tiene

162 Diseño de la representación de la EPG.

un mensaje donde se muestra la descripción de un programa. Esta descripción cambiaráconforme el usuario se desplace por los distintos elementos de la lista (es decir, cada elementode la lista tiene un link a su descripción, la cual se presenta en la parte inferior).

Uno más exigente con el dispositivo, donde se muestra la información de programación paravarios o todos los canales simultáneamente. En este formato se presenta la EPG en formade cuadro o tabla. En el eje de abcisas se tiene una línea temporal, mientras que en el deordenadas se sitúan los distintos canales disponibles. La información relativa a cada programase muestra en cada una de las celdas de la tabla o cuadro. Estas celdas representado a cadaprograma no son �jas para cada �la o columna, sino que se desplazarán a lo largo del ejetemporal según la hora de comienzo y la duración del programa. En la �gura 10.3 se muestraesta representación.

Figura 10.3: Representación de EPG en forma de cuadro o tabla.

Este tipo de representación es muy común, generalmente el elegido por los decodi�cadoresde TDT. Sin embargo plantea grandes retos, ya que las restricciones espaciales en este tipode representación son muy estrictas. Es necesario diseñar un mecanismo de representaciónpara que el cuadro cumpla con las restricciones de las que se hablaba en la introducciónde este capítulo. Del algoritmo que implementa este mecanismo se hablará en la parte V:�Arquitectura del software�, representado por su �gura 15.14.

Bibliografía

[1] Evaluación de calidad web: Métodos, técnicas y uso de métricas de usabilidad. Carlos D.González. Junio del 2009:http://www.usabilidadweb.com.ar/metodos_eval_calidad_web.php

[2] McCall, J. A., Richards, P. K., and Walters, G. F., "Factors in Software Quality", Nat'lTech.Information Service, no. Vol. 1, 2 and 3, 1977.

[3] The ISO 9126 Standard:http://www.issco.unige.ch/en/research/projects/ewg96/node13.html

[4] Artículo de opinión �How MIDlet Signing is Killing J2ME � por Sam Halliday, publicado enagosto de 2007 en el blog Javablog :http://javablog.co.uk/2007/08/09/how-midlet-signing-is-killing-j2me/

[4] jMobileCore:http://jmobilecore.sourceforge.net/

[5] Licencias GNU:http://www.gnu.org/licenses/licenses.es.html

[6] Abstract Window Toolkit:http://java.sun.com/products/jdk/awt/

[7] SwingMe:http://yura.net/projects/swing-me

[8] Swing:http://java.sun.com/javase/6/docs/technotes/guides/swing/

[9] J4ME:http://code.google.com/p/j4me/

[10] Licencia Apache 2.0:http://www.apache.org/licenses/LICENSE-2.0.html

[11] Apime:http://www.java4ever.com/index.php?section=j2me&project=apime&menu=

main&lang=_en

[12] Fire2:http://sourceforge.net/projects/fire-j2me/

[13] MWT:http://j2me-mwt.sourceforge.net/

[14] MicroEWT:http://www.esoco.net/content/view/7/1/

http://www.usabilidadweb.com.ar/metodos_eval_calidad_web.php

http://www.issco.unige.ch/en/research/projects/ewg96/node13.html

http://javablog.co.uk/2007/08/09/how-midlet-signing-is-killing-j2me/

http://jmobilecore.sourceforge.net/

http://www.gnu.org/licenses/licenses.es.html

http://java.sun.com/products/jdk/awt/

http://yura.net/projects/swing-me

http://java.sun.com/javase/6/docs/technotes/guides/swing/

http://code.google.com/p/j4me/

http://www.apache.org/licenses/LICENSE-2.0.html

http://www.java4ever.com/index.php?section=j2me&project=apime&menu=main&lang=_en

http://www.java4ever.com/index.php?section=j2me&project=apime&menu=main&lang=_en

http://sourceforge.net/projects/fire-j2me/

http://j2me-mwt.sourceforge.net/

http://www.esoco.net/content/view/7/1/

164 BIBLIOGRAFÍA

[15] Synclast:http://www.synclast.com/index.jsp

[16] Kuix:http://www.kalmeo.org/projects/kuix

[17] Kuix Subversion:http://kuix.googlecode.com/svn

[18] Subversion:http://subversion.tigris.org/

[19] LWUIT:https://lwuit.dev.java.net/

[20] LWUIT Subversion:https://lwuit.dev.java.net/svn/lwuit/trunk

[21] J2ME Polish:http://www.j2mepolish.org/cms/

[22] Evaluation: GUI libraries for J2ME. Andreas Bossard, Febrero del 2008:http://newsofthefuture.net/index.php?/archives/33-Evaluation-GUI-libraries-for-J2ME.

html

[23] Java ME Open Source Software. Wendong Li:http://j2me.ngphone.com/opensource/ui.htm

[24] OpenSource Software For Mobile Phones: UI:http://opensource.ngphone.com/tag/ui/

[25] LightWeight UI Toolkit Developer's Guide. Sun Microsystems, Inc. Julio 2008.

http://www.synclast.com/index.jsp

http://www.kalmeo.org/projects/kuix

http://kuix.googlecode.com/svn

http://subversion.tigris.org/

https://lwuit.dev.java.net/

https://lwuit.dev.java.net/svn/lwuit/trunk

http://www.j2mepolish.org/cms/

http://newsofthefuture.net/index.php?/archives/33-Evaluation-GUI-libraries-for-J2ME.html

http://newsofthefuture.net/index.php?/archives/33-Evaluation-GUI-libraries-for-J2ME.html

http://j2me.ngphone.com/opensource/ui.htm

http://opensource.ngphone.com/tag/ui/

Parte III - bibing.us.esbibing.us.es/proyectos/abreproy/11809/fichero/PARTE_3.pdf · En su modelo,...

Documents

Transcript of Parte III - bibing.us.esbibing.us.es/proyectos/abreproy/11809/fichero/PARTE_3.pdf · En su modelo,...