Aplicaciones MIDP

MIDP nos provee de API’s para poder crear una aplicación de dos formas distintas:

1. Interfaz de bajo nivel --> utiliza la pantalla entera dibujando pixe a pixel los elementos que van a formar la aplicación.Sus elementos y métodos derivaban de la clase Canvas.
2. Interfaz de alto nivel -->utiliza componentes definidos en MIDP y que cualquier dispositivo MIDP soporta:cajas de textos, grupos de opciones, etc siendo esta su mayor ventaja y su desventaja es que no son personalizable. Sus elementos y métodos derivaban de la clase Screen.

La característica más importante en un dispositivo móvil MIDP es su permanente posibilidad de conexión con el exterior, la cual permitirá establecer una conexión HTTP con un servidor J2EE (entre otras muchas).
Toda conexión en MIDP hereda de la interface Connection. Dicha interface representa la conexión más abstracta posible. Para obtener una instancia de ella o de cualquiera de sus hijas debe usarse alguno de los métodos open() de la clase factoría Connector.
Los tipos de conexión actualmente soportados por MIDP 2.0 son el HTTP, su versión segura HTTPS, las conexiones basadas en SOCKETS (de espera, en servidor, seguros, comunes), la realizada por medio de DATAGRAMAS y la comunicación con puertos serie COMM.


Una conexión HTTP siempre se encontrará en alguno de los tres estados siguientes: Establecimiento, Conectado o Cierre.
Podrán mejorarse las aplicaciones que requieran comunicación HTTP con múltiples consideraciones. Dos de ellas son: cuidar un redireccionamiento adecuado de la URL a buscar y otra, el uso de cookies utilizando el RMS del dispositivo para permitir que el servidor a conectar mantenga un seguimiento adecuado de la sesión.

API's de MIDP

Esta api esta formada por apis de la clase J2SE:

• Paquete java.util.

y otra propia:

• Paquete javax.microedition.
  

API's de CLDC

Parte de estas API's proviene del API de J2SE:

• Paquete java.util
• Paquete java.lang.
• Paquete java.io.

y otra propia:

• Generic Connection Framework --> da soporte para la creación de ficheros y para comunicaciones de red.

Pasos para desarrollar un MIDlet

Como son dispositivos de capacidades muy limitadas, los pasos aconsejados a seguir son:

1. Escribir el código fuente.
2. Compilación.
3. Preverificador de clases -->mira que las clases cumplan los requisitos necesarios, como no sobrepasar los límites de la pila de la Máquina virtual,uso correcto de las variables y se respeta la estructura de clases. Esta herramienta no la incorpora el KVM ya que pesa mucho y hay que hacerlo desde un entorno externo a ella.
4. Empaquetamiento (jar,jad).
   
5. Ejecución y depuración.
   

MIDlet

Al conjunto de aplicaciones que se basan en la configuración CLDC y perfil MIDP ,se les denomina MIDlet.

Las acciones que un dispositivo debe realizar antes de lanzar un MIDlet son:

• Localizar el MIDlet.
• Descargar el MIDlet.
• Almacenar el MIDlet.
• Gestionar el MIDlet.
• Localizar los archivos JAD que pueden venir incluidos en un MIDlet.
• Ejecutar los MIDlets descargados.
• Conectarse a un servidor de internet utilizando el protocolo http y descargar tanto el MIDlet como su JAD asociado.
• Proporcionar un nombre de usuario y contraseña cuando necesite conectarse a internet y la petición web lo solicite.
• Instalar y borrar los MIDlets descargados.

Para realizar estos pasos el dispositivo tiene un programa que se encarga de realizar estas acciones llamado AMS o Gestor de aplicaciones.

Estructura de J2ME

Está compuesto por varias partes:

• Perfil --> es un conjunto de API’s orientado a cubrir específicamente las necesidades de una familia de dispositivo.
• Configuración -->conjunto de APIs que va a soportar los dispositivos.Existen 2 configuraciones básicas, CDC y CLDC.
  
• Máquina Virtual --> Encargada de ejecutar el código, podemos utilizar una de estas dos JVM o KVM.Elegiremos una u otra dependiendo de las características del dispositivo que vamos a crear la aplicación.

Si elegimos la maquina virtual JVM, la configuración que le corresponde sería la CDC y si elegimos la KVM, entonces trabajaríamos con la CLDC y están destinada para dispositivos de pocos recursos.

Existen diferencias entre JVM y KVM haciendo que esta última no tenga características que incluye la primera.:

1. KVM no trabaja con tipos de datos float ni double.
2. No existe el main() sino el starApp().
3. No tienen recolector de basuras.
4. La verificación de código se hace fuera del dispositivo.
5. Elimina el JINI.
6. Elimina los threads.
7. No tiene método que finalice las clases.
8. Limitada capacidad para gestionar excepciones.
9. Incluye una biblioteca gráfica nueva para ser empleada en dispositivos de poca memoria y con un tipo de pantalla más pequeña.

También tenemos que saber que la configuración CDC esta basada en J2SE e incorpora muchas de sus clases y CLDC es un subconjunto de CDC.

Con respecto a los distintos perfiles que hay, ocurre lo mismo con la maquina virtual, si elegimos la configuración CDC, los perfiles que tenemos son:

• Foundation Profile
• Personal Profile
• RMI Profile

Y para la configuración CLDC tenemos:

• PDA Profile
• Mobile Information Device Profile (MIDP)--> es el perfil más utilizado.
  

J2ME

Es un lenguaje de programación y a su vez una plataforma donde se pueden ejecutar software creado en java.

Está orientado al desarrollo de aplicaciones para pequeños dispositivos electrónicos con recursos limitados como móviles, pdas,smartphone,etc...

El sitio oficial de J2ME se encuentra en http://java.sun.com/j2me/index.jsp

La serialización de objetos

Es un tipo de persistencia, esto consiste en la codificación de un objeto en cadenas de bytes y almacenar ese objeto o transmitirlo, para poder llevar acabo esta acción lo hacemos mediante la interfaz java.io.Serializable que no tiene métodos solo sirve para indicar que esa clase se puede serializar. Los objetos de clases que no implementan Serializable no pueden salvar o restaurar sus estados.
Toda clase que implemente esta interfaz puede transformar sus objetos a cadenas de bytes y viceversa.Para ello utilizamos las clases del paquete java.io writeObject y readObject.
Hay clases que no se pueden serializar porque sus datos están cambiando constantemente como java.io.FileInputStream y java.lang.Thread.Tenemos que tener cuidado a a hora de serializar un objeto, si este contiene una referencia a un elemento no-serializable,fallaría y se lanzaría la excepción NotSerializableException.

Cuando pasamos objetos Serializable de un lado a otro podemos tener el problema de que la versión de un lado tenga una versión más antigua que en el otro lado. Si sucede esto, la reconstrucción de la clase en el lado que recibe es imposible.Para evitar este problema se aconseja que la clase serializable tenga el atributo privado serialVersionUID. Así java es capaz de detectar rápidamente que las versiones de objeto_serializable.class en ambos lados son distintas o no.

Nota:Los objetos con las propiedades static y transient no se pueden serializar y la mayoría de las clases Java son serializable.

Stream

Cada vez que queramos enviar o traer información sea del tipo que sea (imagenes,caracteres,objetos) utilizamos los stream.Hay streams de entrada (InputStream,Reader) y stream de salida (OutputStream,Writer).

Los stream soportan 2 tipos de datos:

1. bytes brutos-->implementados por subclases de la clase InputStream y los streams de salida de bytes son implementados por subclases de la clase OutputStream.
2. caracteres Unicode--> implementados por subclases de la clase Reader y los streams de salida de caracteres son implementados por subclases de la clase Writer.