Android vs Java

Diferencias con una máquina virtual Java normal

       En primer lugar, la máquina virtual de Dalvik (Android) toma los archivos generados por las clases Java y los combina en uno o más archivos ejecutables Dalvik (. dex), los cuales a su vez son comprimidos en un sólo fichero .apk (Android Package) en el dispositivo. De esta forma, reutiliza la información duplicada por múltiples archivos .class, reduciendo así la necesidad de espacio (sin comprimir) a la mitad de lo que ocuparía un archivo .jar. 

        En segundo lugar, Google ha mejorado la recolección de basura en la máquina virtual de Dalvik, pero ha preferido omitir just-in-time (JIT), en esta versión por lo menos. La empresa justifica esta elección diciendo que muchas de las bibliotecas centrales de Android, incluyendo las bibliotecas de gráficos, están implementadas en C y C++. Del mismo modo, Android proporciona una biblioteca de C optimizada para acceder a la base de datos SQLite, pero esta biblioteca está encapsulada en un nivel superior del API de Java. Dado que la mayoría del código del núcleo se encuentra en C y C++, Google argumentó que el impacto de la compilación JIT no sería significativo.

        Por último, la máquina virtual de Dalvik utiliza un tipo diferente de montaje para la generación del código, en el que se utilizan los registros como las unidades primarias de almacenamiento de datos en lugar de la pila. Hay que señalar que el código ejecutable final de Android, como resultado de la máquina virtual de Dalvik, no se basa en el bytecode de Java, sino que se basa en los archivos .dex. Esto significa que no se puede ejecutar directamente el Bytecode de Java, sino que hay que comenzar con los archivos .class de Java y luego convertirlos en archivos .dex.

 Formato de un fichero .dex

 Tras comenzar a estudiar las características de Android, pueden observarse algunos aspectos que, si bien no siempre resultan una ventaja frente a sus competidores, sí son interesantes y pueden repercutir positivamente en su elección como plataforma. Por ejemplo:

Diferencias de arquitectura y Librerias

   

 A pesar de que Google evita usar el término demasiado, el hecho de utilizar un lenguaje tan popular como Java ayuda a que cualquier programador mínimamente experimentado pueda comenzar a programar sus aplicaciones sin mayor complicación, además de animar a los que ya estén muy familiarizados. Incluye, además, las API más importantes de este lenguaje como java.util, java.io o java.net.

  La licencia Apache permite a todo el mundo poder estudiar, modificar y distribuir el sistema Android, a la vez que da opción al desarrollo privado mediante la publicación comercial de aplicaciones. Cada desarrollador puede decidir cómo quiere distribuir su propio trabajo.

Como ya es sabido, Android divide todas sus aplicaciones en componentes o bloques básicos que, combinados, constituyen el programa final. Así, tenemos bloques visibles para el usuario mediante interfaces (Activity), bloques que se ejecutan en background fuera de su conocimiento (Service), bloques a la escucha de determinados eventos (Broadcast Receiver) y bloques que ofrecen contenidos a otras aplicaciones (Content Providers). Esta filosofía es original y ayuda a modularizar funcionalmente las aplicaciones.

·         La delegación de acciones en otras aplicaciones mediante Intents es otro de los aspectos más innovadores ofrecidos por Android. Mediante un Intent, la aplicación simplemente expresa lo que desea hacer y es el sistema el encargado de buscar la aplicación más adecuada (para llamar, mandar un correo electrónico, abrir una página web, etc.). Así mismo, las aplicaciones pueden anunciar a las demás que están preparadas para poder atender determinados tipos de Intents.

·         La construcción de interfaces de usuario ha sido un aspecto muy cuidado, no sólo por la amplia colección de elementos y diseños incorporados, sino por la posibilidad de ser definidas tanto en el código fuente como mediante documentos XML externos.

·         El acceso a los recursos del dispositivo, como GPS, Wi-Fi, etc., se convierte en una tarea fácil y simple gracias a las API del SDK.

·         La declaración y uso de recursos externos, tales como imágenes, cadenas de texto, valores numéricos, o incluso diferentes modelos de interfaz de usuario y de diseños es cómoda y fácil de realizar.

En cuanto a las librerías estas son algunas diferencias:

·         APIS que controlan el ciclo de vida de la aplicación.

·            ANDROID: Principalmente se usan android.app.Activity y android.app.ListActivity. 

·           JAVA: Principalmente se usa javax.microedition.midlet.MIDLET.

