Pasando a Android desde J2ME

Procedentes de la progtwigción de J2ME , existen similitudes que facilitarían la adaptación a la Android API . O es Android API completamente diferente de la forma J2ME de progtwigción de aplicaciones móviles.

En realidad, la API de Android es mucho más poderosa que la J2ME.

Es mucho más fácil crear una aplicación para Android.

El uso de J2ME te limita a formas simples debido a la ausencia de bibliotecas tipo swing (aunque ahora existe una biblioteca llamada LWUIT, que evita la necesidad de recrear desde cero una biblioteca similar a un swing).

En Android podrá crear formularios complejos muy rápidamente, y el paquete de software para el SDK de Android es fácil de instalar (mientras que en J2ME debe instalar el kit de herramientas de desarrollo inalámbrico de sun o instalar uno de Nokia, Samsung o SonyEricsson). se pone un poco confuso a veces).

Las cosas que tuve que cambiar cuando cambié de j2me a android fueron:

1 / La clase de fuente y gráficos es más fácil de usar en j2me. La API es más completa en Android, pero también más complicada.

2 / Si está acostumbrado al almacenamiento de la base de datos de j2me (RecordStore), puede olvidarlo en Android. Tendrá que usar una base de datos similar a SQL, así que prepárese para repensar su modelo de datos.

También he descubierto que la ruta de Java ME a Android es bastante simple. Aquí hay algunas cosas que he notado:

  1. Hay ONE ui draw thread en Android. postInvalidate tener en cuenta la diferencia entre llamar a postInvalidate e invalidate en Views para obligarlos a actualizar.

  2. La manipulación gráfica bit a bit es muy similar. Pude portar grandes cantidades de código de sorteo J2ME personalizado escribiendo algunos calces para drawRect y drawImage .

  3. La biblioteca de IU de Android es mucho más extensa, mucho menos inútil y mucho más complicada que las ME de Java.

  4. En sentido inverso, debes tener mucho más cuidado con la seguridad de los hilos con Android. En Java ME puede salirse con la suya haciendo que los métodos no sean síncronos o las variables sean volátiles la mayor parte del tiempo. No es así en Android.

Diré, en general, que la biblioteca de UI de Android no pasa una prueba crítica. Yo llamo a esto la prueba “roll my own”.

Su biblioteca de IU falla esta prueba si me lleva más tiempo completar una tarea de tarea detallada (por ejemplo, cambiar el fondo en un elemento de menú individual) de lo que me tomaría escribir mi propio Menú desde cero. Android no supera la prueba de “rodar tu propio” por un factor de 3 o 4. De hecho, si miras, la mayoría de las preguntas en este sitio web son “¿Cómo hago para que el kit de herramientas de interfaz de usuario de Android haga mi oferta?” preguntas

Android es una plataforma increíble y ha valido la pena cada momento frustrante en el que me he hundido. Sin embargo, es una plataforma joven y necesita un trabajo serio en el futuro.

Un buen comienzo sería mirar los videos de la architecture de Android y ver algunos de los documentos.

http://www.youtube.com/view_play_list?p=586D322B5E2764CF http://code.google.com/android/what-is-android.html

Google es muy bueno documentando. Por lo que he escuchado, Android es muy similar a J2ME en sus objectives. Puede ser ligeramente diferente en cuanto a la estructura y el estilo de progtwigción, pero si tienes experiencia en J2ME, deberías estar más que listo para pasar a Android.

¡¡¡Buena suerte!!!

Bueno, puede que en realidad no necesites adaptarte.

Hay muchas posibilidades de que una stack J2ME esté disponible para Android en poco tiempo, ya que se supone que Android no se volverá tan restrictivo con los tiempos de ejecución de terceros como el iPhone.

Conozco a un tipo que ha estado trabajando en eso: http://justanapplication.wordpress.com/

Ahora, por supuesto, eso no significa que no deba echar un vistazo a las API de Android y al ciclo de vida de la aplicación.