sábado, 15 de noviembre de 2014

J2ME Tutorial Parte VIII

Programación en red en MIDP2.0

 OBJETIVOS
El soporte que da MIDP2.0 a la programación 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 móviles, pero no implementa ninguna de ellas. Es en los perfiles donde se debe realizar esta implementación. En MIDP1.0, se daba soporte únicamente a conexiones HTTP, a través de la implementación del interfaz HttpConnection.Sin embargo, MIDP2.0 ofrece nuevas interfaces de conexión de red, lo que supone un conjunto de abstracciones más 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 evolución que experimentan tanto los terminales móviles (tecnologías GPRS y UMTS) como las aplicaciones que se diseñan para dichos terminales. Se imponen nuevos requisitos a los mecanismos de conexión 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 conmutación de circuitos necesitan conexiones basadas en flujo de bits, como por ejemplo el protocolo TCP.
  • Los dispositivos que trabajan en conmutación de paquetes necesitan conexiones basadas en datagramas así que requerirán conexiones como las que ofrece el protocolo UDP.
  • Habrá dispositivos con mecanismos específicos de conexión.
Como consecuencia MIDP2.0 responde al reto planteado ofreciendo multitud de formas de conexión manejables a nivel del programador y que no introducen un mayor grado de complejidad ya que todas ellas están 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 método estático open de la clase Connector. Si no se produce ningún error, este método devuelve un objeto que implementa una de las interfaces definidas en el CLDC Generic Connection Framework e implementadas por MIDP2.0:

Figura1
Figura 1: Jeraquía de Intefaces del CLDC Generic Connection Framework

 La interfaz Connection es el nodo raíz en este arbol de jerarquía por lo que el resto de interfaces serán subinterfaces de Connection. En la figura, los interfaces en un recuadro amarillo son parte de CLDC 1.0. El interfaz HttpConnection fue añadido por MIDP 1.0. Los interfaces dentro de los recuadros azules son interfaces añadidos por MIDP 2.0.
Todas estas interfaces estan contenidas en el paquete javax.microedition.io

Como vemos hay un número considerable de interfaces y cada una de ellas nos permite establecer un tipo de conexión específico y con un protocolo determinado. Sin embargo J2ME nos permite trabajar con estas interfaces de la manera más sencilla posible. Para ello utilizaremos la clase Connector.



 LA CLASE Connector

Esta clase nos ofrece un conjunto de métodos que permiten abrir los distintos tipos de conexiones que definen los interfaces de los que hablamos anteriormente.
  • open(String name): crea y abre una conexión con la URL especificada.

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

  • open(String name,int mode,boolean timeouts): crea y abre una conexión 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 conexión para un flujo de datos de entrada / salida.

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


    El parámtero String name que aparece en la definición de los métodos tiene el formato "protocol:address;parameters".

    Algunos ejemplos de utilización de estos métodos:

    • Conexión HTTP:
      Connector.open("http://www.it.uc3m.es/pervasive");
      
    • Conexión por datagramas:
      Connector.open("datagram://address:port#");
      
    • Conexión por Sockets:
      Connector.open("socket://address:port#");
      
    • Conmunicación 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 mayoría del código de una aplicación no se modifica cuando se cambia el protocolo que se está usando.

IMPORTANTE: Los ejemplos de conexiones anteriores son sólo ilustrativos. CLDC en sí mismo no proporciona ninguna implementación de ningún protocolo, éstas deben de proporcionarse a nivel de perfil. Además un determinado perfil no tiene porque implementar todos los protocolos. Así por ejemplo MIDP 1.0 sólo proporcionaba una implementación del protocolo HTTP, pero no implementaba ni sockets, ni datagramas (aunque algunos fabricantes pudieran incorporar esta posibilidad).
MIDP 2.0 en cambio añade la implementación de protocolos para establecer conexiones HTTP seguras, por Datagramas y mediante Sockets.