·          APIS que definen la interfaz de usuario de la aplicación. 

  Alto Nivel

·              ANDROID: Principalmente se usan android.widget.ArrayAdapter y android.widget.ListAdapter 

·             JAVA: Esencialmente son javax.microedition.lcdui.Display yjavax.microedition.lcdui.Displayable

  Bajo Nivel

·              ANDROID: Principalmente se usan android.graphics.drawable.Drawable y android.view.View

·             JAVA: Esencialmente son javax.microedition.lcdui.game.GameCanvas y javax.microedition.lcdui.Displayable.Canvas

  

·          APIS media: Bluetooth, Multimedia y sensores.

  Bluetooth

·              ANDROID: Android ofrece la siguiente librería para usar esta interfaz, android.bluetooth.

·             JAVA: CLDC tiene un paquete opcional para usar Bluetooth (JSR 82): “Bluetooth API”.

  Multimedia

·              ANDROID: Ofrece la siguiente librería para reproducción de audio y vídeo, android.media: MediaPlayer.

·             JAVA: CLDC ofrece el paquete opcional “MMAPI” y un soporte básico en la API de MIDP 2.0: Manager, Playery Control en los paquetes javax.microedition.media y javax.microedition.media.control.

   Sensores y acelerómetro

·              ANDROID:Android proporciona la clase  android.hardware.SensorManager, la cual sirve  para  manejar el sensor de orientación, y el acelerómetro.

·              JAVA: CLDC tiene un paquete opcional para gestionar los sensores conectados al móvil (JSR 256): “Mobile Sensor API”.

·         Descriptores. 

·              ANDROID: AndroidManifest.xml

 Los componentes que necesita la aplicación se enumeran en un archivo llamado AndroidManifest.xml, el cual es un fichero XML donde se declaran los componentes y cuáles son sus capacidades y requerimientos. 

·              JAVA: Descriptor JAD

  Permite describir las propiedades de la aplicación y los componentes que forman parte de la misma. De esta manera, el AMS (Application Management System) podrá verificar si es posible instalar la aplicación antes de descargarla. Es un fichero de texto con extensión .jad.

  Arquitectura: Ciclo de vida de la aplicación

·          ANDROID: En Android existen 4 grandes bloques de construcción: Activity, Intent, Service y Content Provider, de los cuales, el bloque Activity es el componente más habitual de las aplicaciones para Android, es decir, un componente Activity refleja una determinada actividad llevada a cabo por una aplicación, y que lleva asociada típicamente una ventana o interfaz de usuario. Los cuatro posibles estados que definen su ciclo de vida son: Activa, pausada, parada y reiniciada. 

·         JAVA: La clase encargada del ciclo de vida de una aplicación, es la clase MIDlet, y los métodos que gestionan el ciclo de vida de una aplicación son tres: activa, pausada y destruida.

 Máquina Virtuales: KVM y CVM (Java ME) vs. Dalvik (Android)

·             ANDROID:La JVM que utiliza Android es la máquina virtual DalvikVM. En ella podemos encontrar una gran diferencia con respecto a la máquina virtual Java (JVM), ya que la máquina virtual de Google no está basada en una pila.

·             JAVA: En el perfil MIDP, la JVM es la máquina virtual KVM, la cual es la máquina virtual más pequeña desarrollada por Sun, y se usa con la configuración CLDC. Se trata de una implementación reducida y especialmente orientada a dispositivos con bajas capacidades computacionales y de memoria. 

 Herencia de interfaz ráfica de Java

·            ANDROID: Android hereda las siguientes librerías de Java: 

·           java.awt.font.* Para definir propiedades del estilo y tamaño de la letra. (Subconjunto de J2SE)

·           java.beans.*: Para definir beans con los métodos get y set.(Subconjunto de J2SE)

·           java.io.*: Conexión genérica.

·           java.lang.*  Clases de la VM. (Subconjunto de J2SE)

·           java.math.* Para operaciones matemáticas.

·           java.nio.*  Para definir buffers.

·           java.security.*  Clases para definir  el modelo de seguridad. (Subconjunto de J2SE)

·           java.sql.* API para usar JDBC y gestión de base de datos con SQL.

·           java.text.* Para definir diferentes formatos de texto.

·           java.util.* Clases para utilidades estándar. (Subconjunto de J2SE)

·           javax.crypto.* Clases para realizar operaciones criptográficas.

·           javax.microedition.khronos.* Clases orientadas a diseño de interfaces 3D.

