AO DEL BUEN SERVICIO AL CIUDADANO

Universidad Nacional de Trujillo

TEMA:
Patrones de Diseo para J2ME y Optimizacin de cdigo.

CURSO:
Tecnologa de la Programacin II
DOCENTE:
Mg. Vidal Melgarejo, Zoraida Janet
CICLO:
V

ESTUDIANTES:
ASMAT NUNJA, Junior Alexander
GUZMAN CARRANZA, John David
SANCHEZ VALVERDE, Cristian Humberto
VASQUEZ CRUZATE, David Felipe
PASTOR URQUIAGA, Cristian

ESCUELA:
Ingeniera de Sistemas
 INDICE
Descripcin de patrones de diseo para
J2ME..1
1. Patrn de generacin de men en
cascada...1
o 1.1. Modelo.
3
o 1.2.
Controlador.
3
o 1.3.
Vista3
2. Patrn para la generacin de
dilogos......4
3. Patrn de la
paginacin....7
4. Patrn para la creacin de
aplicaciones portables...9
5. Buenas prcticas y recomendaciones
de uso..........12
6 Optimizacin de
cdigo....13
6.1. Optimizacin para la
mantenibilidad...13
6.2. Optimizacin del
tamao..13
6.3. Optimizacin de la
velocidad14
Bibliografa
..15
Patrones de Diseo para J2ME
Optimizacin de Cdigo
J2ME es el acrnimo de Java 2 Micro Edition. J2ME es la versin
de Java orientada a dispositivos mviles. Debido a que los
dispositivos mviles tienen una potencia de clculo baja e interfaces
de usuario pobres, es necesaria una versin especfica de Java,
destinada a estos dispositivos, ya que el resto de versiones de
Java, J2SE O J2EE, no encajan dentro de este esquema. J2ME es
por tanto, una versin reducida de J2SE.
En el desarrollo de aplicaciones para J2ME, hay que tener en
cuenta las restricciones del terminal y del propio lenguaje. Si
buscamos que nuestras aplicaciones utilicen al mximo las
capacidades del dispositivo en concreto en el que se ejecuten,
tendremos que tener en cuenta las caractersticas de cada uno de
estos dispositivos. Esto obliga a hacer una versin de la aplicacin
para cada terminal o grupo de terminales con caractersticas
similares.
Sin embargo, las modificaciones entre las distintas versiones son
mnimas. Por lo tanto, tendremos que tener cuidado al disear
nuestras aplicaciones, para que el esfuerzo de adaptacin a los
distintos terminales sea el mnimo.
Debido a lo mencionado anteriormente, usamos patrones, que
podemos definir como una solucin con nombre que se puede
aplicar en nuevos contextos, con consejos acerca de cmo aplicarlo
en nuevas situaciones.

1. Patrn de generacin de men en cascada

Este patrn es til en la realizacin de los procesos de

navegacin por las aplicaciones. Los mens en cascada
organizan las distintas funcionalidades del sistema dentro de una
arquitectura de varios niveles. Dentro de esta organizacin, cada
elemento de un men puede ser el enlace a otro men o el
acceso a una funcionalidad de los sistemas.

1
Este tipo de interfaz de
usuario es comn dentro
de los entornos WAP
(Wireless Application
Protocol). Si usamos
elementos de interfaz de
usuario de alto nivel,
podremos implementar
fcilmente estos mens a
travs de elementos List.
Cada objeto de este tipo
List contendr todas las
opciones disponibles en un
men y, cuando un
elemento de la lista sea
seleccionado, el sistema
presentara la lista de sub opciones correspondiente o ejecutara
la accin correspondiente.

Cuando el nmero de listas o pantallas es muy grande, la gestin

de comandos empieza a ser un poco complicada si cada objeto
de tipo List gestiona sus propios comandos. Para solucionar esto
podemos usar un patrn MVC.

MVC (Modelo-Vista-
Controlador) es un patrn de
arquitectura de software, que
separa los datos y la lgica del
negocio de una aplicacin de
la interfaz de usuario y el
modulo encargado de
gestionar los eventos y las
comunicaciones. Este patrn de arquitectura de software se basa
en las ideas de reutilizacin de cdigo y la separacin de
conceptos, caractersticas que buscan facilitar la tarea de
desarrollo de aplicaciones y su posterior mantenimiento.

