Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

La configuración CLDC

1,183 views

Published on

Se presentan las bases para la configuración en dispositivos móviles con limitaciones de potencia, memoria y visualización CLDC

Published in: Education
  • Be the first to comment

  • Be the first to like this

La configuración CLDC

  1. 1. 1 Programación de dispositivos móviles Semana 2 LA CONFIGURACIÓN CLDC Ya vimos de manera general la configuración CLDC, aquella en la que se monta el perfil MIDP para hacer los MIDlets. Sin embargo, debido a su uso, es necesario entenderla a profundidad la configuración, sus partes, su estructura y la diferencia que existe entre ellas y otras plataformas. De que se encarga exactamente la configuración CLCD. Esta configuración tiene varias funciones (que estudiaremos a fondo en esta sección), entre las cuales se destacan:  El lenguaje JAVA y las características particulares de la máquina virtual en la que se corre: Características que se han mantenido y aquellas que se han tenido que omitir en la configuración CLDC  Las librerías del Core de JAVA (Las librerías del Core de java son “Java.lang” y “java.util”): Que librerías han sido heredadas por la configuración CLDC y cuales son propias de la misma  Entrada y salida de información: Que entradas y qué salidas se han mantenido en la configuración.  Comunicaciones OTA: Soportes de protocolos de comunicación por la configuración.  Seguridad en el dispositivo: Modelo de seguridad proporcionado por la configuración CLDC  Internacionalización: Variación idiomática Veamos entonces cada uno de estos elementos a profundidad, junto con otros que definen la configuración CLDC.
  2. 2. 2 Programación de dispositivos móviles Semana 2 Objetivos de la configuración CLDC y requerimientos de la misma: JAVA es un lenguaje muy extenso. Puede manejar bases de datos, documentos, animaciones, simulaciones, redes empresariales e incluso dispositivos móviles. Debido a lo extenso de su repertorio, debemos restringir las características de funcionamiento del mismo. Esta restricción la hacemos a través de una configuración. La configuración CLDC determina un conjunto de características, que el lenguaje JAVA soporta, y que caracterizan un determinado conjunto de dispositivos. Restringe el trabajo en red, la seguridad del dispositivo, las APIs de programación, etc. Es como tener una masa para galletas, y usar un molde para hacer galletas de determinada forma. Todas las galletas que se puedan hacer con ese molde están caracterizadas por ser de la misma masa (JAVA), pero todas tienen la misma forma porque fueron cortadas con el mismo molde (Configuración). Este molde, esta forma, es la base para diversos perfiles. Un perfil define un conjunto más particular aún de características que hacen que el dispositivo se pueda dirigir a un mercado más especializado. Si bien existen muchos perfiles1 , el perfil que nos interesa precisamente es el MIDP, porque este es el que define las características de lo que es un dispositivo móvil de bajas prestaciones y alta movilidad. Es como si las galletas sacadas por el mismo molde, pudieran unas bañarse de chocolate, las otras de vainilla, las otras de azúcar… y cada una de esas cubiertas fuera un perfil. En términos JAVA, un celular puede verse como una galleta, en forma de bota, de chocolate; un blacberry como una galleta, en forma de bota, de vainilla; un PC es una galleta, en forma de círculo, con mora… etc. Teniendo esto mucho más claro, veamos los objetivos específicos de la configuración: 1 Estas configuraciones se pueden encontrar en el documento “Configurations and Profiles Architecture Specification, Java 2 Platform Micro Edition (J2ME), Sun Microsystems, Inc”
  3. 3. 3 Programación de dispositivos móviles Semana 2  Objetivos El objetivo principal de la configuración CLDC es, como se dijo ahora, servir como un modelo para un determinado tipo de componentes. En este caso particular, trata de definir un estándar para dispositivos de reducido tamaño conectados a una red y con recursos limitados. Pero decir “recursos limitados” es muy ambiguo. ¿Con respecto a qué? Se define un recurso como limitado cuando es 10 veces menor que los recursos de un computador de escritorio promedio. La configuración CLDC va más allá, definiendo un conjunto de características que debe tener el dispositivo. Estas características son las siguientes: o Entre 160 y 512 Kb de memoria total disponible para la localización de la plataforma JAVA o Procesador de datos de 16 o 32 bits o Bajo consumo energético, generalmente brindado por una batería. o Conectividad inalámbrica (recordemos que debe tener soporte OTA) con conexión intermitente, y ancho de banda (“tamaño” del canal de comunicación) rondando los 9600bps En este rango de dispositivos, entran PDAs sencillas, celulares de cantidad de generaciones, e incluso algunos GPS y Beepers. La configuración definida define entonces los elementos mínimos necesarios para dispositivos conectados pequeños. Si los dispositivos móviles usan herramientas de texto en pantalla, se implementan las librerías requeridas para eso. Sin embargo, los dispositivos móviles raras veces se usan para manejar bases de datos o nubes de información, por lo que estas librerías no se incorporan en la respectiva configuración. Sin embargo, aparte de definir un estándar, existen otros objetivos que se ven a continuación:
  4. 4. 4 Programación de dispositivos móviles Semana 2 Extensibilidad: Sabemos que nuestro dispositivo móvil tiene conectividad, y sabemos que posee una KVM montada, junto con una configuración CLDC. Esto permite que pueda bajar aplicaciones JAVA de la red y, a través de la AMS instalarlas. Una sola aplicación en la red, puede ser descargada por infinidad de dispositivos móviles. Estos dispositivos móviles se comunican entre sí, intercambiando aplicaciones y aumentando aún más la conectividad y el intercambio de información. Estas aplicaciones pueden venir de diversidad de partes, de empresas diversas, de operadores, incluso de usuarios, y empezaron a distribuirse y compartirse entre sí, aumentando el alcance y la utilidad de los dispositivos móviles. A esta característica la llamamos “extensibilidad”. JAVA, y sobre todo, CLDC hace parte entonces de los esfuerzos que se están llevando a cabo para aumentar la extensibilidad de los dispositivos móviles Desarrollo de terceras partes: Esto es una consecuencia de la extensibilidad. Si queremos que los dispositivos sean más extensibles, debemos darle a la configuración CLDC la posibilidad de que terceras partes puedan programar para él. Es por esta razón que la propia configuración debe permitir los elementos mínimos de alto nivel necesarios para crear una abstracción para los programadores. Con esto se intenta decir que el programador puede, y debe ser capaz de programar cualquier aplicación, y la configuración CLDC debe servir como un “traductor” entre sus aplicaciones y los protocolos internos de comunicación y transferencia de archivo.
  5. 5. 5 Programación de dispositivos móviles Semana 2  Requerimientos Existen unos requerimientos de hardware, de software y otros basados en la plataforma de JAVA J2ME, que son necesarios para la plataforma CLDC. Estos los veremos a continuación: o Requerimientos de hardware: Los requerimientos de hardware que pide la configuración se refieren únicamente a la memoria. Veamos que en el estándar que genera la configuración CLDC caben muchos dispositivos, desde celulares, hasta buscapersonas, pasando por PADs y organizadores personales, terminales, etc. Como todas las características de estos dispositivos móviles son muy diversas, la configuración solo restringe el hardware en cuestiones de memoria. Para ser más exactos, el requerimiento de memoria de estos dispositivos es el siguiente:  128 Kb para la máquina virtual y las librerías de JAVA  32 Kb de memoria volátil para variables usadas mientras se ejecutan las aplicaciones. Estos rangos de memoria son dinámicos, y dependen primordialmente del hardware del dispositivo. o Requerimientos de software: Como lo vimos ahora, los dispositivos móviles que entran en el perfil definido por la configuración CLDC son muy diversos, y tanto el hardware como el software varía enormemente. Es por esto que podemos encontrar dispositivos con un sistema operativo complejo y completo, que ejecute procesos multitarea y soporte hilos
  6. 6. 6 Programación de dispositivos móviles Semana 2 (Threats, o procesos en ejecución), así como podemos encontrar dispositivos con un rudimentario sistema operativo que no maneje carpetas, o incluso carentes del mismo. Es por eso que los requerimientos de software de la configuración CLDC son mínimos. Se requiere que el dispositivo tenga un sistema operativo rudimentario que permita ejecutar la máquina virtual de JAVA. Con que el sistema operativo tenga una entidad de planificación que permita ejecutar la máquina virtual, es suficiente. o Requerimientos de J2ME: Recordemos que CLDC es una configuración propia de J2ME. Esto significa que el propio JAVA genera unos requerimientos sobre las especificaciones de esta configuración, requerimientos que generan implicaciones sobre el perfil:  Cuando hablamos de una configuración J2ME, hablamos de un conjunto de APIs mínimas de la tecnología JAVA. Esta configuración debe cobijar una gran cantidad de dispositivos, de diferentes naturalezas, y a veces poco relacionados entre sí. Para definir características específicas de un dispositivo, de un mercado o de una industria, se debe hacer uso de un perfil, y no de una configuración. Esto hace entonces que un perfil sea limitado (servir a muchos dispositivos a veces equivale a no servir bien a ninguno de ellos), y que deba ser siempre complementado con perfiles.  En el apartado superior se indicó que el objetivo principal de la configuración CLDC era, aparte de definir un estándar, generar extensibilidad entre componentes. Esto significa que la configuración solo tiene los componentes
  7. 7. 7 Programación de dispositivos móviles Semana 2 necesarios para garantizar esta extensibilidad, y ningún otro elemento adicional. Esto hace que la característica principal de un dispositivo con configuración CLDC debe ser definida en los perfiles, y no en la propia configuración. DIFERENCIAS DE CLDC CON J2SE Si tenemos un dispositivo móvil con una maquina virtual montada y una configuración CLDC activa, nos interesa que esta combinación sea lo más compatible posible con cualquier especificación de JAVA que pueda presentarse (recordemos que no todos los componentes de JAVA se pueden ejecutar en todas sus versiones y en todas sus máquinas virtuales), teniendo en cuenta las restricciones de memoria anteriormente citadas. Esto significa que, como lo habíamos anotado anteriormente, existan diferencias entre CLDC y J2SE. Si la J2ME es un subconjunto de JAVA, con una librería adicional, significa que hay diferencias entre el lenguaje JAVA usado entre la J2SE y la configuración CLDC (por las APIs propias y exclusivas de J2ME usadas en CLDC), aparte de que algunos procesos escritos en JAVA, al ser limitada la configuración CLDC, no pueden ser ejecutados por esta configuración. La segunda diferencia fundamental es por la máquina virtual usada en J2SE y la usada para soportar la configuración CLDC. Profundicemos más estas diferencias para conocer los límites y los alcances de nuestra configuración. 1. No se soportan operaciones de punto flotante Una operación en punto flotante, como el aprendiz debe conocer, es una operación que permite ampliar el rango de valores operados usando varios bits adicionales en una representación numérica para guardar un exponente que eleva al número. Para estas operaciones, se requieren arreglos de
  8. 8. 8 Programación de dispositivos móviles Semana 2 memoria que permitan el uso de Bytes, Words y Longs (es decir, cadenas de 8, 16 y 32 bits definidas para un mismo carácter), pero la mayoría de dispositivos móviles no poseen el hardware necesario para ejecutar este tipo de operaciones (y de hecho, no las necesitan generalmente. Un celular en muy pocas situaciones tiene como proceso prioritario la multiplicación de 2 cadenas de 8 o 16 bits). Es por esto que se ha eliminado esta característica con respecto a su homóloga J2SE. 2. No se finalizan los objetos Cuando intentamos finalizar un objeto, usamos las librerías de la configuración CLDC. Estas librerías no contienen el método Object.finalize(), por lo que no podemos finalizar objetos a través de ella 3. Manejo de errores limitados Cuando se produce un error en JAVA, en vez de bloquearse o cerrarse (se produce un “core” o “crash”), esta lanza una excepción que nosotros debemos recibir para corregir el error. Si bien pueden ocurrir errores por una gran cantidad de posibilidades (solo miremos los errores que se producen en la instalación de un MIDlet), el conjunto de las clases de errores que se han incluido en la CLDC es limitado, por varias razones: a. Antes que nada, la configuración CLDC posee un subconjunto limitado de todas las excepciones de J2SE, lo cual reduce el manejo de estas drásticamente. b. Una de las clases de JAVA que maneja excepciones, la clase java.lang.error, y todas sus subclases, han sido eliminadas de la configuración CLDC.
  9. 9. 9 Programación de dispositivos móviles Semana 2 Estas limitaciones en el manejo de errores se dan gracias a que, cuando un dispositivo tiene instalado una máquina virtual y una configuración, no depende de ellas directamente para funcionar. Es decir, esta máquina y este perfil existen para poder ejecutar aplicaciones de JAVA, mas no para llevar a cabo procesos críticos del dispositivo. Esto hace que cada máquina tenga su propio manejo de errores, por lo que los errores de JAVA resultan redundantes. Además, generalmente un programador “agarra” excepciones, mas no errores, por lo que el uso de la clase java.lang.error no se ve necesario. Hemos visto las diferencias que existen, en el nivel de lenguaje de JAVA, entre la configuración CLDC y J2SE. Anteriormente habíamos dicho que las diferencias entre estos 2 elementos se daba por sus diferencias en el lenguaje JAVA y por diferencias entre las máquinas virtuales Ahora veremos las diferencias que existen entre las máquinas virtuales. Algunas características de la J2SE han sido eliminadas en la configuración JVM/CLDC, ya que las librerías que posee esta configuración son mucho más limitadas que las de su contraparte estándar. Y no solo por esto. Algunas de las características eliminadas entraban en un conflicto de seguridad con el modelo manejado por la configuración CLDC, generando problemas de seguridad. Para tener claras cuales han sido las características eliminadas de la configuración, procederemos a explicar cada una a continuación. 4. Java Native Interface (JNI) no implementada La JNI, para recordarle al aprendiz, es uno de los frameworks de java que permite interacción entre programas de JAVA y otros programas no escritos
  10. 10. 10 Programación de dispositivos móviles Semana 2 en este lenguaje. En la configuración CLDC, la JNI no ha sido implementada, y esto se ha producido por 2 razones fundamentales: o Primero, cuando la JNI “permite” la interacción entre programas, lo hace a través de “invocaciones” de métodos nativos, y los otros programas pueden invocar también a la JNI. Vemos entonces que estas invocaciones hacen uso de programas externos en caso de que sea necesario. Uno de esos programas puede, por ejemplo, ser usado para violar la seguridad del dispositivo, y el modelo de seguridad de la CLDC es limitado. Por tanto, para eliminar esa posibilidad, el modelo de seguridad no soporta la invocación de métodos nativos o La memoria de un dispositivo es muy limitada, por lo que la implementación de la JNI se considera muy costosa en término de recursos, para ser implementada en la misma. 5. Cargadores de clase definidos por el usuario, suprimidos. Una máquina virtual de JAVA que tenga implementada la configuración CLDC no permite que el usuario defina cargadores de clase. En vez de esto, implementa un cargador de clases que no puede ser ni suprimido, ni sustituido, ni reconfigurado por el usuario. Esto también se lleva a cabo porque el modelo de seguridad proporcionado por la configuración CLDC (modelo de seguridad tipo SandBox) genera esta restricción. 6. Reflexión no implementada: ¿Qué es la reflexión en JAVA? Imaginemos que pensamos sobre nuestra vida, todas las cosas que hemos vivido, aprendido, interiorizado, y las formas de actuar que hemos creado a lo largo de nuestra vida. En
  11. 11. 11 Programación de dispositivos móviles Semana 2 ese momento, estamos haciendo una reflexión sobre nuestra vida. De manera similar, JAVA reflexiona, mirando dentro de una máquina virtual la cantidad de clases, el tipo de clases, de objetos, campos, métodos, pilas, hilos… esta capacidad de inspección interna se ha eliminado de la máquina virtual que soporta CLDC 7. Grupos de hilos o hilos daemon. Un hilo se define, de manera básica, como un proceso en tiempo de ejecución. A estos hilos también se les llama “Threads”. Los dispositivos “multitareas” son aquellos que pueden soportar varios hilos al mismo tiempo. Sin embargo, cada hilo pertenece a un proceso diferente. La JVM de la configuración CLDC permite la ejecución multitareas, pero no soporta grupos de hilos (varios hilos de un mismo proceso). Tampoco se soportan hilos llamados “Daemon”. En el ámbito de programación, un “daemon” o demonio, es un proceso que se ejecuta sin interfaz gráfica que el usuario pueda observar y que lo hace sin el conocimiento del usuario. Un hilo daemon sería el equivalente a un proceso no visible, ejecutado en tiempo real. La máquina virtual de CLDC no permite la ejecución de hilos daemon. 8. Referencias débiles no implementadas La JVM/CLDC puede generar referencias a otros objetos. Algunas de estas referencias son prioritarias para el funcionamiento de un código. Otras de estas referencias pueden ser prescindibles, de manera que cuando se ejecuta el recolector de basura para liberar memoria, estas referencias pueden ser eliminadas2 . Para recordarle al aprendiz, un 2 Vease el paquete java.lang.ref
  12. 12. 12 Programación de dispositivos móviles Semana 2 recolector de basura es un proceso que permite llenar los huecos en la pila de memoria con procesos ejecutados en tiempo real, de manera que se recupera espacio. Digamos que la pila de memoria se llena con un conjunto determinado de procesos. Y digamos que mientras se ejecutan algunos procesos, otros desaparecen. La pila queda entonces de la siguiente manera: Vemos que los espacios en blanco son aquellos procesos que fueron liberados, pero que la pila se encuentra llena. El recolector de basura llena estos espacios, quedando la pila de esta manera:
  13. 13. 13 Programación de dispositivos móviles Semana 2 Es así como se libera espacio en la pila, a través del recolector de basura. SEGURIDAD EN CLDC Los dispositivos con configuración CLDC son extensibles, es decir, la extensión de sus alcances se aumenta gracias a las aplicaciones que se ejecutan en los mismos, combinado con la interactividad que hay entre dispositivos al comunicarse entre sí. Estos dispositivos móviles, como nos acompañan en todo momento, generalmente tienen información privada o confidencial. La unión de interacción con información privada, casi nunca resulta cómoda. Es por esto que se debe hacer gran énfasis en la seguridad de este tipo de dispositivos. También debemos pensar en la posibilidad de que, al transmitirse un MIDlet entre servidor y cliente, llegue íntegro y sin problemas en la transmisión, ya que no queremos un error en tiempo de ejecución que nos bloquee el equipo móvil, que nos sature la memoria, o que, en el peor de los casos, comprometa nuestra información. Es por esto que se debe tener especial cuidado en la integridad de las aplicaciones y los datos transmitidos. ¿Cuál es el modelo de seguridad usado en estos dispositivos? Es un modelo que no es nuevo, y que se usa en aplicaciones generales de JAVA (es decir, en applets). Este modelo de seguridad es llamado el “modelo SandBox” o el modelo de aislamiento de procesos. Se puede decir entonces que el modelo de seguridad de la configuración CLDC es similar al modelo usado por la J2SE para ejecutar applets. El modelo SandBox es un modelo que funciona como una “celda” o un “cuarto” que aísla un proceso determinado, y le permite ser ejecutado dentro de él. Cuando entramos a una página Web, y existe una aplicación JAVA, esta se encuentra enmarcada en un cuadro que la contiene. Dentro, la aplicación es
  14. 14. 14 Programación de dispositivos móviles Semana 2 funcional, pero fuera de la página, la aplicación de JAVA no puede moverse. Este marco aísla la aplicación, funciona como una “caja de arena” para niños. Este modelo entonces establece que solo se pueden llevar a cabo determinadas acciones que él considera seguras. Eso significa que las aplicaciones que se ejecutan dentro de la caja deben cumplir ciertas condiciones: - Cuando se ejecuta la aplicación, se verifica si los archivos de clase JAVA son aplicaciones válidas. - Solo las APIs autorizadas por la CLDC pueden ser ejecutadas en la SandBox. - La caja no permite cargar una clase que se haya definido por un usuario. - La aplicación activa dentro de la SandBox solo puede ejecutar características nativas internas del CLDC. - Cuando ejecutamos una aplicación bajo una KVM, esta puede apuntar a espacios de memoria que en un dispositivo móvil no existen. Este proceso puede acarrear problemas serios en nuestro dispositivo, por lo que se debe tener muy en cuenta esta característica. Para eso, el verificador de clases se asegura en todo momento de que no hayan referencias a posiciones no válidas de memoria. Este verificador de clases también se encarga de observar que las clases cargadas no se ejecuten de una manera no permitida por la configuración CLDC LIBRERÍAS CLDC La versatilidad de JAVA radica en la cantidad de librerías que incorpora, convirtiéndolo en una herramienta de muy amplia gama, pues estas librerías dan la capacidad de crear una gran cantidad de programas útiles para el ámbito empresarial y personal. Desafortunadamente, todas estas librerías requieren una gran cantidad de memoria (en comparación con la memoria de
  15. 15. 15 Programación de dispositivos móviles Semana 2 un dispositivo móvil), teniendo generalmente tamaños de varios megabytes. Si recordamos las capacidades de memoria de un dispositivo móvil que sea arropado por a configuración CLDC, veremos que la memoria que estos dispositivos manejan no sobrepasa generalmente los 500Kb (ni siquiera llega al medio megabyte), por lo que es prácticamente imposible montar las librerías estándar de J2SE y J2EE dentro de un dispositivo móvil. Acá veremos cuáles son los objetivos generales de diseño de una librería para CLDC, cuáles son sus objetivos generales, y que tipos de clases poseen dichas librerías.  Objetivos generales: ¿Cuál es el objetivo general del diseño de una librería JAVA para CLDC? Creo que en este curso no nos cansaremos de comentar la limitación de memoria que poseen los dispositivos móviles, y como dicha limitación impone restricciones en todos los componentes y aplicaciones creadas. Con estas limitaciones en la cabeza, creamos unas librerías completamente básicas y fundamentales, propias para una variedad de pequeños dispositivos. El objetivo de estas librerías es el de proporcionar un conjunto básico de herramientas para desarrollar aplicaciones y definir perfiles para estos pequeños dispositivos.  Compatibilidad: Nuestro objetivo principal entre la plataforma J2SE, J2EE y la JVM con la CLDC incluida, es garantizar la mayor compatibilidad posible entre aplicaciones. Esto hace que las librerías de la J2ME sean un subconjunto de las usadas en J2SE y J2EE. Por esta razón, muchas de las aplicaciones de J2ME pueden ser ejecutadas en J2EE y J2SE, y viceversa. Sin embargo, la memoria nos limita. Las librerías de las versiones estándar y empresarial de JAVA están muy interconectadas entre sí. Algunos
  16. 16. 16 Programación de dispositivos móviles Semana 2 elementos de las librerías dependen directamente de otras librerías, haciendo que en algunos casos, querer incluir una librería obliga a la inclusión de otras, y no nos podemos dar ese lujo. Sectores como la seguridad, las entradas y salidas de datos, las interfaces de usuario y el trabajo en red tienen bibliotecas fuertemente vinculadas entre sí. Esta vinculación hace muy difícil la capacidad de crear subconjuntos de librerías, lo que ha llevado al rediseño de algunas librerías para la configuración CLDC, especialmente en el área de trabajo en red y de entrada y salida de datos. Por esta razón, podemos dividir las librerías de CLDC en 2 categorías definidas: - Librerías como subconjunto de las presentes en J2SE (es decir, librerías heredadas) - Librerías específicas de CLDC Veamos cada una de ellas  Librerías heredadas CLDC posee una gran cantidad de clases heredadas de la plataforma J2SE. Para ser más específicos, hereda aproximadamente 37 clases pertenecientes a los paquetes java.lang, java.util y java.io. Esas clases heredadas tienen como característica ser idénticas o al menos es un subconjunto de la clase correspondiente en J2SE. Los métodos y la semántica trabajada en cada clase han permanecido idénticos para mantener la compatibilidad entre plataformas. Podemos observar las clases heredadas de J2SE en las siguientes tablas:
  17. 17. 17 Programación de dispositivos móviles Semana 2
  18. 18. 18 Programación de dispositivos móviles Semana 2  Librerías propias de CLDC Memoria, memoria, memoria… La falta de memoria en los dispositivos limita todos los procesos y aplicaciones de JAVA. En este punto, no es la excepción. En las tablas anteriores vimos que la plataforma J2SE heredó algunas de las clases de los paquetes java.io y java.net. Esos paquetes en la J2SE están encargados de las operaciones de entrada y salida de datos. Como se vio, no se pudieron heredar todas las clases, pero entre esas clases no heredó ninguna encargada de la transferencia de ficheros, entre otras. Esto se debe a que, como la aplicación CLDC maneja dispositivos que en su sistema operativo no tienen la noción de fichero, lo cual hace innecesario heredar esta característica. Otra de las clases no heredadas fue la de comunicaciones basadas en TCP/IP presentes en el paquete java.net, ya que no se puede asegurar que los dispositivos móviles usen este protocolo de comunicación para interactuar con la red. Para solucionar estos problemas, la plataforma J2ME tiene un conjunto de clases mucho más genérico, llamado “Generic Connection Framework”, incluído en el
  19. 19. 19 Programación de dispositivos móviles Semana 2 paquete javax.microedition.io. Estas clases se pueden observar en la siguiente tabla: El manejo de estas clases e interfaces es avanzado para un curso introductorio, por lo que deben ser estudiadas por el aprendiz en otros cursos.

×