·           javax.net.* Clases para aplicaciones de Red. (Subconjunto de J2SE)

·           javax.xml.* Para usar lenguaje XML en el Descriptor de la aplicación.

·           JAVA:  El perfil MIDP, hereda las siguientes librerías de Java:

·         java.io.* Clases y paquetes estándar de E/S. (Subconjunto de J2SE)

·         java.lang.* Clases e interfaces de la VM. (Subconjunto de J2SE)

·         java.util.* Clases, interfaces y utilidades estándar. (Subconjunto de J2SE)

  Mensajería instantánea: SIP(Java ME) vs. XMPP(Android)

·             ANDROID: Android ofrece una API para desarrollar protocolos de mensajería instantánea, concretamente                         XMPP (Extensible Messaging and Presence Protocol), protocolo de intercambio de mensajes basado en XML.

·             JAVA: Java ME con el perfil MIDP ofrece un paquete opcional para utilizar protocolos de mensajería instantánea, concretamente SIP (Session Initition Protocol).

Almacenamiento de Datos: RMS(Java ME) vs. SQLite(Android)

·              ANDROID: Android ofrece la superclase android.content.ContentProvider para el manejo y almacenamiento de datos, conocido también como “proveedor de contenido”. Este bloque de construcción, permite compartir datos entre procesos y aplicaciones.

 Además, Android soporta BBDD SQLite y proporciona funciones de control que permiten almacenar datos complejos en forma de objeto.

·             JAVA: MIDP ofrece la librería javax.microedition.rms para memoria persistente, lo cual consiste en una base de datos binaria sencilla (sin usar SQL) orientada a almacenes de registros (RecordStore).

 Navegador (Java ME) vs. WebKit (Android)

·            ANDROID: El SO Android dispone de un navegador integrado basado en el motor del proyecto abierto WebKit.

·            JAVA: CLDC ofrece la posibilidad de desarrollar clientes web con “Web Services APIs”.

 Portabilidad de Aplicaciones

·           ANDROID: En este ámbito, Java ME tiene una enorme ventaja sobre Android, ya que tiene una VM “totalmente Java”, mientras que la VMde Google (Dalvik), a pesar de sus grandes ventajas ya comentadas, hace que la migración de una aplicación open-source de Linux x86 sea realmente dura. Todos los interfaces de usuario y la lógica han de ser reescritos desde cero.

·           JAVA: La existencia de diferentes perfiles en Java ME consiguen garantizar la portabilidad de las aplicaciones, que utilizan un API no tan complejo y extenso como en el caso de Android, pero suficiente para que el código sea portable entre diferentes dispositivos móviles.

¿Puede ejecutarse un Proyecto Java ME en un móvil con ANDROID?

·         Claro que si, usando MicroEmu (Emulador de J2ME hecho en Java) o bien con el J2ME MIDP Runner.

Diferencias en aspectos de programación

