Mas de programación móvil.

Maquinas virtuales



Las máquina virtual Java tiene como función principal  interpretar código intermedio (bytecode) procedente de la pre-compilación a código ejecutable por la plataforma, permitiendo así efectuar llamadas al sistema operativo subyacente para que este evalué el código y establezca reglas de seguridad para que el lenguaje Java se ejecute. Esto proporciona al programa independencia a la plataforma con respecto al hardware y al sistema operativo del dispositivo, lo cual lo convierte en interoperable.
A diferencia de las ediciones de java J2SE y J2EE, J2ME utiliza una máquina virtual con capacidades reducidas debido de las características intrínsecas de los teléfonos celulares con el fin de realizar una implementación menos exigente. De acuerdo al tipo de configuración se utiliza una máquina virtual distinta. La Máquina Virtual de la Configuración CLDC se denomina KVM y la de la configuración CDC CVM.



KVM (Kilobytes Virtual Machine)



Es la máquina virtual más pequeña desarrollada por Sun, compacta y portable diseñada especialmente para un grupo de dispositivos pequeños con recursos restringidos. Su nombre hace referencia a la baja ocupación de memoria que utiliza. KVM es apropiado  para los microprocesadores de 16/32 bits RISC/CISC y con un total de memoria asignada de no más unos cientos de kilobytes (algunas veces menos de 128 kilobytes). KVM fue diseñada para ser:
       Pequeña, con una carga de memoria entre los 40kb y los 80kb, dependiendo de la plataforma y las opciones de compilación.
       Alta portabilidad.
       Modulable.
       La más completa y rápida posible y sin sacrificar características para la cual fue diseñada.




CVM (Compact Virtual Machine)



Máquina virtual para la configuración CDC. Orientados para dispositivos electrónicos con procesadores de 32 bits de gama alta y alrededor de 2 Mb de o ma de memoria RAM, con conexiones de red de forma intermitente o permanente a través de TCP/IP. Sus principales características son:
       Sistema de memoria avanzado.
       Tiempo de espera bajo el recolector de basura.
       Separación de la funcionalidad de la máquina virtual del sistema de memoria.
       Consta de un recolector de basura modularizado.
       Portabilidad.
       Sincronización rápida.
       Ejecución de clases a través de la implementación de memoria de solo lectura ROM.
       Soporte nativo de hilos.
       Las clases tiene baja ocupación de memoria.
       Socialización de objetos.



Configuraciones



En el entorno J2ME las configuraciones se refieren al conjunto de APIS que permiten el desarrollo de aplicaciones para un grupo de dispositivos. La configuración maneja característica básicas,  comunes a un grupo de dispositivos o mercado objetivo en cuanto a asignación de memoria y otras capacidades de hardware se refiere. El perfil hace uso o “hereda” una configuración particular. La configuraciones no permiten la definición de características adicionales ya que este tipo de características son manejadas por los perfiles.

Entre las características soportadas por las configuraciones, se especifica:

       Soporte para característica del lenguaje de programación java.
       Soporte para característica de la Máquina Virtual.
       Soporte para las librerías Java y APIs.




Actualmente están disponibles dos configuraciones en J2ME:

Configuración de Dispositivos con Conexión (CDC). Esta configuración está diseñada para los dispositivos con ciertas capacidades computacionales y de memoria soportando un entorno más completo para la máquina virtual Java con características similares J2SE, con limitaciones en el ambiente gráfico y memoria del dispositivo. La Máquina Virtual adaptada a esta configuración es la CVM. Esta configuración se enfoca a dispositivos con ciertas características:

       Memorial volátil de al menos 2 Mb o más, incluyendo RAM o ROM.
       Procesador de 32 bits.
       Conexión a algún tipo de red.
       Manejo de la funcionalidad completa de la Máquina Virtual de Java 2.




Estos rasgos pueden ser encontrados en dispositivos como decodificadores de televisión digital, televisores con internet y sistemas de navegación de automóviles.



Configuración de Dispositivos Limitados con Conexión (CLDC). 

Esta configuración es apropiada para para dispositivos provistos con conexión pero con limitaciones en cuanto a capacidad gráfica, de cómputo y memoria. Es el bloqueo básico en donde se soportan los perfiles de la gran mayoría de dispositivos que se apoyan en J2ME como plataforma de desarrollo.
La gran mayoría de estas restricciones está dada debido al uso que se hace de la KVM, necesaria para trabajar con CLDC.

Los dispositivos que hacen uso de esta configuración (en la versión 1.1) deben cumplir con las siguientes características.

1)      Al menos 192 Kb de memoria total disponible para la plataforma Java.
2)      Un procesador de 16 o 32 bits.
3)      Bajo poder de consumo, a menudo operan con suministro de energía limitado, a través de baterías.
4)      Conectividad a algún tipo de red, por lo general la inalámbrica, con conexión intermitente y con ancho de banda limitado.





Entre los requerimientos de hardware especificados para CLDC se encuentran:

       Al menos 16 kilobytes de memoria no volátil disponible para la máquina virtual y las librerías CLDC.
       Al menos 32 kilobytes de memoria volátil disponible para la ejecución de la máquina virtual.

La CLDC aporta las siguientes funcionalidades a los dispositivos:

   Un subconjunto del lenguaje Java y todas las restricciones de su Máquina Virtual (KVM).
       Un subconjunto de las bibliotecas Java del núcleo.
       Soporte para E/S básica.
       Soporte para acceso a redes.
       Seguridad.




Perfiles



Los perfiles definen de forma personalizada mediante APIs el manejo del ciclo de vida de una aplicación en un dispositivo móvil, interfaz de usuario, etc., extendiéndose de esta manera la configuración a través de la edición de clases, para un tipo específico de dispositivo.

Básicamente se considera importante el uso de las librerías de interfaz gráfico para la definición de un perfil. Por lo tanto el perfil define rasgos propios de un dispositivo mientras que la configuración hace lo mismo con un conjunto de ellos. Así que a la hora de construir una aplicación se tenga a disposición tanto las APIs del perfil como de la configuración.

Los perfiles al igual que la máquina virtual están predeterminados por la configuración que se pretende usar en el desarrollo de una aplicación J2ME.

Para la configuración CDC se definen se tienen los siguientes perfiles:

Foundation Profile: Orientada a dispositivos móviles que no tienen interfaz gráfica, como por ejemplo, decodificadores de televisión digital. Funciona como base para otros perfiles definidos para CDC. Excluye paquetes que hacen parte de la interfaz gráfica de J2SE, de tal manera que para poder implementar interfaz del usuario en forma gráfica sería necesario la implementación de otro perfil adicional.

Personal Profile: extiende al Foundation Profile proporcionando soporte completo para gráficos AWT, permitiendo el manejo de applets y con capacidades web. Este perfil redefine a PersonalJava como un perfil JEME.




Para la configuración CLDC los perfiles mas importantes son:

       PDA Profile: construido sobre CLDC y abarca PDAs (Asistentes digitales personales) de baja gama, con pantalla cuya resolución oscile entre los 20000 pixeles y puntero.

       Mobile Information Profile Device (MIDP - Perfil de Información de Dispositivo Movil): al igual que al perfil PDA este también está construido sobre CLDC y es el perfil central de esta configuración. Fue la primera configuración establecida para la plataforma J2ME. Este perfil maneja las siguientes características:

1)      capacidad computacional, gráfica y de memoria reducida.
2)      Ciclo de vida de la aplicación.
3)      Almacenamiento persistente.
4)      Conexión limitada.
5)      Entrada de datos alfanumérica.
6)      Transacciones punto a punto seguras (HTTPS).
7)      Temporizadores.




Paquetes Opcionales



Además de las característica que traen incorporados los perfiles y configuraciones, existe la necesidad de adicionar librerías de uso general que no están limitadas a una categoría o familia de dispositivos. Los paquetes opcionales J2ME son un conjunto de APIs estándar, que puedan ser usadas para extender un perfil y hacer uso tanto de tecnologías existentes como emergentes.

Paquetes opcionales más usados:

•  API de Mensajería inalámbrica (WMA, Wireles Messaging API) JSR 120: Define un conjunto de APIs que proporciona acceso independiente de la plataforma a través de recursos de comunicación inalámbricos, como el servicio de mensajería corta (SMS, Short Message Service).



•  API de Contenido Multimedia Móvil (MMAPI, Mobile Media API) JSR 135: Proporciona control de recursos multimedia (audio y video), archivos y gran variedad de tipos de datos multimedia basados en tiempos, a dispositivos con recursos limitados, al igual que el WMA este paquete puede ser incorporado en aplicaciones desarrolladas para las configuraciones CLDC y CDC.

•  Especificación de servicio web en J2ME(WSA, Web Services API) JSR 172: extiende el concepto de Servicios Web permitiendo que los dispositivos J2ME puedan ser consumidores de servicios Web a través de los modelos de programación provenientes de la plataforma estándar de servicios web.

•  API para Servicios de Seguridad y Certificación en J2ME JSR 177: este paquete opcional extiende las características de seguridad en la plataforma J2ME a través de uso de APIs que proporcionen servicios de seguridad, usados para la configuración CLDC.



•  API de Localización para J2ME JSR 135: especifica que permiten el desarrollo de aplicaciones basadas en localización para dispositivos J2ME. Su propósito es proporcionar una API que genere información acerca de la ubicación geográfica y orientación del dispositivo para las aplicaciones Java.  Permite el acceso a base de datos con mapas almacenados en la terminal móvil. Define interfaces estándar para trabajar con metodologías de posicionamiento como GPS. Utilizado por CLDC y CDC.

•  API para Graficas Móviles en 3D para J2ME JSR 184: usado bajo CLDC, permite la generación de gráficos tridimensionales a frecuencias de imagen interactiva con recursos limitados, También se incluye la gestión de escenas 3D, animaciones, mensajes animados, salvapantalla, etc.

•  API para Bluetooth JSR 82: paquete usado en CLDC y MIDP. Proporciona mecanismos estándar para la creación de aplicaciones Bluetooth de modo que puedan ser ejecutadas a través de esta tecnología.

•  Paquete opcional JDBC para CDC/Foundation Profile JSR 169.





MIDP 2.0



Mobile Information Device profile o MIDP (JSR 118) es una versión  de J2ME (Java 2 Micro Edition) integrada en el hardware de celulares relativamente modernos que permite el uso de programas java denominados MIDlets, tales como juegos, aplicaciones o todo tipo de software.
La versión más moderna es la 2.0 incompatible con la 1.0, ya que no se puede cambiar en el teléfono.

 Limitaciones de MIDP 1.0

•   No posee APIs de renderizado activo.
• No posee soporte para el acceso directo a los pixeles de las imágenes(RGB).
•   No posee soporte para un modelo en pantalla completa.
•   No posee soporte de audio.
•   Solo requiere soporte htttp.



Las APIs adicionales más comunes que podemos encontrar en Java ME son (descripciones en inglés):

•          Wireless Messaging API (WMA) (JSR 120)
•          Mobile Media API (MMAPI) (JSR 135)
•          FileConnection & PIM API (JSR 75)
•          Bluetooth API (JSR 82)
•          Security and Trust Services API (SATSA) (JSR 177)
•          Location API (JSR 179)
•          SIP API (JSR 180)
•          Mobile 3D Graphics API (JSR 184)
•          Wireless Messaging API 2.0 (JSR 205)
•          Content Handler API (JSR 211)
•          Scalable 2D Vector Graphics API (SVG API) (JSR 226)
•          Payment API (JSR 229)
•          Advanced Multimedia Supplements API (AMMS API) (JSR-234)
•          Mobile Internationalization API (JSR 238)
•          Contactless API (JSR 257)
•          Web Services API (JSR 172)
•          JDBC for CDC (JSR 169) (no está disponible en dispositivos MIDP)
•          Java Binding for the OpenGL ES API (JSR 239)
•          Mobile Sensor API (JSR 256)






Estructura de un Midlet.


Midlet es un programa en lenguaje de programación Java para dispositivos embedidos (se dedican a una sola actividad), más específicamente para la máquina virtual Java MicroEdition (Java ME). Generalmente son juegos y aplicaciones que corren en un teléfono móvil. Está desarrollada bajo la especificación MIDP (perfil para información de dispositivo móvil).

Requisitos
Requiere un dispositivo que implemente Java ME y MIDP para correr. Como otros programas desarrollados en Java, tienen la característica, "Escribir una vez, ejecutar en cualquier parte" ("Write once, run anywhere"). Para escribir se puede obtener Sun Java Wireless Toolkit o NetBeans con la extensión Mobility Pack. Para las distribución son necesarios dos archivos, archivo .jar conteniendo el bytecode del programa y un archivo .jad que describe los contenidos del archivo .jar




Un MIDlet tiene que cumplir los siguientes requisitos para poder correr en un teléfono móvil:

• La clase principal necesita ser una subclase de javax.microedition.midlet.MIDlet.
•      El MIDlet necesita ser empacado dentro de un archivo .jar.
•      El archivo .jar necesita ser preverificado usando un preverificador.
•      En algunos casos, el archivo .jar necesita ser firmado digitalmente por un proveedor de teléfonos móviles.
•    Al crear una aplicación midlet 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.



Una vez entendidos los conceptos del gestor de aplicaciones y ciclo de vida podemos ver el aspecto que tiene un MIDlet real.

Los MIDlet tienen la siguiente estructura:

import javax.microedition.midlet.*;
public class MiMidlet extends MIDlet {
public MiMidlet() {
 /* Éste es el constructor de clase.
 Aquí debemos inicializar nuestras variables. */
}
 public startApp(){
 /* Aquí incluiremos el código que queremos que el MIDlet ejecute cuándo se active. */
 }
 public pauseApp(){
 /* Aquí incluiremos el código que queremos que el MIDlet ejecute cuándo entre en el estado de pausa (Opcional). */
}
public destroyApp(){
 /* Aquí incluiremos el código que queremos que el MIDlet ejecute cuándo sea destruido. Normalmente aquí se liberaran los recursos ocupados por el MIDlet como memoria, etc. (Opcional) */ }
}




Ciclo de vida de un Midlet.


El ciclo de vida de un midlet se compone de lo siguientes estados: PausadoActivo o Destruido. Sólo puede estar en un estado a la vez. La figura 1 muestra cómo se pasa de uno a otro:

Cuando un midlet ser carga en memoria, inicialmente pasa al estado Pausado, entonces se realiza la inicialización de la clase (método startApp(), que luego veremos). Si el Midlet lanza una excepción durante la ejecución de su constructor, se destruye. El midlet puede pasar de Activo a Pausado, cuando, por ejemplo, recibimos una llamada en nuestro móvil; es el sistema quien pasa nuestro Midlet de Activo a Pausado y viceversa. Un Midlet puede ser lanzado y parado todas las veces que queramos, pero sólo puede ser destruido una vez.




Gestor de aplicaciones.



El gestor de aplicaciones o AMS (Application Management System) es el software encargado de gestionar los MIDlets . Este software reside en el dispositivo y es el que permite ejecutar, pausar o destruir aplicaciones J2ME.
El AMS realiza dos grandes funciones:

•   Por un lado gestiona el ciclo de vida de los MIDlets.
•   Por otro, es el encargado de controlar los estados por los que pasa el
MIDlet mientras está en ejecución.


















Comentarios

Entradas populares de este blog

Relación de tablas en SQL Server de forma grafica

Uso de la clase "Choice group"

Imagenes dinamicas en Crystal Reports