Programacin en red en MIDP2.

0
OBJETIVOS

El soporte que da MIDP2.0 a la programacin en red se basa, como en MIDP1.0, en el Generic Connection Framework de CLDC. CLDC Generic Connection Framework define una serie de interfaces para dar soporte a la variedad de tipos de conexiones que nos podemos encontrar en dispositivos mviles, pero no implementa ninguna de ellas. Es en los perfiles donde se debe realizar esta implementacin. En MIDP1.0, se daba soporte nicamente a conexiones HTTP, a travs de la implementacin del interfaz HttpConnection.Sin embargo, MIDP2.0 ofrece nuevas interfaces de conexin de red, lo que supone un conjunto de abstracciones ms completo que es de gran utilidad para el programador. Este cambio sustancial de MIDP2.0 respecto a MIDP1.0 surge como respuesta a la constante evolucin que experimentan tanto los terminales mviles (tecnologas GPRS y UMTS) como las aplicaciones que se disean para dichos terminales. Se imponen nuevos requisitos a los mecanismos de conexin que se traducen en la necesidad de un nuevo conjunto de abstracciones que pueda ser utilizado a nivel de programador. Los dispositivos que trabajan en conmutacin de circuitos necesitan conexiones basadas en flujo de bits, como por ejemplo el protocolo TCP.

Los dispositivos que trabajan en conmutacin de paquetes necesitan conexiones basadas en datagramas as que requerirn conexiones como las que ofrece el protocolo UDP.

Habr dispositivos con mecanismos especficos de conexin.

Como consecuencia MIDP2.0 responde al reto planteado ofreciendo multitud de formas de conexin manejables a nivel del programador y que no introducen un mayor grado de complejidad ya que todas ellas estn englobadas dentro del mismo conjunto de abstracciones mencionado anteriormente.

CLDC Generic Connection Framework

En el CLDC Generic Connection Framework, todas las conexiones se crean utilizando el mtodo esttico open de la clase Connector. Si no se produce ningn error, este mtodo devuelve un objeto que implementa una de las interfaces definidas en el CLDC Generic Connection Framework e implementadas por MIDP2.0:

Figura 1: Jeraqua de Intefaces del CLDC Generic Connection Framework

La interfaz Connection es el nodo raz en este arbol de jerarqua por lo que el resto de interfaces sern subinterfaces de Connection. En la figura, los interfaces en un recuadro amarillo son parte de CLDC 1.0. El interfaz HttpConnection fue aadido por MIDP 1.0. Los interfaces dentro de los recuadros azules son interfaces aadidos por MIDP 2.0. Todas estas interfaces estan contenidas en el paquete javax.microedition.io El interfaz Connection es el tipo bsico de conexin. Esta conexin slo puede abrirse y cerrarse.

El interfaz InputConnection representa un dispositivo desde el que se pueden leer datos. Proporciona el mtodo openInputStream que devuelve un stream de entrada para la conexin.

El interfaz OuputConnection representa un dispositivo en el que se pueden escribir datos. Proporciona el mtodo openOutputStream que devuelve un stream de salida para la conexin.

El interfaz StreamConnection que combina la conexiones de entrada y de salida anteriores.

El interfaz ContentConnection que es una subinterfaz de StreamConnection. Proporciona acceso a informacin de algunos meta datos proporcionados en una conexin HTTP.

El interfaz StreamConnectionNotified que espera a que se establezca una conexin. Devuelve un StreamConnection a travs del cual puede establecerse un enlace de comunicacin bidireccional.

El interfaz DatagramConnection que representa el destino de un datagrama.

El interfaz HttpConnection

El interfaz HttpsConnection (http seguro)

El interfaz CommConnection, conexiones por puerto serie.

El interfaz SocketConnection

El interfaz SecureConnection (sockets seguros)

El interfaz ServerSocketConnection

El interfaz UDPDatagramConnection

Como vemos hay un nmero considerable de interfaces y cada una de ellas nos permite establecer un tipo de conexin especfico y con un protocolo determinado. Sin embargo J2ME nos permite trabajar con estas interfaces de la manera ms sencilla posible. Para ello utilizaremos la clase Connector.

LA CLASE Connector

Esta clase nos ofrece un conjunto de mtodos que permiten abrir los distintos tipos de conexiones que definen los interfaces de los que hablamos anteriormente. open(String name): crea y abre una conexin con la URL especificada.

open(String name,int mode): crea y abre una conexin con la URL especificada con un determinado modo de acceso.

open(String name,int mode,boolean timeouts): crea y abre una conexin con la URL especificada con un determinado modo de acceso y especificando si el usuario desea que se produzcan excepciones de timeout.

openDataInputStream(String name)/ openDataOutputStream(String name): crea y abre una conexin para un flujo de datos de entrada / salida.

openInputStream(String name)/ openOutputStream(String name): crea y abre una conexin para un flujo de datos de entrada / salida.

El parmtero String name que aparece en la definicin de los mtodos tiene el formato "protocol:address;parameters". Algunos ejemplos de utilizacin de estos mtodos: o o o Conexin HTTP: Connector.open("http://www.it.uc3m.es/pervasive"); Conexin por datagramas:

o o o o o o o

Connector.open("datagram://address:port#"); Conexin por Sockets: Connector.open("socket://address:port#"); Conmunicacin con puerto serie: Connector.open("comm:0;baudrate=9600"); Acceso a ficheros: Connector.open("file:/miFichero.txt");

El objetivo de tener esta sintaxis, es abstraer al programador de las diferencias que existen entre los diferentes protocolos, de manera que la mayora del cdigo de una aplicacin no se modifica cuando se cambia el protocolo que se est usando. IMPORTANTE: Los ejemplos de conexiones anteriores son slo ilustrativos. CLDC en s mismo no proporciona ninguna implementacin de ningn protocolo, stas deben de proporcionarse a nivel de perfil. Adems un determinado perfil no tiene porque implementar todos los protocolos. As por ejemplo MIDP 1.0 slo proporcionaba una implementacin del protocolo HTTP, pero no implementaba ni sockets, ni datagramas (aunque algunos fabricantes pudieran incorporar esta posibilidad). MIDP 2.0 en cambio aade la implementacin de protocolos para establecer conexiones HTTP seguras, por Datagramas y mediante Sockets. A continuacin vemos los distintos interfaces que implementa MIDP 2.0.

HttpConnection

HTTP puede implementarse utilizando protocolos IP (como TCP/IP) o protocolos no-IP (como WAP o i-mode), por este motivo se seleccion como uno de los protocolos para comunicaciones de red en MIDP (en MIDP 1.0 era el nico implementado). Todas las implementaciones de MIDP (tanto 1.0 como 2.0) deben soportarlo, garantizando de esta manera la portabilidad de las aplicaciones, que utilizan este protocolo, entre diferentes dispositivos. Se define un nuevo interfaz dentro de la jerarqua del CLDC Generic Connection Framework, el interfaz HttpConnection para el soporte a conexiones HTTP. Este interfaz extiende del interfaz ContentConnection. El protocolo HTTP es un protocolo a nivel de aplicacin del tipo peticin/respuesta, en el que los parmetros de una peticin deben establecerse antes de que se enve la peticin. La conexin puede estar en uno de los siguientes tres posibles estados: "Setup": No se ha establecido todava la conexin.

"Connected": Se ha establecido la conexin, la peticin se ha enviado y se est esperando por una respuesta.

"Closed": La conexin se ha cerrado.

En el interfaz HttpConnection se proporcionan una serie de mtodos que pueden invocarse en cada uno de los estados anteriores: En el estado "setup" se pueden invocar los siguientes mtodos: setRequestMethod(String method) que establece el mtodo de la peticin, que puede ser POST, GET o HEAD. El mtodo por defecto es GET y si el mtodo no es HTTP o la implementacin de HTTP est recortada y no lo soporta, se produce una IOException.

setRequestProperty(String key, String value) que permite indicar el valor de algunas propiedades HTTP antes de enviar la peticin, la propiedad que se quiere establecer se indica en el parmetro key y su valor se establece en el parmetro value.

Por ejemplo, en el cdigo siguiente se crea una conexin HTTP a la URL http://www.it.uc3m.es/pervasive y se indica que el mtodo de la peticin es POST, y que la propiedad HTTP User-Agent tiene el valorProfile/MIDP-2.0 Configuration/CLDC-1.0: HttpConnection c = (HttpConnection)Connector.open("http://www.it.uc3m.es/pervasive"); c.setRequestMethod(HttpConnection.POST); c.setRequestProperty("User-Agent", "Profile/MIDP-2.0 Configuration/CLDC-1.0"); La transicin entre el estado "setup" y el estado "connected" se produce cuando se invoca algn mtodo que precisa enviar o recibir datos al servidor con el que se establece la conexin. Algunos de los mtodos que proporciona la implementacin del interfaz HttpConnection y que provocan esta transicin, son: openInputStream ()

openOutputStream()

openDataInputStream()

openDataOutputStream()

getLength()

getType()

getDate()

getExpiration()

Cuando la conexin est abierta (se ha pasado al estado de "connected"), se pueden invocar los siguientes mtodos: getURL()

getProtocol()

getHost()

getPort()

close()

A continuacin se muestra un ejemplo de cdigo en el que se utiliza la implementacin de HttpConnection para leer el contenido de la pgina http://www.it.uc3m.es/celeste/docencia/cr/hola.txt y mostrarselo al usuario (MIDletHTTPExample.java): import java.io.*; import javax.microedition.midlet.*; import javax.microedition.io.*;

import javax.microedition.lcdui.*; /** * Un ejemplo de MIDlet para visualizar el contenido de una URL * utilizando la implementacin del interfaz HttpConnection. */ public class MIDletHTTPExample extends MIDlet { private Display display; private String url = "http://www.it.uc3m.es/celeste/docencia/cr/hola.txt"; public MIDletHTTPExample() { display = Display.getDisplay(this); } /** * Mtodo startApp() */ public void startApp() { // Llama al mtodo download para descargar el contenido de la URL try { download(url); } catch(IOException e) { System.out.println("IOException: " + e); } } private void download (String url) throws IOException { StringBuffer b = new StringBuffer(); InputStream is = null; HttpConnection c = null; TextBox t = null; try { long len = 0 ; int ch = 0; // Abre una conexin del tipo HttpConnection c = (HttpConnection)Connector.open(url); // Obtiene un stream de entrada, para leer el contenido de la url // con la que establece la conexin is = c.openInputStream(); // Lee hasta que se cierra la conexin while ((ch = is.read()) != -1) { b.append((char)ch); } // Se contruye un TextBox con el contenido de la URL t = new TextBox("Hola...", b.toString(), 1024, 0); } finally { // Se cierra tanto el stream de entrada

if (is != null) is.close(); // Se cierra la conexin if (c != null) c.close(); } // Se visualiza el TextBox en el Display display.setCurrent(t); } /** * pauseApp */ public void pauseApp() { } /** * destroyApp */ public void destroyApp(boolean unconditional) { } }

HttpsConnection (Conexin HTTP segura)

HTTPS es la versin segura del protocolo HTTP y consiste bsicamente en establecer conexiones HTTP sobre SSL (Secure Sockets Layer). Para poder establecer este tipo de conexiones MIDP 2.0 implementa el interfazHttpsConnection, que es un subinterfaz de HttpConnection. Por tanto, el interfaz HttpsConnection implementa, adems de los mtodos y constantes que hereda de HttpConnection, nuevos mtodos y constantes que permiten establecer conexiones de red seguras. La manera de trabajar con este interfaz es idntica a la que vimos en el apartado anterior para conexiones HTTP convencionales. La nica diferencia es que en este caso utilizaremos un objeto HttpsConnection. Los mtodos adicionales que aporta el interfaz HttpsConnection son los siguientes: getPort(): devuelve el puerto utilizado por una HttpsConnection. getSecurityInfo(): devuelve la informacin de seguridad (objeto javax.microedition.io.SecurityInfo )asociada a una conexin establecida correctamente. Si la conexin se encuentra en el estado setup ser inicializada para establecer una conexin segura con el servidor. El mtodo devolver el resultado cuando la conexin haya sido establecida y se haya validado el certificado dado por el servidor.

Otra novedad que introducen las conexiones HTTP seguras son las excepciones CertificateException. Son un subtipo de la IOException y ocurren en la transicin al estado "connected". Estn relacionadas especficamente con errores ocurridos en

el establecimiento de conexiones seguras. Ejemplo de utilizacin del interfaz HttpsConnection: EjemploHttpSeguro.java Cabe en este punto introducir un nuevo interfaz especificado por MIDP 2.0 : SecurityInfo. Este interfaz, que veremos a continuacin, permite acceder a informacin relativa a conexiones seguras.

SecurityInfo

El interfaz SecurityInfo implementa, como ya se ha dicho, una serie de mtodos que permiten acceder a la informacin asociada a conexiones seguras. Cualquiera de los protocolos que MIDP 2.0 implementa para establecer estas conexiones seguras (Https o sockets seguros sobre ssl) pueden utilizar estos mtodos para conocer los parmetros de seguridad de estas conexiones. El API del interfaz SecurityInfo se muestra a continuacin: getCipherSuite(): devuelve un String con el nombre del sistema de cifrado que se est utilizando.

getProtocolName(): devuelve el protocolo seguro al que pertenece la conexin.

getProtocolVersion(): devuelve la versin utilizada del protocolo seguro.

getServerCertificate(): devuelve el certificado (objeto Certificate) utilizado para establecer la conexin segura.

Ejemplo: // obtener el objeto SecurityInfo asociado a una conexion segura SecurityInfo secInfo = conexionSegura.getSecurityInfo(); // Extraer informacion de seguridad String cipherSuite = secInfo.getCipherSuite(); String protocol = secInfo.getProtocolName(); String version = secInfo.getProtocolVersion(); Certificate certificado = secInfo.getServerCertificate();

CommConnection

El interfaz CommConection define una conexin lgica con un puerto serie. El puerto en cuestin no tiene por qu corresponder a un puerto serie fsico sino que puede ser un puerto lgico definido por el sistema operativo. Como corresponde a este tipo de conexiones la informacin se transmitir como un flujo de bits en serie. Como ya se dijo anteriormente todos los tipos de conexin existentes se abren utilizando el mtodo open(String URL) de la clase Connector. En este caso el String que debemos pasar como parmetro debe tener el siguiente formato: comm:< identificador del puerto >[< parmetros opcionales >] Los parmetros opcionales son los que definen como ser la conexin. Habr definidos unos valores por defecto que sern aplicados en caso de que no se especifiquen a la hora de establecer la conexin. Los parmetros son los siguientes: Parametro baudrate Valor por defecto depende de la plataforma 1 ninguna on on on Descripcin Define la velocidad de transferencia de bits. Numero de bits por caracter (7 8). Numero de bits de parada por caracter (1 2) Control de errores por paridad. Puede ser par(even), impar(odd), o ninguna(none) Se espera (on) o no (off) a tener el fuffer de entrada lleno para leer Se espera (on) o no (off) a que la lnea CTS est activada antes de escribir Con on actviva la lnea RTS cuando el buffer de entrada no est lleno. Con off la lnea RTS est siempre activada.

bitsperchar 8 stopbits parity blocking autocts autorts

Tanto para establecer la conexin como para especificar los parmetros opcionales que se deseen utilizaremos el mtodo open() de la clase Connector. Para ello el String que pasaremos como argumento debe tener el formato adecuado o de lo contrario se producir una IllegalArgumentException. Para trabajar con conexiones por puerto serie se implementan, adems de los mtodos heredados de las interfaces Connection, InputConnection y OutputConnection, dos mtodos adicionales: getBaudRate(): devuelve la tasa de transferencia de la conexin. setBaudRate(int baud_rate): permite fijar la tasa de transferencia de la conexin. Si el

valor especificado no es vlido el sistema fijar un valor.

SocketConnection

Este interfaz define la abstraccin de sockets lo que nos permitir comunicar distintos procesos entre s incluso cuando estos se estn ejecutando en distintos dispositivos. Para poder crear un socket necesitaremos un String de conexin genrico que especifique explicitamente un host y un puerto con los que establecer el socket mediante la expresin ya conocida Connector.open(...). Ejemplo: SocketConnection socket = (SocketConnection)Connector.open("socket://< host >:< port >"); El interfaz SocketConnection implementa StreamConnection que a su vez proporciona un objeto Connection a la vez que objetos de I/O (un InputStream y un OutputStream) que permiten trabajar con la conexin socket. Cada uno de estos interfaces tiene su propio mtodo close(). As pues, en sistemas que soporten comunicacin duplex, debe ser posible cerrar uno de los sentidos de la comunicacin si afectar al otro. La implementacin del interfaz SocketConnection define los siguientes mtodos: getAddress(): devuelve la direccin remota con la que se ha establecido la conexin. getLocalAddress(): devuelve la direccin local en la que se ha establecido la conexin. getLocalPort(): devuelve el puerto local dnde se encuentra establecido el socket. getPort(): devuelve el puerto remoto en el que se estableci el socket. getSocketOption(byte option): devuelve el valor de la opcin especificada. setSocketOption(byte option, int value): fija el valor de la opcin especificada.

En este enlace puede ver un ejemplo (EjemploClient.java) de un cliente que conecta con un terminal remoto a travs de sockets. En dicho terminal remoto (que se supone est ejecutando en el mismo ordenador) estar ejecutando un socket servidor. Este MIDlet podr ser descargado en el siguiente apartado.

SecureConnection

Este interfaz define una conexin mediante sockets seguros que consiste en una conexin basada en SSL (Secure Socket Layer). Esta conexin segura se establece utilizando Connector.open(..) con un String de conexin genrico que especifique, adems de un host y un puerto destino, que dicha conexin debe apoyarse en el protocolo SSL.

Ejemplo: SecureConnection secureSocket = (SecureConnection)Connector.open("ssl://< host >:< port >"); Si tras llamar al mtodo open no se pudo establecer la conexin debido a algn error relacionado con los certificados de seguridad se lanzar una CertificateException Como subinterfaz de SocketConnection, el interfaz SecureConnection implementar todos los mtodos que se expusieron en el apartado anterior. Adems de estos implementa el siguiente mtodo: getSecurityInfo(): devuelve un objeto SecurityInfo con la informacin relativa a la seguridad asociada a una conexin segura.

ServerSocketConnection

El interfaz ServerSocketConnection define un socket servidor o pasivo. La finalidad de este tipo especial de sockets es el poder conectar dos sockets establecidos en distintas mquinas de manera que stas puedan comunicarse entre s. De no disponer de un socket servidor ambos terminales deberan establecer un socket genrico de forma simultnea, producindose un error en caso contrario. Gracias a ServerSocketConnection dispondremos de un servidor que facilita esta labor. El servidor permanecer escuchando las peticiones de conexin de los clientes (se tratar simplemente del establecimiento de sockets genricos). Cuando reciba estas peticiones devolver una instancia de unSocketConnection y la comunicacin entre ambos terminales estar establecida. La forma en que el objeto ServerSocketConnection lleva a cabo lo anteriormente explicado es muy sencillo: utiliza el mtodo acceptAndOpen() heredado de la clase javax.microedition.io.StreamConnectionNotifier. Ejemplo: SocketConnection socket = (SocketConnection)serverSocket.acceptAndOpen(); En el ejemplo anterior el servidor permanecer a la espera hasta recibir una peticin de conexin SocketConnection dirigida a la mquina y puerto en los que est escuchando. Una vez recibida la peticin el mtodo terminar su ejecucin devolviendo la instancia que representa la conexin mediante sockets. El nico dato que nos queda por conocer para poder implementar lo hasta ahora visto es cmo crear una instancia de ServerSocketConnection. Para ello utilizaremos, igual que en todos los tipos de conexin vistos hasta ahora, el metodo open() de la clase Connector. La nica diferencia respecto a lo visto hasta ahora es que al crear una conexin ServerSocketConnection no se debe especificar el host con el que establecerla ya que ser siempre la mquina local: ServerSocketConnection serverSocket = (ServerSocketConnection)Connector.open("socket://:< port number >"); Al igual que en los demas tipos de conexiones vistos hasta ahora, podemos omitir el puerto para conseguir una asignacin dinmica de un puerto disponible (el sistema gestionar dicha

asignacin): ServerSocketConnection serverSocket = (ServerSocketConnection)Connector.open("socket://"); En este ltimo caso, para conocer el puerto sobre el que se ha establecido la conexin, debemos ejecutar el mtodo getLocalPort() que veremos ms adelante. Los mtodos disponibles en el interfaz ServerSocketConnection son: getLocalAddress(): devuelve la direccin local en la que se ha establecido el socket. Esta es la direccin IP a la que otros terminales deben solicitar el establecimiento de un socket tal y como se explic anteriormente. Dado que las direcciones IP pueden ser asignadas dinmicamente habr que prestar atencin en este aspecto e implementar aplicaciones robustas frente a cambios de la direccin IP del socket servidor. ATENCIN: Para acceder a la direccin IP de la mquina local se puede utilizar System.getProperty("microedition.hostname").

getLocalPort(): devuelve el nmero de puerto local en el que se ha establecido el socket.

EjemploServer.java, MIDlet ejemplo en el que se establece un socket servidor esperando peticiones de establecimiento de sockets por parte de los clientes (MIDlet que puede ser descargado en el apartado anterior).

UDPDatagramConnection

El interfaz UDPDatagramConnection define una conexin por datagramas de la que se conoce la direccin del punto de terminacin ("end point") local. Las caractersticas de este tipo de conexin no varan por tratarse de terminales mviles. Al trabajar con el protocolo UDP nos enfrentamos a dos limitaciones inherentes a ste: no se garantiza la entrega y no existe proteccin frente a duplicados. En comunicaciones sencillas, sin fuertes requisitos de prdidas o duplicados, las conexiones por datagramas UDP representan un modo eficiente de establecer la comunicacin. Sin embargo, en aplicaciones no resistentes frente a prdidas o duplicados, ser necesario trabajar con sockets TCP(utilizando el interfaz ServerSocketConnection que acabamos de ver), penalizando en la cantidad de recursos consumidos (las cabeceras TCP tienen un gran tamao por lo que el ancho de banda utilizado es mucho menor). Habr que tener en cuenta entonces cuales son los requisitos de nuestra aplicacin para decidirnos por un protocolo u otro estableciendo un compromiso entre fiabilidad y consumo de recursos (en dispositivos limitados como los terminales mviles nos enfrentaremos a nuevas limitaciones). Para obtener una instancia de UDPDatagramConnection recurriremos, como ya es habitual, al mtodo open() de la clase Connector. El formato en el que se debe especificar la direccin para establecer la conexin UDP es el mismo que el utilizado para especificar la direccin destino de un datagrama (utilizando Datagram.setAddress()): Ejemplo:

UDPDatagramConnection UDPDat = (UDPDatagramConnection)Connector.open("datagram://< host >:< port >"); Los mtodos disponibles en el interfaz UDPDatagramConnection son: getLocalAddress(): devuelve la direccin local en la que se ha establecido la conexin por datagramas. getLocalPort(): devuelve el puerto local sobre el que se ha establecido la conexin por datagramas.

LA CLASE PushRegistry

Esta clase constituye una novedad de MIDP 2.0 respecto a la versin 1.0 y se encuentra tambin en el paquete javax.microedition.io. El push registry permite que los MIDlets puedan ser lanzados automticamente sin necesidad de ser inicializados por el usuario. El concepto de push registry no modifica el ciclo de vida del MIDlet, simplemente introduce dos nuevas vas por las que un MIDlet puede ser activado: o o Activacin causada por conexiones de red entrantes (gracias a que MIDP 2.0 implementa nuevos interfaces de conexin como TCP, datagramas UDP e incluso SMS). Activacin causada por temporizadores.

Ser el push registry el que gestione la activacin de estos MIDlets almacenando las conexiones o alarmas temporales que "despertarn" a un determinado MIDlet.

Figura 2: Modelo de ciclo de vida de un MIDlet

El push registry es parte del sistema gestor de aplicaciones (Application Management System o AMS), que es el software residente en el dispositivo mvil que es responsable del ciclo de vida de cada aplicacin (instalacin, activacin, ejecucin y eliminacin). Sin embargo, a nivel de programacin, es decir, en el propio cdigo del MIDlet, tambin podremos llevar a cabo actuaciones sobre el push registry. Para ello utilizaremos el API de la clase PushRegistry.

Figura 3: Elementos tpicos del Push Registry

CONEXIONES ESTTICAS Y DINMICAS. Para habilitar la activacin "push" los MIDlets deben utilizar el push registry como ya vimos anteriormente. Se pueden llevar a cabo dos tipos de registros: Registros estticos - Registrar conexiones estticas, es decir, las que sabemos con toda seguridad que se producirn y que son imprescindibles para el buen funcionamiento del MIDlet. Registros dinmicos - Registrar conexiones dinmicas (las que pueden establecerse, o no, a lo largo de la ejecucin del MIDlet) y alarmas. sta es la nica manera de registrar los temporizadores asociados a un MIDlet.

Cada uno de estas dos maneras de registrar "eventos activadores" del MIDlet son tratadas con ms detalle a continuacin. REGISTRO DE CONEXIONES ESTTICAS. El registro de conexiones estticas ocurre durante la instalacin del MIDlet suite. Para ello se deben especificar todas las conexiones a registrar mediantes los atributos MIDlet-Push en el fichero JAD o en el Manifiesto. Cada entrada tendr el siguiente formato: MIDlet-Push-< n >: < ConnectionURL >, < MIDletClassName >, < AllowedSender > Ejemplo: MIDlet-Push-1: socket://:79, com.sun.example.SampleChat, * MIDlet-Push-2: datagram://:50000, com.sun.example.SampleChat, * stas son dos entradas del fichero descriptor que reservaran una conexin socket en el puerto 79 y una conexin por datagramas en el puerto 5000. Si todas las entradas que incluyamos en el descriptor no pueden ser satisfechas (errores de sintaxis en la declaracin, reserva de un puerto o una conexin ya ocupados, declaracin de un protocolo no registrable ...) se informar al usuario y se le recomendar no instalar el MIDlet suite. Sin embargo si, an sin poder llevar a cabo todos los registros en el push registry la aplicacin puede funcionar de manera aceptable deber registrar dinmicamente (utilizando el API de la clase PushRegistry) las conexiones que no pudieron ser registradas estticamente con sus entradas correspondientes en el fichero descriptor. Por ltimo, hay que tener en cuenta que la instalacin del MIDlet suite con declaraciones como las anteriores en el fichero descriptor reserva las conexiones solicitadas para uso exclusivo de los MIDlets dentro de dicho suite. Mientras que ste est instalado, cualquier intento por parte de otras aplicaciones de abrir una de las conexiones reservadas ser rechazado produciendo uno IOException. Si dos MIDlet suites tienen una conexin "push" esttica en comn no podrn ser instalados simultneamente y si as sucediera su funcionamiento no sera correcto.

REGISTRO DE CONEXIONES DINMICAS.EL API DE LA CLASE PushRegistry

Para el registro de conexiones "push" dinmicas utilizaremos los mtodos de la clase javax.microedition.io.PushRegistry. Son los siguientes: getFilter(String connection): recupera el filtro asociado a la conexin que se pasa como parmetro. Devuelve un String indicando que conexiones entrantes pueden activar la ejecucin del MIDlet o null si esta conexin no fue registrada en el push registry por el correspondiente MIDlet suite. getMIDlet(String connection): recupera el MIDlet al que est asociada la conexin especificada, devolviendo un String con el nombre de clase del MIDlet o null si no hay ningn MIDlet asociado. registerAlarm(String midlet,long time): registra un temporizador para que el MIDlet se ejecute automticamente. NOTA: El PushRegistry acepta slo un temporizador por MIDlet. La aplicacin debe tener un "TimerTask" para notificar a la aplicacin los eventos del temporizador en tiempo. Si intentamos registrar un temporizador que ya est registrado el mtodo devolver el valor anterior de dicho temporizador, es decir, el instante para el que estaba programada la ejecucin del MIDlet. Si es la primera vez que se hace el registro devolver cero. listConnections(boolean available): devuelve una lista (String[]) con los nombres de las conexiones registradas por el MIDlet suite instalado. Los Strings devueltos tendrn el formato de una conexin genrica: protocolo, host y puerto . registerConnection(String connection, String midlet, String filter): registra una conexin dinmica que una vez registrada funcionar igual que una conexin pre-alojada por el fichero descriptor. Los atributos son los mismos que en elPush Registration Atribute que se utiliza para registrar conexiones estticas. unregisterConnection(String connection): elimina del registro la una conexin dinmica, devolviendo el resultado de la operacin. NOTA IMPORTANTE: Cuando se implemente un MIDlet que al terminar su ejecucin registre una alarma para ser activado tras un cierto tiempo, dicho registro debe ser gestionado por un nuevo hilo de ejecucin para evitar "dead lock". El motivo es que existe el riesgo de que la ejecucin del MIDlet llegue a su fin sin que se haya podido llevar a cabo el proceso de registrar la alarma de activacin. Ejemplo de MIDlet que registra una alarma para su activacin pasado un tiempo determinado: EjemploPush.java
EJEMPLOS

Descargar aqu el fichero que contiene el proyecto completo con todos los archivos que han aparecido a lo largo del documento.
ENLACES

API MIDP/CLDC

inicio | tabln| contacta