·         ANDROID: Permite desarrollar aplicaciones en los siguientes entornos de programación:           Eclipse          Netbeans ·         JAVA: Permite desarrollar aplicaciones en los siguientes entornos de programación:          J2ME Wireless Toolkit 2.2         J2ME WTK 2.5         Java ME Platform SDK 3.0        Netbeans: Mobility Pack 4.1                  Eclipse: Plug-in EclipseME    Midlet(Java ME) vs. Activity(Android) ·         ANDROID:  En Android una pantalla (asociada a una interfaz de usuario) se corresponde  con la clase Activity, y para pasar de una pantalla a otra se utiliza la clase Intent de  la siguiente manera:                           Intent intentLista = new Intent();      intentLista.setClass(Clase1.this,Lista.class);//origen,destino                                      startActivity(intentList);//para pasar a la pantalla asociada a la clase Lista  ·         JAVA:  En MIDP para pasar de una pantalla otra se utiliza la clase Display de la siguiente manera:                                             this.midlet.getDisplay().setCurrent(this.midlet.getLista()); Donde el método getLista() devuelve un objeto del tipo List de la API de alto nivel  Además, se usa la clase Command para añadir un comando al Displayable y poder cambiar de una pantalla a otra, utilizando el siguiente método:                                     addComand(Command)   Modelo de seguridad ·         ANDROID: En Android se hace en el fichero AndroidManifest.xml. Por ejemplo, si  queremos acceder a la API de bajo nivel, ActivityManager, para obtener el número de procesos en ejecución, debemos añadir la siguiente línea al descriptor:  <uses-permission id="android.permission.GET_TASKS" android:name="GET_TASKS"/>  ·         JAVA:  CLDC sigue el modelo “sandbox” y MIDP 2.0  proporciona un modelo de seguridad a nivel de aplicaciónmediante firmas digitales que permiten determinar si una aplicación es  fiable o no asociada a un dominio de seguridad. Las políticas permiten especificar los permisos asignados a cada dominio.   Gestión de eventos (escuchadores) ·          ANDROID: Principalmente se usan android.view.View.OnClickListener  (para capturar el evento OnClick de cualquier elemento del Layout, por ejemplo un botón) y android.view.MenuItem.onMenuItemSelected (cuando se usa la tecla Menú para interactuar con el usuario, para capturar el evento OnClick de una de las opciones del menú). ·         JAVA: Sigue el modelo de manejo de eventos y escuchadores definidos en Java SE, así tenemos fuentes de eventos que mantiene escuchadores que están interesados en saber cuándo ocurre un evento y proporciona métodos que permite que los escuchadores se añadan a dicha lista. Así cuando la fuente genera un evento, se lo notifica al escuchador correspondiente para que procese el evento, ejecutando la acción programada. Además, con la API de bajo nivel se pueden programas eventos del teclado y puntero. Por ejemplo, en la clase javax.microedition.lcdui.game.GameCanvas se gestionan los eventos de teclado por polling utilizando el método getKeyStates().    Propiedades del sistema ·         ANDROID: Las propiedades del sistema se definen en el fichero AndroidManifest.xml, el cual describe la aplicación, los permisos necesarios, etc… Todos los proyectos Android tienen este archivo que, entre otras cosas, nos dará la posibilidad depedir los permisos que vayamos necesitando, y definirá la actividad inicial que se ejecutará.  ·         JAVA: Las propiedades del sistema se definen en el fichero descriptor de la aplicación (JAD) y se obtienen viajava.lang.System y javax.microedition.MIDlet, por ejemplo:                         System.getproperty(String key)    Uso de memoria ·         ANDROID: En este aspecto Android es el ganador ya que los terminales Android no imponen restricciones de memoria, debido a que cada aplicación Android corre su propio proceso, con su propia instancia de la VM Dalvik. Dalvik permite el uso eficiente de dichas instancias. Ejecuta ficheros en el formato .dex optimizado para el consumo mínimo de memoria.  ·         JAVA: Los sistemas J2ME tienen restricciones importantes de memoria para el almacenamiento y ejecución de aplicaciones, restricciones por debajo de 50K.   Uso de hilos (contextos) ·         ANDROID:  Ofrece el paquete java.util.concurrent, heredado de java, y android.os para mecanismos de sincronización de procesos, tareas, hilos y actividades.  ·            La principal diferencia entre las dos tecnologías es que Android ofrece un “entorno multitarea”, es decir, cada aplicaciónde Android corre en su propio proceso, el cual es creado por la aplicación cuando se ejecuta y permanece hasta que la aplicación deja de trabajar o el sistema necesita memoria para otras aplicaciones. Una característica fundamental de Android es que el ciclo de vida de una aplicación  no está controlado por la misma aplicación sino que lo determina el sistema a partir de una combinación de estados como pueden ser que aplicaciones están funcionando, que prioridad tienen para el usuario y cuanta memoria queda disponible en el sistema. De esta manera,  Android sitúa cada proceso en una jerarquía de "importancia", concretamente sigue el estándar POSIX, de modo que la política de eliminación de procesos esTRANSPARENTE para el programador, ya que la capa inferior de la plataforma está compuesta por un núcleo Linux (versión 2.6) que se usa como capa de abstracción de hardware (HAL, Hardware Abstraction Layer). Si el programador desea ver los procesos en ejecución a bajo nivel, la única posibilidad es usar la herramienta AIDL, la cual ofrece al programador la visualización de las llamadas del SO a los métodos IPC. ·         JAVA: Java ME, al igual que Android ofrece un entorno “multithreaded”, ya que permite realizar múltiples actividades simultáneamente, pero se diferencia en que el Planificador de hilos (el cambio de contexto) no lo puede controlar el programador sino que puede suceder en cualquier momento. Aún así, existen “trucos” para que el programador sea capaz de gestionar varios hilos dentro de una misma aplicación. Finalmente el proyecto de como seria un HELLO WORD en las dos tecnologias: Android: Java: