UNIVERSIDAD NACIONAL DE TRUJILLO

FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA DE SISTEMAS

J2ME y Otras Tecnologías para el

Desarrollo de Aplicaciones Móviles
DOCENTE:
Vidal Melgarejo, Zoraida

INTEGRANTES:
Argomedo De La Cruz, Jhon
Reyes Julca, Christian Steven
Serin Nery, Elmer
Silva Guevara, Manuel
Zavaleta Cortez, Jeyson
CURSO:
Tecnología de la Programación II

CICLO: V
Trujillo, mayo de 2019
Contenido
I. Introducción ..............................................................................................................................1
II. ¿Qué es Java 2 ME? ..................................................................................................................2
III. Componentes ..........................................................................................................................3
IV. Máquinas virtuales ..................................................................................................................4
V. Configuraciones .......................................................................................................................5
CDC (Connected Device Configuration) ...................................................................................5
CLDC (Connected Limited Device Configuration) ....................................................................6
VI. Perfiles ....................................................................................................................................7
1. Foundation Profile: ..........................................................................................................7
2. Personal Profile:...............................................................................................................8
3. RMI Profile: ......................................................................................................................8
4. PDA Profile: ......................................................................................................................8
5. Mobile Informa ion Device Profile (MIDP): .....................................................................9
VII. MIDlet ....................................................................................................................................9
a. Componentes y contenedores .........................................................................................9
b. Ciclo de vida de un MIDlet ..............................................................................................10
c. Proceso de creación de un MIDlet ..................................................................................10
d. Principales métodos .......................................................................................................11
Método startApp() .............................................................................................................11
Método pauseApp() ...........................................................................................................11
Método destroyApp(boolean) ...........................................................................................12
Método notifyDestroyed() .................................................................................................12
Método notifyPaused()......................................................................................................12
Método resumeRequest() ..................................................................................................12
VIII. Conclusiones ...............................................................................................................13
Bibliografía .................................................................................................................................13
I. Introducción
Uno de los factores del éxito de Java como lenguaje de programación se debe a su
conocido lema “Write Once, run everyehere” (Escribe una vez, ejecuta en todos lados).
Esto, debido a que Java se desarrolló con el enfoque de ser un lenguaje “universal” que
se ejecuta indistintamente del hardware y del sistema operativo. Todo esto posible
gracias a la implementación de la Java Virtual Machine. Sin embargo, con el lanzamiento
de dispositivos móviles con sistemas operativos propios y recursos limitados, es que
surge la necesidad de utilizar un lenguaje más ligero y eficiente en el que se pueda
programar aplicaciones para estos.

Es por ello que en 1999 Sun Microsystems (luego adquirida por Oracle) lanza una nueva
versión de Java adaptada a estas necesidades. La J2ME o Java 2 Micro Edition es una
versión de Java más ligera que se enfoca en el desarrollo para dispositivos de pocos
recursos, esto es: teléfonos, tabletas, relojes, dispositivos inteligentes, etc.

Cabe resaltar que, debido al aumento en las capacidades de los teléfonos y tabletas
modernos, ya no es necesario el uso de J2ME en estos dispositivos y se usa la versión
standard, sin embargo, aún es utilizado en algunos dispositivos con menos recursos
como relojes y otros dispositivos inteligentes.

En el presente informe, se repasarán los conceptos más importantes de esta edición de

Java, además de dar un repaso por las clases, librerías y herramientas más importantes
y cómo estas se utilizan.

1
II. ¿Qué es Java 2 ME?
Antes de definir qué es J2ME, repasaremos las distintas versiones de Java y
estableceremos sus principales diferencias.

Java 2 Platform, Standard Edition (J2SE):

Esta edición de Java es la que en cierta forma recoge la iniciativa original del lenguaje
Java.

Esta versión de Java contiene el conjunto básico de herramientas usadas para

desarrollar Java Applets, así como las APIs orientadas a la programación de aplicaciones
de usuario final: Interfaz gráfica de usuario, multimedia, redes de comunicación, etc.

Java 2 Platform, Enterprise Edition (J2EE):

Esta versión está orientada al entorno empresarial. El software empresarial tiene unas
características propias marcadas: está pensado no para ser ejecutado en un equipo, sino
para ejecutarse sobre una red de ordenadores de manera distribuida y remota mediante
EJBs (Enterprise Java Beans). De hecho, el sistema se monta sobre varias unidades o
aplicaciones. En muchos casos, además, el software empresarial requiere que se sea
capaz de integrar datos provenientes de entornos heterogéneos. Esta edición está
orientada especialmente al desarrollo de servicios web, servicios de nombres,
persistencia de objetos, XML, autenticación, APIs para la gestión de transacciones, etc.
El cometido de esta especificación es ampliar la J2SE para dar soporte a los requisitos de
las aplicaciones de empresa.

Java 2 Platform, Micro Edition (J2ME):

Habiendo repasado los conceptos de las otras versiones de Java, ahora podemos definir
qué es y en qué está enfocada la J2ME.

La J2ME, está enfocada a la aplicación de la tecnología Java en dispositivos electrónicos

con capacidades computacionales y gráficas muy reducidas, tales como teléfonos
móviles, PDAs o electrodomésticos inteligentes. Esta edición tiene unos componentes
básicos que la diferencian de las otras versiones, como el uso de una máquina virtual
denominada KVM (Kilo Virtual Machine, debido a que requiere sólo unos pocos
Kilobytes de memoria para funcionar) en vez del uso de la JVM clásica, inclusión de un
pequeño y rápido recolector de basura y otras diferencias que ya iremos viendo más
adelante.

Para simplificar, J2ME es entonces una “versión reducida” de Java Standard Edition.

En la siguiente figura, se muestra gráficamente la diferencia entre las distintas versiones

de Java, así como una idea de los entornos en los que funcionan y los recursos que
requieren.

2
III. Componentes
Al ser una versión para pequeños dispositivos, J2ME está compuesto de distintos
componentes que pueden variar (principalmente las máquinas virtuales) de un
dispositivo a otro.

Los principales componentes son:

a. Las máquinas virtuales (mencionadas anteriormente) que difieren en los requisitos

dependiendo del hardware en el que se ejecutará la aplicación.
b. Configuraciones, que son un conjunto de clases básicas orientadas a conformar el
corazón de las implementaciones para dispositivos de características específicas.
Existen 2 configuraciones definidas en J2ME: Connected Limited Device
Configuration (CLDC) enfocada a dispositivos con restricciones de procesamiento y
memoria, y Connected Device Configuration (CDC) enfocada a dispositivos con más
recursos.
c. Perfiles, que son unas bibliotecas Java de clases específicas orientadas a
implementar funcionalidades de más alto nivel para familias específicas de
dispositivos.
d. Paquetes opcionales que se usan dependiendo de los requerimientos de la
aplicación que se implementará.

3
 La figura representa el entorno de ejecución de una aplicación J2ME que va desde una
capa de abstracción más alta (los perfiles) a una más baja (Sistema operativo).

A continuación, estudiaremos cada componente más detalladamente.

IV. Máquinas virtuales

Son las encargadas de interpretar y ejecutar el código intermedio de los programas de
Java pre-compilados (byte code). Para J2ME existen dos máquinas virtuales principales
dependiendo de los recursos del dispositivo. La elección de una máquina virtual u otra
depende de la capa de configuración (CLDC o CDC).

KVM (Kilobyte virtual machine): Es la máquina virtual más pequeña desarrollada por
Sun, utilizada por dispositivos con configuración CLDC. Su nombre hace referencia al
poco espacio de memoria requerido por esta para ejecutarse (entre 40 y 80 Kb).

Las principales limitaciones de la KVM son las siguientes:

a. No tiene soporte para tipos de dato double ni float

b. No existen cargadores de clase definidos por el usuario, solo los predefinidos.
c. No existe la finalización (el método Object.finalize() ).
d. Limitada capacidad para el manejo de excepciones debido a que el manejo de
éstas depende en gran parte de las APIs de cada dispositivo por lo que son éstos
los que controlan la mayoría de las excepciones.
e. La verificación de clases en 2 pasos (utilizada también en dispositivos CDC). Que
reduce la comprobación de clases de la J2SE como se muestra en el siguiente
esquema:

4
 La KVM puede ser compilada y probada en 3 plataformas distintas: Solaris Operating
Environment, Windows 3, PalmOs.

CVM (Compact virtual machine): Ha sido tomada como Máquina Virtual Java de
referencia para la configuración CDC y soporta las mismas características que la
Máquina Virtual de J2SE. Está orientada a dispositivos electrónicos con procesadores de
32 bits de gama alta y en torno a 2Mb o más de memoria RAM. Las características que
presenta esta Máquina Virtual son:

A. Sistema de memoria avanzado.

B. Tiempo de espera bajo para el recolector de basura.
C. Separación completa de la VM del sistema de memoria.
D. Recolector de basura modularizado.
E. Soporte nativo de hilos.
F. Baja ocupación en memoria de las clases.
G. Proporciona soporte e interfaces para servicios en Sistemas Operativos de Tiempo
Real.
H. Soporte para todas las características de Java2 v1.3 y librerías de seguridad,
referencias débiles, Interfaz Nativa de Java (JNI), invocación remota de métodos
(RMI), Interfaz de depuración de la Máquina Virtual (JVMDI).

V. Configuraciones
Una configuración es el conjunto mínimo de APIs Java que permiten desarrollar
aplicaciones para un grupo de dispositivos. Estas APIs describen las características
básicas, comunes a todos los dispositivos como: Características soportadas del lenguaje
de programación Java y por la Máquina Virtual Java, bibliotecas básicas de Java y otras
APIs soportadas.

Como ya hemos visto con anterioridad, existen dos configuraciones en J2ME: CLDC,
orientada a dispositivos con limitaciones computacionales y de memoria y CDC,
orientada a dispositivos con no tantas limitaciones.

CDC (Connected Device Configuration)

La CDC está orientada a dispositivos con cierta capacidad (superior a 2Mb)
computacional y de memoria. Por ejemplo, decodificadores de televisión digital,
televisores con internet, algunos electrodomésticos y sistemas de navegación en
automóviles. CDC usa una Máquina Virtual Java similar en sus características a una de
J2SE, pero con limitaciones en el apartado gráfico y de memoria del dispositivo.

La CDC está enfocada a dispositivos con las siguientes capacidades:

a. Procesador de 32 bits.
b. Disponer de 2 Mb o más de memoria total (incluyendo memoria RAM y ROM).
c. Poseer la funcionalidad completa de la Máquina Virtual Java2.
d. Conectividad de red.

La CDC está basada en J2SE e incluye varios paquetes Java de la edición estándar. Las
peculiaridades de la CDC están contenidas principalmente en el paquete

5
javax.microedition.io, que incluye soporte para comunicaciones http y basadas en
datagramas.

La siguiente tabla nos muestra las librerías incluídas en CDC

Nombre de Paquete CDC Descripción
java.io Clases e interfaces estándar de E/S.
java.lang Clases básicas del lenguaje.
java.lang.ref Clases de referencia.
java.lang.reflect Clases e interfaces de reflection.
java.math java.math Paquete de matemáticas.
java.net Clases e interfaces de red.
java.security Clases e interfaces de seguridad
java.security.cert Clases de certificados de seguridad.
java.text Paquete de texto.
java.util Clases de utilidades estándar.
java.util.jar Clases y utilidades para archivos JAR.
java.util.zip Clases y utilidades para archivos ZIP y comprimidos.
javax.microedition.io Clases e interfaces para conexión genérica CDC.

CLDC (Connected Limited Device Configuration)

La CLDC está orientada a dispositivos dotados de conexión y con limitaciones en cuanto

a capacidad gráfica, cómputo y memoria. Un ejemplo de estos dispositivos es: teléfonos
móviles de generación anterior, PDAs, organizadores personales, etc. (Como nos
podremos dar cuenta, muchos de ellos ya no se utilizan en la actualidad).

Ya hemos dicho que CLDC está orientado a dispositivos con ciertas restricciones. Algunas
de estas restricciones vienen dadas por el uso de la KVM, necesaria al trabajar con la
CLDC debido a su pequeño tamaño.

Los dispositivos que usan CLDC deben cumplir los siguientes requisitos:

a. Disponer entre 160 Kb y 512 Kb de memoria total disponible.

b. Como mínimo se debe disponer de 128 Kb de memoria no volátil para la Máquina
Virtual Java y las bibliotecas CLDC, y 32 Kb de memoria volátil para la Máquina
Virtual en tiempo de ejecución.
c. Procesador de 16 o 32 bits con al menos 25 Mhz de velocidad.
d. Ofrecer bajo consumo, debido a que éstos dispositivos trabajan con suministro de
energía limitado, normalmente baterías.
e. Tener conexión a algún tipo de red, normalmente sin cable, con conexión
intermitente y ancho de banda limitado (unos 9600 bps).

Además, la CLDC aporta las siguientes funcionalidades a los dispositivos:

a. Un subconjunto del lenguaje Java y todas las restricciones de su Máquina Virtual

(KVM).
b. Un subconjunto de las bibliotecas Java del núcleo.
c. Soporte para E/S básica.
d. Soporte para acceso a redes.
e. Seguridad (modelo de seguridad sandbox).

6
 La siguiente tabla nos muestra las librerías incluídas en CLDC

Nombre de Paquete CLDC Descripción

java.io Clases y paquetes estándar de E/S. Subconjunto de J2SE.
java.lang Clases e interfaces de la Máquina Virtual. Subconj. de J2SE.
java.util Clases, interfaces y utilidades estándar. Subconj. de J2SE.
javax.microedition.io Clases e interfaces de conexión genérica CLDC

Hay que ter en cuenta que una determinada Configuración no se encarga del
mantenimiento del ciclo de vida de la aplicación, interfaces de usuario o manejo de
eventos, sino que estas responsabilidades caen en manos de los perfiles.

VI. Perfiles
El perfil es el que define las APIs que controlan el ciclo de vida de la aplicación, interfaz
de usuario, etc. Más concretamente, un perfil es un conjunto de APIs orientado a un
ámbito de aplicación determinado. Los perfiles identifican un grupo de dispositivos por
la funcionalidad que proporcionan (electrodomésticos, teléfonos móviles, etc.) y el tipo
de aplicaciones que se ejecutarán en ellos. Las librerías de la interfaz gráfica son un
componente muy importante en la definición de un perfil. Aquí nos podemos encontrar
grandes diferencias entre interfaces, desde el menú textual de los teléfonos móviles
hasta los táctiles de los PDAs.

En la imagen anterior se muestran los distintos perfiles que existen para cada
configuración.

A continuación, vamos a ver con detenimiento cada uno de estos perfiles:

1. Foundation Profile:
Este perfil define una serie de APIs sobre la CDC orientadas a dispositivos que carecen
de interfaz gráfica como, por ejemplo, decodificadores de televisión digital. Este perfil
incluye gran parte de los paquetes de la J2SE, pero excluye totalmente los paquetes
“java.awt” Abstract Windows Toolkit (AWT) y “java.swing” que conforman la interfaz
gráfica de usuario (GUI) de J2SE. Si una aplicación requiriera una GUI, entonces sería
necesario un perfil adicional. Los paquetes que forman parte del Foundation Profile se
muestran en la siguiente tabla.

7
2. Personal Profile:
El Personal Profile es un subconjunto de la plataforma J2SE, y proporciona un entorno
con un completo soporte gráfico AWT. El objetivo es el de dotar a la configuración CDC
de una interfaz gráfica completa, con capacidades web y soporte de applets Java. Este
perfil requiere una implementación del Foundation Profile. La siguiente tabla nos
muestra los paquetes que conforman el Personal Profile.

3. RMI Profile:
Este perfil requiere una implementación del Foundation Profile. El perfil RMI soporta un
subconjunto de las APIs JSE RMI, aunque algunas características de estas APIs se han
eliminado del perfil RMI debido a las limitaciones de cómputo y memoria de los
dispositivos.
Las siguientes propiedades se han eliminado del J2SE RMI:
a. Java.rmi.server.disableHTTP.
b. Java.rmi.activation.port.
c. Java.rmi.loader.packagePrefix.
d. Java.rmi.registry.packagePrefix.
e. Java.rmi.server.packagePrefix.

4. PDA Profile:
El PDA Profile está construido sobre CLDC. Pretende abarcar PDAs de gama baja, tipo
Palm, con una pantalla y algún tipo de puntero (ratón o lápiz) y una resolución de al
menos 200x100 pixels con un factor 2:1.

8
 5. Mobile Informa ion Device Profile (MIDP):
Este perfil está construido sobre la configuración CLDC. Al igual que CLDC fue la primera
configuración definida para J2ME, MIDP fue el primer perfil definido para esta
plataforma. Este perfil está orientado para dispositivos con las siguientes características:
a. Reducida capacidad computacional y de memoria.
b. Conectividad limitada (en torno a 9600 bps).
c. Capacidad gráfica muy reducida (mínimo un display de 96x54 pixels monocromo).
d. Entrada de datos alfanumérica reducida.
e. 128 Kb de memoria no volátil para componentes MIDP.
f. 8 Kb de memoria no volátil para datos persistentes de aplicaciones.
g. 32 Kb de memoria volátil en tiempo de ejecución para la pila Java.

Los tipos de dispositivos que se adaptan a estas características son: teléfonos móviles,
buscapersonas (pagers) o PDAs de gama baja con conectividad. El perfil MIDP establece
las capacidades del dispositivo, por lo tanto, especifica las APIs relacionadas con:

a. La aplicación (semántica y control de la aplicación MIDP).

b. Interfaz de usuario.
c. Almacenamiento persistente.
d. Trabajo en red.
e. Temporizadores.

Las aplicaciones que realizamos utilizando MIDP reciben el nombre de MIDlets. Decimos
así que un MIDlet es una aplicación Java realizada con el perfil MIDP sobre la
configuración CLDC. Este es el punto de referencia para cualquier programador de J2ME.

VII. MIDlet
Como se vio anteriormente, un MIDlet es una aplicación desarrollada en J2ME y
construida sobre la configuración CLDC utilizando el perfil MIDP.

a. Componentes y contenedores

Los componentes son elementos que tienen una determinada interfaz, y los
contenedores son la infraestructura que da soporte a estos componentes.

De esta forma nosotros podemos deberemos definir sólo el componente, con

su correspondiente interfaz, y será el contenedor quien se encargue de
controlar su ciclo de vida (instanciarlo, ejecutarlo, destruirlo). Cuando
desarrollamos componentes, no deberemos crear el método main, ya que estos

9
 componentes no se ejecutan como una aplicación independiente (stand-alone),
sino que son ejecutados dentro de una aplicación ya existente, que será el
contenedor.

El contenedor que da soporte a los MIDlets recibe el nombre de Application

Management Software (AMS). El AMS además de controlar el ciclo de vida de la
ejecución MIDlets (inicio, pausa, destrucción), controlará el ciclo de vida de las
aplicaciones que se instalen en el móvil (instalación, actualización, ejecución,
desinstalación).

b. Ciclo de vida de un MIDlet

Durante su ciclo de vida un MIDlet atraviesa tres tipos de estados diferentes:

Estado Detenido (paused): El MIDlet se encuentra a mitad de una ejecución,

pero está pausado, estando presente en la memoria RAM. La ejecución podrá
reanudarse, pasando de nuevo al estado activo.

En este estado el midlet debe mantener los recursos mínimos posibles liberando
los demás para que sean utilizados por el dispositivo con la nueva aplicación
activa.

Ejemplo: Cuando entra una llamada al teléfono móvil durante la ejecución del
midlet.

Estado Activo (active): El MIDlet se está ejecutando actualmente. En ese

momento está utilizando los recursos necesarios para su funcionamiento.

Estado Destruido (destroyed): El MIDlet ha terminado su ejecución y ha

liberado todos los recursos, por lo que ya no se puede volver a estado activo. La
aplicación está cerrada, por lo que para volver a ponerla en marcha tendríamos
que volver a ejecutarla.

Será el AMS quién se encargue de controlar este ciclo de vida, es decir, quién
realice las transiciones de un estado a otro. Nosotros podremos saber cuándo
hemos entrado en cada uno de estos estados porque el AMS (Administration
Managament System) invocará al método correspondiente dentro de la clase
del MIDlet.

c. Proceso de creación de un MIDlet

• La clase principal necesita ser una subclase de

javax.microedition.midlet.MIDlet
• El MIDlet es empacado dentro de un archivo .jar
• El archivo .jar necesita pasa a ser pre verificado usando un pre verificador.
• En algunos casos, el archivo .jar necesita ser firmado digitalmente por un
proveedor de teléfonos móviles.
• Finalmente se genera un archivo descriptor con extensión .jad, que contiene
todos los recursos que se están utilizando para que la aplicación se ejecute.
10
d. Principales métodos
Anteriormente se vio los tres estados del ciclo de vida de un MIDlet. En esta
sección, veremos los principales métodos utilizados para establecer y verificar
estos estados.

Método startApp()

Es un método abstracto, debe ser definido por el MIDlet para reservar todos los
recursos y establecer los valores iniciales de los atributos que vaya a necesitar
en su estado activo.

Debe tenerse en cuenta que este método puede ejecutarse en varias ocasiones:
cuando se inicia por primera vez el MIDlet y cada vez que el MIDlet pase de
estado pausado a estado activo. Esto es particularmente importante al
momento de decidir donde realizar la creación de ciertos objetos (en este
método o en el constructor del MIDlet).

Como regla general, en el método startApp() se reservarán los recursos que son
liberados en el método pauseApp(). Debemos tener en cuenta que el
constructor MIDlet crea una instancia de la clase Display (pantalla del
dispositivo) solamente en el primer llamado al método startApp(). Pues en los
siguientes llamadas al método startApp() el objeto Display seguirá siendo el
mismo que el utilizado antes de la pausa.

Si ocurre un error que impida que el MIDlet empiece a ejecutarse deberemos

notificarlo. Podemos distinguir entre errores pasajeros o errores permanentes.
Los errores pasajeros impiden que el MIDlet se empiece a ejecutar ahora, pero
podría hacerlo más tarde. Los permanentes se dan cuando el MIDlet no podrá
ejecutarse nunca. En el caso de que el error sea pasajero, lo notificaremos
lanzando una excepción de tipo MIDletStateChangeException, de modo que el
MIDlet pasará a estado pausado, y se volverá intentar activar más tarde. Si por
el contrario el error es permanente, entonces deberemos destruir el MIDlet
llamando a notifyDestroyed() porque sabemos que nunca podrá ejecutarse
correctamente. Si se lanza una excepción de tipo RuntimeException dentro del
método startApp() tendremos el mismo efecto, se destruirá el MIDlet.

Método pauseApp()

Este método abstracto y deberá ser implementado por el MIDlet. Es llamado

cuando se va a detener temporalmente la ejecución y su función es la de
garantizar la conservación del estado del MIDlet y liberar la mayor cantidad de
recursos que no vayan a ser requeridos durante este estado de “hibernación”.

Durante el estado pausado el MIDlet no se encuentra formalmente activo, sin

embargo, está posibilitado para recibir mensajes de eventos asíncronos como
temporizadores o recepción de mensajes vía SMS.

11
Igual que en el caso anterior, si se produce una excepción de tipo
RuntimeException durante la ejecución de este método, el MIDlet se destruirá.

Método destroyApp(boolean)

Este método implementado por el MIDlet es invocado por el sistema operativo

o por la propia aplicación cuando esta ha de finalizar su ejecución. Su misión es
la de liberar todos los recursos que el MIDlet haya reservado durante su
ejecución para finalizar su ciclo de vida.

Este método recibe un argumento de tipo booleano que indica si la petición de

destrucción es incondicional (true) haciendo que se liberen todos los recursos
para terminar la aplicación o si, por el contrario, es opcional (false) permitiendo
que esta se obvie al lanzarse una excepción de clase
MIDletStateChangeException la cual, si es manejada adecuadamente por la
aplicación, permitirá que el MIDlet permanezca en estado activo rehusándose a
ser finalizado.

Método notifyDestroyed()

Utilizaremos este método cuando queramos finalizar la aplicación. Por ejemplo,

podemos ejecutar este método como respuesta a la pulsación del botón "Salir"
por parte del usuario. La llamada a este método notifica que el MIDlet ha sido
destruido, pero no invoca el método destroyApp para liberar los recursos, por
lo que tendremos que invocarlo nosotros manualmente antes de llamar a
notifyDestroyed.

Método notifyPaused()

Este método le informa a sistema operativo que el MIDlet desea pasar a estado
paused. Únicamente puede ser invocado cuando el MIDlet se encuentre en
estado active. Tiene la misma funcionabilidad de la invocación del método
pauseApp() por parte del dispositivo.

Método resumeRequest()

Este método le indica al dispositivo que un MIDlet actualmente en estado

paused está interesado en activarse. El dispositivo puede reanudar al MIDlet
invocando su método startApp(). Es funcionalmente antagónico al método
notifyPaused.

La invocación de este método acostumbra a ser provocada por una tarea que se
ejecuta en segundo plano, un temporizador o un evento de origen externo

12
VIII. Conclusiones
Respecto al desarrollo en J2ME, se logró entender la arquitectura de este tipo de
aplicaciones y como se logra reducir la versión estándar de Java a una versión más ligera
y mucho menos demandante. Además de como estas aplicaciones (MIDlet) manejan los
recursos limitados a través de estados y cuál es el ciclo de vida de estas.

Del presente informe también se puede inferir que J2ME fue una gran innovación y una
de las pioneras en el desarrollo para dispositivos móviles. Este era el lenguaje de
programación en el que se desarrollaban todo tipo de aplicaciones para teléfonos de la
época. Sin embargo, debido al avance tecnológico y las capacidades de los dispositivos
móviles, ha dejado de usarse masivamente. A pesar de ello, se pueden abstraer algunas
metodologías para desarrollos futuros de aplicaciones que puedan funcionar en gran
cantidad de dispositivos sin la necesidad de hardware potente.

IX. Bibliografía
AMS Introduction. (2012). Recuperado el 25 de Mayo de 2019, de Oracle Java ME
Embedded Application Management System API Guide:
https://docs.oracle.com/javame/config/cldc/rel/3.4/core/ams/html/ams/ams_f
actory_class.htm

Gálvez Rojas, S., & Ortega Díaz, L. (2003). Java a tope: J2ME (Java 2 Micro Edition). Madrid:
Universidad de Málaga.

Luna, J. M. (Septiembre de 2006). Origen y breve descripción de J2ME - Arquitectura, 2.0.

Recuperado el 28 de Mayo de 2019, de The Society for Imprecise Probability:
Theories and Applications: http://leo.ugr.es/J2ME/INTRO/intro_2b.htm

Oracle. (s.f.). ¿Cómo puedo obtener Java para dispositivos móviles? Recuperado el 29 de
Mayo de 2019, de Java:
https://www.java.com/es/download/faq/java_mobile.xml

Oracle. (2018). JAVA ME SDK. Recuperado el 28 de Mayo de 2019, de Oracle Technology

Network.

Universidad de Alicante. (2011). Introducción a Java con JavaME. Alicante: Universidad de

Alicante.

13