A continuación 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 jerarquía 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 aplicación del tipo petición/respuesta, en el que los parámetros de una petición deben establecerse antes de que se envíe la petición. La conexión puede estar en uno de los siguientes tres posibles estados:

  • "Setup": No se ha establecido todavía la conexión.

  • "Connected": Se ha establecido la conexión, la petición se ha enviado y se está esperando por una respuesta.

  • "Closed": La conexión se ha cerrado.

En el interfaz HttpConnection se proporcionan una serie de métodos que pueden invocarse en cada uno de los estados anteriores:

En el estado "setup" se pueden invocar los siguientes métodos:

  • setRequestMethod(String method) que establece el método de la petición, que puede ser POST, GET o HEAD. El método por defecto es GET y si el método no es HTTP o la implementación 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 petición, la propiedad que se quiere establecer se indica en el parámetro key y su valor se establece en el parámetro value.
Por ejemplo, en el código siguiente se crea una conexión HTTP a la URL http://www.it.uc3m.es/pervasive y se indica que el método de la petición es POST, y que la propiedad HTTP User-Agent tiene el valor Profile/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 transición entre el estado "setup" y el estado "connected" se produce cuando se invoca algún método que precisa enviar o recibir datos al servidor con el que se establece la conexión. Algunos de los métodos que proporciona la implementación del interfaz HttpConnection y que provocan esta transición, son:

Cuando la conexión está abierta (se ha pasado al estado de "connected"), se pueden invocar los siguientes métodos:
A continuación se muestra un ejemplo de código en el que se utiliza la implementación de HttpConnection para leer el contenido de la página 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 implementación 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);
  }

  /**
   * Método startApp()
   */
  public void startApp() {
    // Llama al método 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 conexión 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 conexión
      is = c.openInputStream();
      
      // Lee hasta que se cierra la conexión
      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 conexión
      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 (Conexión HTTP segura)
HTTPS es la versión segura del protocolo HTTP y consiste básicamente en establecer conexiones HTTP sobre SSL (Secure Sockets Layer). Para poder establecer este tipo de conexiones MIDP 2.0 implementa el interfaz HttpsConnection, que es un subinterfaz de HttpConnection. Por tanto, el interfaz HttpsConnection implementa, además de los métodos y constantes que hereda de HttpConnection, nuevos métodos y constantes que permiten establecer conexiones de red seguras.

La manera de trabajar con este interfaz es idéntica 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 métodos adicionales que aporta el interfaz HttpsConnection son los siguientes:

  • getPort(): devuelve el puerto utilizado por una HttpsConnection.
  • getSecurityInfo(): devuelve la información de seguridad (objeto javax.microedition.io.SecurityInfo )asociada a una conexión establecida correctamente.
    Si la conexión se encuentra en el estado setup será inicializada para establecer una conexión segura con el servidor. El método devolverá el resultado cuando la conexión 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 transición al estado "connected". Están relacionadas específicamente con errores ocurridos en el establecimiento de conexiones seguras.

Ejemplo de utilización del interfaz HttpsConnection: EjemploHttpSeguro.java

Cabe en este punto introducir un nuevo interfaz especificado por MIDP 2.0 : SecurityInfo. Este interfaz, que veremos a continuación, permite acceder a información relativa a conexiones seguras.


 SecurityInfo
El interfaz SecurityInfo implementa, como ya se ha dicho, una serie de métodos que permiten acceder a la información 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 métodos para conocer los parámetros de seguridad de estas conexiones.

El API del interfaz SecurityInfo se muestra a continuación:

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 conexión lógica con un puerto serie. El puerto en cuestión no tiene por qué corresponder a un puerto serie físico sino que puede ser un puerto lógico definido por el sistema operativo. Como corresponde a este tipo de conexiones la información se transmitirá como un flujo de bits en serie.

Como ya se dijo anteriormente todos los tipos de conexión existentes se abren utilizando el método open(String URL) de la clase Connector. En este caso el String que debemos pasar como parámetro debe tener el siguiente formato:

comm:< identificador del puerto >[< parámetros opcionales >]
Los parámetros opcionales son los que definen como será la conexión. Habrá definidos unos valores por defecto que serán aplicados en caso de que no se especifiquen a la hora de establecer la conexión.

Los parámetros son los siguientes:
Parametro Valor por
defecto
Descripción
baudrate depende de
la plataforma
Define la velocidad de transferencia de bits.
bitsperchar 8 Numero de bits por caracter (7 ó 8).
stopbits 1 Numero de bits de parada por caracter (1 ó 2)
parity ninguna Control de errores por paridad. Puede ser par(even), impar(odd), o ninguna(none)
blocking on Se espera (on) o no (off) a tener el fuffer de entrada lleno para leer
autocts on Se espera (on) o no (off) a que la línea CTS esté activada antes de escribir
autorts on Con on actviva la línea RTS cuando el buffer de entrada no está lleno.
Con off la línea RTS está siempre activada.

Tanto para establecer la conexión como para especificar los parámetros opcionales que se deseen utilizaremos el método 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, además de los métodos heredados de las interfaces Connection, InputConnection y OutputConnection, dos métodos adicionales:
  • getBaudRate(): devuelve la tasa de transferencia de la conexión.
  • setBaudRate(int baud_rate): permite fijar la tasa de transferencia de la conexión. Si el valor especificado no es válido el sistema fijará un valor.

 SocketConnection
Este interfaz define la abstracción de sockets lo que nos permitirá comunicar distintos procesos entre sí incluso cuando estos se estén ejecutando en distintos dispositivos. Para poder crear un socket necesitaremos un String de conexión genérico que especifique explicitamente un host y un puerto con los que establecer el socket mediante la expresión 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 conexión socket.
Cada uno de estos interfaces tiene su propio método close(). Así pues, en sistemas que soporten comunicación duplex, debe ser posible cerrar uno de los sentidos de la comunicación si afectar al otro.

La implementación del interfaz SocketConnection define los siguientes métodos:

En este enlace puede ver un ejemplo (EjemploClient.java) de un cliente que conecta con un terminal remoto a través 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 conexión mediante sockets seguros que consiste en una conexión basada en SSL (Secure Socket Layer). Esta conexión segura se establece utilizando Connector.open(..) con un String de conexión genérico que especifique, además de un host y un puerto destino, que dicha conexión debe apoyarse en el protocolo SSL.

Ejemplo:
   
  SecureConnection secureSocket = 
    (SecureConnection)Connector.open("ssl://< host >:< port >"); 
Si tras llamar al método open no se pudo establecer la conexión debido a algún error relacionado con los certificados de seguridad se lanzará una CertificateException

Como subinterfaz de SocketConnection, el interfaz SecureConnection implementará todos los métodos que se expusieron en el apartado anterior. Además de estos implementa el siguiente método:

  • getSecurityInfo(): devuelve un objeto SecurityInfo con la información relativa a la seguridad asociada a una conexión 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 máquinas de manera que éstas puedan comunicarse entre sí. De no disponer de un socket servidor ambos terminales deberían establecer un socket genérico de forma simultánea, produciéndose un error en caso contrario. Gracias a ServerSocketConnection dispondremos de un servidor que facilita esta labor. El servidor permanecerá escuchando las peticiones de conexión de los clientes (se tratará simplemente del establecimiento de sockets genéricos). Cuando reciba estas peticiones devolverá una instancia de un SocketConnection y la comunicación entre ambos terminales estará establecida.

La forma en que el objeto ServerSocketConnection lleva a cabo lo anteriormente explicado es muy sencillo: utiliza el método 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 petición de conexión SocketConnection dirigida a la máquina y puerto en los que esté escuchando. Una vez recibida la petición el método terminará su ejecución devolviendo la instancia que representa la conexión mediante sockets.

El único dato que nos queda por conocer para poder implementar lo hasta ahora visto es cómo crear una instancia de ServerSocketConnection. Para ello utilizaremos, igual que en todos los tipos de conexión vistos hasta ahora, el metodo open() de la clase Connector. La única diferencia respecto a lo visto hasta ahora es que al crear una conexión ServerSocketConnection no se debe especificar el host con el que establecerla ya que será siempre la máquina 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 asignación dinámica de un puerto disponible (el sistema gestionará dicha asignación):
ServerSocketConnection serverSocket = (ServerSocketConnection)Connector.open("socket://");
En este último caso, para conocer el puerto sobre el que se ha establecido la conexión, debemos ejecutar el método getLocalPort() que veremos más adelante.

Los métodos disponibles en el interfaz ServerSocketConnection son:
  • getLocalAddress(): devuelve la dirección local en la que se ha establecido el socket.
    Esta es la dirección 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 dinámicamente habrá que prestar atención en este aspecto e implementar aplicaciones robustas frente a cambios de la dirección IP del socket servidor.

    ATENCIÓN: Para acceder a la dirección IP de la máquina local se puede utilizar System.getProperty("microedition.hostname").

  • getLocalPort(): devuelve el número 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 conexión por datagramas de la que se conoce la dirección del punto de terminación ("end point") local. Las características de este tipo de conexión no varían por tratarse de terminales móviles. Al trabajar con el protocolo UDP nos enfrentamos a dos limitaciones inherentes a éste: no se garantiza la entrega y no existe protección frente a duplicados. En comunicaciones sencillas, sin fuertes requisitos de pérdidas o duplicados, las conexiones por datagramas UDP representan un modo eficiente de establecer la comunicación. Sin embargo, en aplicaciones no resistentes frente a pérdidas 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 tamaño por lo que el ancho de banda utilizado es mucho menor). Habrá que tener en cuenta entonces cuales son los requisitos de nuestra aplicación para decidirnos por un protocolo u otro estableciendo un compromiso entre fiabilidad y consumo de recursos (en dispositivos limitados como los terminales móviles nos enfrentaremos a nuevas limitaciones).

Para obtener una instancia de UDPDatagramConnection recurriremos, como ya es habitual, al método open() de la clase Connector. El formato en el que se debe especificar la dirección para establecer la conexión UDP es el mismo que el utilizado para especificar la dirección destino de un datagrama (utilizando Datagram.setAddress()):
Ejemplo:

  UDPDatagramConnection UDPDat = (UDPDatagramConnection)Connector.open("datagram://< host >:< port >");

Los métodos disponibles en el interfaz UDPDatagramConnection son:
  • getLocalAddress(): devuelve la dirección local en la que se ha establecido la conexión por datagramas.
  • getLocalPort(): devuelve el puerto local sobre el que se ha establecido la conexión por datagramas.

 LA CLASE PushRegistry
Esta clase constituye una novedad de MIDP 2.0 respecto a la versión 1.0 y se encuentra también en el paquete javax.microedition.io. El push registry permite que los MIDlets puedan ser lanzados automáticamente 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 vías por las que un MIDlet puede ser activado:

    • Activación causada por conexiones de red entrantes (gracias a que MIDP 2.0 implementa nuevos interfaces de conexión como TCP, datagramas UDP e incluso SMS).
    • Activación causada por temporizadores.
Será el push registry el que gestione la activación de estos MIDlets almacenando las conexiones o alarmas temporales que "despertarán" a un determinado MIDlet.

Figura2
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 móvil que es responsable del ciclo de vida de cada aplicación (instalación, activación, ejecución y eliminación). Sin embargo, a nivel de programación, es decir, en el propio código del MIDlet, también podremos llevar a cabo actuaciones sobre el push registry. Para ello utilizaremos el API de la clase PushRegistry.

Figura3
Figura 3: Elementos típicos del Push Registry


CONEXIONES ESTÁTICAS Y DINÁMICAS.

Para habilitar la activación "push" los MIDlets deben utilizar el push registry como ya vimos anteriormente. Se pueden llevar a cabo dos tipos de registros:
  • Registros estáticos - Registrar conexiones estáticas, es decir, las que sabemos con toda seguridad que se producirán y que son imprescindibles para el buen funcionamiento del MIDlet.
  • Registros dinámicos - Registrar conexiones dinámicas (las que pueden establecerse, o no, a lo largo de la ejecución 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 más detalle a continuación.
REGISTRO DE CONEXIONES ESTÁTICAS.

El registro de conexiones estáticas ocurre durante la instalación 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 reservarían una conexión socket en el puerto 79 y una conexión por datagramas en el puerto 5000. Si todas las entradas que incluyamos en el descriptor no pueden ser satisfechas (errores de sintaxis en la declaración, reserva de un puerto o una conexión ya ocupados, declaración de un protocolo no registrable ...) se informará al usuario y se le recomendará no instalar el MIDlet suite. Sin embargo si, aún sin poder llevar a cabo todos los registros en el push registry la aplicación puede funcionar de manera aceptable deberá registrar dinámicamente (utilizando el API de la clase PushRegistry) las conexiones que no pudieron ser registradas estáticamente con sus entradas correspondientes en el fichero descriptor.

Por último, hay que tener en cuenta que la instalación 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 conexión "push" estática en común no podrán ser instalados simultáneamente y si así sucediera su funcionamiento no sería correcto.


REGISTRO DE CONEXIONES DINÁMICAS.EL API DE LA CLASE PushRegistry

Para el registro de conexiones "push" dinámicas utilizaremos los métodos de la clase javax.microedition.io.PushRegistry. Son los siguientes:

  • getFilter(String connection): recupera el filtro asociado a la conexión que se pasa como parámetro. Devuelve un String indicando que conexiones entrantes pueden activar la ejecución del MIDlet o null si esta conexión no fue registrada en el push registry por el correspondiente MIDlet suite.


  • getMIDlet(String connection): recupera el MIDlet al que está asociada la conexión especificada, devolviendo un String con el nombre de clase del MIDlet o null si no hay ningún MIDlet asociado.


  • registerAlarm(String midlet,long time): registra un temporizador para que el MIDlet se ejecute automáticamente.

    NOTA: El PushRegistry acepta sólo un temporizador por MIDlet. La aplicación debe tener un "TimerTask" para notificar a la aplicación los eventos del temporizador en tiempo. Si intentamos registrar un temporizador que ya está registrado el método devolverá el valor anterior de dicho temporizador, es decir, el instante para el que estaba programada la ejecución 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 tendrán el formato de una conexión genérica: protocolo, host y puerto .


  • registerConnection(String connection, String midlet, String filter): registra una conexión dinámica que una vez registrada funcionará igual que una conexión pre-alojada por el fichero descriptor. Los atributos son los mismos que en el Push Registration Atribute que se utiliza para registrar conexiones estáticas.


  • unregisterConnection(String connection): elimina del registro la una conexión dinámica, devolviendo el resultado de la operación.

    NOTA IMPORTANTE: Cuando se implemente un MIDlet que al terminar su ejecución registre una alarma para ser activado tras un cierto tiempo, dicho registro debe ser gestionado por un nuevo hilo de ejecución para evitar "dead lock". El motivo es que existe el riesgo de que la ejecución del MIDlet llegue a su fin sin que se haya podido llevar a cabo el proceso de registrar la alarma de activación.

    Ejemplo de MIDlet que registra una alarma para su activación pasado un tiempo determinado: EjemploPush.java
  • No hay comentarios.:

    Publicar un comentario