2
1.1. Modelo
Es la representacin de la informacin con la cual el sistema
opera, por lo tanto gestiona todos los accesos a dicha
informacin, tanto consultas como actualizaciones.

El modelo se encarga de lo siguiente:

Acceder a la capa de almacenamiento de datos.
Define las reglas de negocio (la funcionalidad del
sistema).
Lleva un registro de las vistas y controladores del
sistema.
Si estamos ante un modelo activo, notificara a las vistas
los cambios que en los datos pueda producir un agente
externo.

1.2. Controlador
Responde a eventos e invoca peticiones al modelo cuando
se hace alguna solicitud sobre la informacin.

El controlador se encarga de lo siguiente:

Recibir los eventos de entrada
Contener reglas de gestin de eventos, del tipo Si
evento A, entonces accin B.

1.3. Vista
Presenta el modelo en un formato adecuado para interactuar
por tanto requiere de dicho modelo la informacin que debe
representar como salida.

La vista se encarga de lo siguiente:

Recibir los datos del modelo y los muestra al usuario.
Tener un registro de su controlador asociado
Puede dar el servicio de actualizacin, para que sea
invocado por el controlador o por el modelo.

El flujo de control que sigue la interaccin de los componentes es

la siguiente:
a. El usuario interacta con la interfaz de usuario.

3
 b. El controlador recibe la notificacin de la accin solicitada
por el usuario.
c. El controlador accede al modelo, actualizndolo, posiblemente
modificndolo de forma adecuada a la accin solicitada por el
usuario.
d. El controlador delega a los objetos de la vista la tarea de
desplegar la interfaz de usuario. La vista obtiene sus datos del
modelo para generar la interfaz de usuario apropiada para el
usuario donde se reflejan los cambios en el modelo.
e. La interfaz de usuario espera nuevas interacciones del
usuario, comenzando el ciclo nuevamente.

2. Patrn para la generacin de dilogos

Muchas aplicaciones usan agentes de ayuda (wizards) para guiar
al usuario a travs de un determinado proceso, como puede ser
un proceso de instalacin.
Los Wizards se utilizan para realizar tareas de mltiples pasos.
Los Wizards suelen incluir estos tipos de pginas:

Pginas de seleccin, se utilizan para recopilar informacin y

permitir a los usuarios a tomar decisiones.

La pgina de confirmacin, se utiliza para realizar una accin

que no se puede deshacer haciendo clic en Atrs o Cancelar.

La pgina Progreso, se utiliza para mostrar el progreso de una

operacin larga.

Todas las pginas de los Wizards tienen estos componentes:

Una barra de ttulo para identificar el nombre del asistente,

con un botn Atrs en la esquina superior izquierda, y un
botn Cerrar con la opcin Minimizar / maximizar y restaurar
los botones. Tenga en cuenta que la barra de ttulo tambin
incluye un icono para identificar en la barra de tareas.

Una instruccin principal para explicar el objetivo del usuario

con la pgina.

Un rea de contenido con el texto opcional y posiblemente

otros controles.

4
 Un rea de comandos con al menos un botn se
comprometen a comprometerse con la tarea o proceder al
siguiente paso.

Aunque un Wizard tiene varios pasos, estos pasos deben sumar

todos a una sola tarea, desde el punto de vista del usuario. Este
es el principio fundamental de diseo de un asistente. As, en
este artculo, una tarea es la funcin bsica de un asistente (por
ejemplo, la tarea de un asistente de configuracin es instalar un
programa). Sub-tareas son aspectos de la tarea ms grande (por
ejemplo, un sub-tarea de un asistente de configuracin puede ser
para configurar el programa para ser instalado). Finalmente,
cada pgina del asistente se considera un paso en un sub-tarea
o una tarea determinada (por ejemplo, puede haber dos o tres
pasos implicados en la configuracin del programa).

Normalmente, en este tipo de interaccin con el usuario, se le

presentan una serie de pantallas en las que ste debe
proporcionar cierta informacin y se le permite pasar a la
siguiente pantalla y volver a la anterior. Este modo de interaccin
con el usuario puede ser una buena forma de evitar los
formularios demasiados largos (como los de muchas pginas
web), ya que las limitaciones de pantalla de los terminales hacen
del uso de los formularios extensos una mala prctica desde el
punto de vista de la usabilidad.

La solucin propuesta en el prrafo anterior es buena, por lo

tanto, merece la pena realizar un buen diseo software para
permitir al desarrollador el crear este tipo de secuencias de
pantallas de forma sencilla y flexible. Si implementamos el patrn
conocido como Mediador (Mediator), tendremos una forma
elegante y limpia de desarrollar este tipo de soluciones.

Un Mediator es un patrn de diseo que define un objeto que

hace de procesador central, coordinando las relaciones entre sus
asociados o participantes. Permite la interaccin de varios
objetos, sin generar acoples fuertes en esas relaciones. Todos
los objetos se comunican con un mediador y es ste quin
realiza la comunicacin con el resto. Cuando muchos objetos
interactan con otros objetos, se puede formar una estructura
muy compleja, con muchas conexiones entre distintos objetos.
En un caso extremo cada objeto puede conocer a todos los

5
dems objetos. Para evitar esto, el patrn Mediator, encapsula el
comportamiento de todo un conjunto de objetos en un solo
objeto.
Usar el patrn Mediator cuando:
- Un conjunto grande de objetos se comunica de una
forma bien definida, pero compleja.
- Reutilizar un objeto se hace difcil porque se relaciona
con muchos objetos.
- Las clases son difciles de reutilizar porque su funcin
bsica esta entrelazada con relaciones de dependencia.

Como conclusin podemos afirmar que este patrn debe ser

utilizado en casos donde convenga utilizar un procesador central,
en vez de que cada objeto tenga que conocer la implementacin
de otro. Imaginemos un aeropuerto: que pasara si no tuviese
una torre de control y todos los aviones que deban
aterrizar/despegar se tienen que poner todos de acuerdo para
hacerlo. Adems cada avin debe conocer detalles de otros
aviones (velocidad de despegue, nafta que le queda a cada uno
que quiera aterrizar, etc).

Para evitar esto se utiliza una torre de control que sincroniza el

funcionamiento de un aeropuerto. Esta torre de control se puede
ver como un mediador entre aviones.

Diagrama UML

Mediator: define una interface para comunicarse con los objetos

colegas.

6
 MediatorConcreto: implementa la interface y define como los
colegas se comunican entre ellos. Adems los conoce y
mantiene, con lo cual hace de procesador central de todos ellos.
Colleague: define el comportamiento que debe implementar
cada colega para poder comunicarse el mediador de una manera
estandarizada para todos.
ColleagueConcreto: cada colega conoce su mediador, y lo usa
para comunicarse con otros colegas.
Los colegas envan y reciben requerimientos de un objeto
mediador. El mediador gestiona cada mensaje y se lo comunica
a otro colega si fuese necesario.

3. Patrn de la paginacin
Este patrn nos vuelve a ayudar en la creacin de interfaces de
usuario mucho ms eficientes en cuanto a la usabilidad. Las
limitaciones de pantalla, de las que ya hemos hablado
anteriormente, hacen que el proceso de paginacin de las
interfaces (como las listas) sea muy tedioso para el usuario.

El uso de la paginacin en las aplicaciones, en las que se debe

presentar una lista de elementos larga, es una buena poltica de
usabilidad ya que requieren menos clicks por parte del usuario
que la presentacin de todos los elementos en una nica
pantalla. La paginacin tambin es ms eficiente desde el punto
de vista del uso de los recursos, como la memoria. El patrn de
paginacin nos permite automatizar en cierta medida el proceso
de paginado.

Los dispositivos mviles obviamente tienen una pantalla muy

limitada de bienes races; Por lo general tienen menos de 10
lneas de texto. En muchas aplicaciones mviles, la paginacin
es un proceso horrible. Durante la paginacin, grandes pginas
de contenido se dividen en varias pginas ms pequeas; Cada
uno contiene un subconjunto del contenido completo. Los
usuarios ven el contenido completo paginando a travs del
subconjunto usando un comando Ms o Siguiente.

7
En un ejemplo de bsqueda de
restaurantes, una bsqueda amplia
puede resultar en 200 coincidencias.
Esto puede dividirse en 10 pginas, cada
pgina contiene 20 coincidencias en la
lista. Las aplicaciones con paginacin
son ms fciles de usar que las que no
tienen porque requiere menos
pulsaciones de teclado para alcanzar el
elemento de destino. En algunos dispositivos, la paginacin
tambin es necesaria por razones de rendimiento. He visto a los
desarrolladores poner 1.000 artculos en una sola lista de MIDP,
y el telfono del blanco consecuentemente no puede responder a
una sola peticin. Se necesita una gran cantidad de memoria y
poder de procesamiento para mostrar 1.000 cuerdas en un
telfono mvil.

El patrn Paginacin proporciona un componente que automatiza

el proceso de paginacin. Este patrn tambin crea una clara
separacin entre el modelo de datos y el componente de vista. El
modelo de datos en este caso es el conjunto de datos completo
(por ejemplo, las 200 coincidencias de bsqueda). El modelo de
datos no necesita saber cmo se rompen los datos para
ajustarse a la pantalla. El componente de vista crea varias
pginas de contenido del conjunto de datos completo. Esto es
similar a una interfaz grfica de usuario (GUI) toolkit (vista) que
proporciona automticamente una barra de desplazamiento para
desplazar una imagen grande (los datos) en una aplicacin de
escritorio.

El patrn de paginacin es un patrn especfico del espectador

que puede implementarse completamente en una clase,
PagableList. PagableList es una subclase de List MIDP. Su
aplicacin puede tratar esto como una clase de List normal y
realizar operaciones de List habituales en l. Puede agregar
elementos y comandos y registrar oyentes de comandos. Pero
no es una List ordinaria en el interior.

PagableList es un proxy de List original porque anula algunos

de los mtodos. Internamente, contiene todo el conjunto de datos
y administra una subList de la misma. Mantiene un cursor que
apunta al ndice de subList actualmente visualizado. Registra

8
dos comandos integrados: los comandos More y Previous.
Cuando los usuarios pulsan el comando Ms, PagableList
avanza automticamente al siguiente conjunto de subList y los
muestra en la pantalla. De forma similar, cuando los usuarios
pulsan el comando Anterior, PagableList devuelve el cursor al
conjunto de datos anterior y los coloca en la pantalla. Mediante la
gestin de un cursor interno, los usuarios pueden desplazarse
rpidamente a travs de cada subconjunto de datos.

PagableList es un componente listo para usar. No se requiere

ningn trabajo adicional para habilitar la paginacin para su
aplicacin. Simplemente cree una instancia de PagableList en
lugar de una de List y agregue datos a ella mediante el mtodo
append(). Puesto que PagableList es una subclase List,
soporta todo el comportamiento List, y puede emitir su tipo en
List en toda la aplicacin. Este fragmento de cdigo muestra
cmo usar PagableList:

PagableList pagablelist = new PagableList ("Paging",

List.IMPLICIT);
// 'this' refer to the current MIDlet
Display.getDisplay(this).setCurrent(pagablelist);
for (int i=0; i< 100; i++)
{
pagablelist.append(Item #"+i, null );

Mostrando uso
PagableList implementa un patrn de proxy. Al encapsular List
de PagableList
original desde el exterior, PagableList pone funcionalidad
adicional en la parte superior de List. El patrn de proxy original
sugiere la encapsulacin mediante el uso de un marcador de
posicin para controlar el acceso al tema. Lo modifico para incluir
la encapsulacin sub clasificando y reemplazando la interfaz de
List. Este enfoque me permite preservar la interfaz de List y la
jerarqua de tipos, facilitando el uso y la reduccin de la
sobrecarga de este patrn. Pequeas optimizaciones como esta
pueden mejorar en gran medida el uso de patrones de diseo en
entornos con restricciones J2ME.

9
4. Patrn para la creacin de aplicaciones portables
Hoy por hoy, las diferencias entre los distintos dispositivos que
disponen de J2ME (incluso dentro de un mismo perfil) son muy
grandes, en cuanto a la interfaz de usuario. Es decir, tendremos
terminales con pantalla pequeas con dos colores y tendremos
terminales con pantallas grandes y gran cantidad de colores. De
forma similar, en algunos terminales tendremos un pequeo
joystick que el usuario utilizar para interaccionar con el sistema
y en otros casos tendremos simplemente dos teclas.

Por otra parte, si

queremos que
nuestras
aplicaciones sean
totalmente
profesionales y
aprovechen al
mximo las normas
de cada terminal,
tendremos que
personalizar las interfaces de usuario para cada terminal.
El avance de la tecnologa ha logrado que estos dispositivos
incorporen funcionalidades tales como reproduccin de msica,
correo electrnico, SMS,
fotografa, video digital, video
llamada, navegacin por
Internet, GPS y televisin
digital, adems de poseer
hardware capaz de ejecutar
potentes aplicaciones como
video juegos, juegos puzles,
paseos y galeras virtuales.

Una de las virtudes de J2ME es

que nos permite desarrollar aplicaciones que cubran un amplio
espectro de terminales. Para hacer esto de forma automtica, y
que las aplicaciones corran sin
problemas en todos los terminales,
tendremos que utilizar los componentes
de interfaz de usuario a alto nivel que
nos proporciona de forma nativa J2ME.
Esto parece una buena solucin pero, a

10
cambio, el resultado de las mismas no suele ser muy vistoso y,
por supuesto, no aprovechamos al mximo las capacidades de
los terminales ligeramente avanzados.
Otra cuestin que nos obliga a realizar interfaces de usuario
adaptadas al terminal, es la necesidad de hacer los mens y
dems elementos de nuestra aplicacin lo ms parecidos posible
a los mens o dems elementos
nativos del terminal. De esta
forma, la usabilidad de la
aplicacin ser mucho mayor
debido a que el usuario
interacta con un entorno que
ya conoce. Adems, de esta
forma, el usuario nota menos la
diferencia entre aplicaciones
nativas del terminal y
aplicaciones J2ME
descargadas, lo que reduce en gran medida la posible reticencia
del usuario al uso de las aplicaciones externas al terminal.

Bien, para conseguir soluciones con este tipo de caractersticas,

tendremos que disear nuestra aplicacin con sumo cuidado, de
tal forma que el esfuerzo necesario para portar la aplicacin
entre terminales sea mnimo. Es decir, por una parte tendremos
que conseguir que los distintos terminales compartan la mayor
parte de cdigo y que la aplicacin est bien diseada, para que
el reparto de responsabilidades sea correcto y, por lo tanto, la
adaptacin al terminal requiera la menor cantidad de cdigo
posible.
Un patrn de diseo de software conocido para soluciones de
este tipo, son los denominados Factory. Es decir, tendremos lo
que podemos denominar una fbrica o creador (Factory) de
interfaces de usuario, de tal forma, que el creador genere una
interfaz de usuario totalmente adaptada al terminal o familia de
terminales.

11
5. Buenas prcticas y recomendaciones de uso
Una buena forma de empezar a disear aplicaciones con las
caractersticas anteriormente descritas, es la separacin entre
los modelos de datos o la lgica de aplicacin y la interfaz de
usuario, de forma similar a lo expuesto en alguno de los patrones
anteriores.
Si optamos por esta separacin de responsabilidades, podremos
compartir totalmente el modelo de datos entre todas las
versiones de la aplicacin y slo tendremos que adaptar la
interfaz de usuario. Una vez conseguido esto, lo nico que
tendremos que hacer ser mejorar el diseo para que la
generacin de interfaces de usuario sea lo ms sencilla y directa
posible. Un patrn de diseo de software conocido para
soluciones de este tipo, son los denominados Factora. Es decir,
tendremos lo que podemos denominar una fbrica o creador
(Factory) de interfaces de usuario, de tal forma, que el creador
genere una interfaz de usuario totalmente adaptada al terminal o
familia de terminales.
Realizar un buen diseo software para permitir al desarrollador el
crear este tipo de secuencias de pantallas de forma sencilla y
flexible. Si implementamos el patrn conocido
como Mediador (Mediator), tendremos una forma elegante y
limpia de desarrollar este tipo de soluciones.

Por qu usar J2ME? Algunas ventajas reportadas:

-Es un estndar actual de la industria respaldado por Sun
Microsystems.
-Puede correr en el escritorio y en dispositivos mviles.
-Continas versiones de actualizacin a travs de un comit JCP
(Java Community Process).

12
 -APIs de desarrollo de terceros para nuevas caractersticas en
los equipos de nueva generacin.
Sin embargo, J2ME tambin puede tener algunas desventajas,
entre las cuales estn:
-Es un lenguaje interpretado, una aplicacin Midlet mal planeada
puede ser lenta.
-La memoria libre de cada telfono y el tamao mximo del
archivo JAR/JAD.

6. Optimizacin de cdigo
La mayora de los telfonos mviles tienes importantes
restricciones en cuanto a memoria y capacidad de proceso. Esto
nos obliga a optimizar en la medida de lo posible los MIDlets.
Hay tres importantes facetas en las que optimizar un MIDlet,
entre otras:
Mantenibilidad
Tamao
Velocidad
Lo mejor que se puede hacer de cara a la optimizacin, es hacer
los MIDlets lo ms simple posible.
Es decir, debemos hacer los interfaces de usuario sencillos, para
reducir el nmero de componentes y comandos.
6.1. Optimizacin para la mantenibilidad
Esta optimizacin har que el cdigo sea manejable en el
futuro y ms sencillo de comprender. Depende
bsicamente de la estructura y la organizacin del cdigo.

Esta optimizacin, est reida en cierta forma con los otros

dos tipos de optimizacin. A pesar de que la optimizacin
orientada a la mantenibilidad es importante, la optimizacin
del tamao y la velocidad es an ms importante.
6.2. Optimizacin del tamao
Para optimizacin el tamao del MIDlet lo que debemos
hacer es que el tamao de las clases resultantes sea lo
ms pequeo posible.
La piedra angular de esta optimizacin es la reutilizacin
del cdigo, cuya base es la herencia.

13
 Otro punto a considerar son los recursos usados por el
MIDlets y los datos que gestiona.
Para reducir el uso de memoria, podemos usar alguna de
las siguientes tcnicas:
Evitar el uso de objetos siempre que sea posible
Cuando usamos objetos, debemos reciclarlos
siempre que sea posible
Limpiar los objetos explcitamente cuando
finalicemos de usarlos. El garbage collector de
J2ME no es del todo eficiente, ya que su prioridad es
muy baja.

6.3. Optimizacin de velocidad

La optimizacin de la velocidad de ejecucin del MIDlet es
la ms importante y es lo que debemos tener presente en
primer lugar.
Eliminacin de Evaluaciones innecesarias
El siguiente cdigo:

Eliminar sub expresiones comunes

El siguiente cdigo:

Aprovechar las variables locales

El siguiente cdigo:

14
 Expandir los bucles

El siguiente cdigo:

BIBLIOGRAFIA

http://www.juntadeandalucia.es/servicios/madeja/contenido/rec
urso/208

https://en.wikipedia.org/wiki/Wizard_(software)

https://es.wikipedia.org/wiki/Mediator_(patr%C3%B3n_de_dise
%C3%B1o)

15
 http://www.javaworld.com/article/2074754/mobile-java/mobile-
java-big-designs-for-small-devices.html

http://www.juntadeandalucia.es/servicios/madeja/contenido/rec
urso/208#Patron_para_la_creacion_de_aplicaciones_portable
s

https://sg.com.mx/revista/05/j2me-desarrollo-aplicaciones-
para-tel-fonos-celulares#.WTSZTpI1_IU

http://www.ajpdsoft.com/modules.php?
name=News&file=article&sid=437

PRIETO, Manuel. Desarrollo de juegos con J2ME. Mxico.

Editorial Alfaomega/RaMa. 2004. 352 p. ISBN: 978-84-7897-
634-8.

https://es.wikipedia.org/wiki/Modelo%E2%80%93vista
%E2%80%93controlador

https://si.ua.es/es/documentacion/asp-net-mvc-3/1-
dia/modelo-vista-controlador-mvc.html

16