Pregunta

Recientemente comencé a desarrollar un prototipo de aplicación J2ME. Me di cuenta de lo difícil que es desarrollar una interfaz de usuario atractiva. Considere desarrollar una aplicación en J2ME para reservar vuelos que interactúen con el servicio web.

Un sitio web para reservar vuelos será fácil de desarrollar con una buena interfaz de usuario y se puede acceder a él mediante el navegador en un teléfono. Entiendo que no todos los teléfonos tienen navegador, pero todos los nuevos y futuros tienen navegador y también tienen pantalla grande.

¿Es una buena idea desarrollar una aplicación de este tipo en j2me que necesita hablar con el servicio web para que funcione? ¿O j2me solo es adecuado para aplicaciones independientes?

¿Fue útil?

Solución

Ventajas de J2ME:

  • Puede acceder a los recursos del teléfono, como el sistema de archivos, la guía telefónica y el GPS. Lo último es muy importante en las aplicaciones de mapas.
  • Puede construir interfaces de usuario más ricas. Puede ser difícil como dices, pero hay muchas bibliotecas GUI que pueden ayudarte. Por el contrario, la interfaz de usuario para un navegador móvil (no puede confiar en que CSS y JavaScript funcionen) sería muy pobre.
  • Mayor flexibilidad en la lógica de comunicación. Puede cifrar / descifrar datos, comprimirlos, usar servicios web SOAP. Con el navegador, su mejor opción sería desarrollar servicios REST.

Desventajas de J2ME:

  • Midlets deben ser firmados. Esto tiene algún costo y hay situaciones en las que incluso una aplicación firmada no se ejecutará correctamente en teléfonos específicos.
  • Desarrollar una midlet para ejecutar en todo tipo de teléfonos es una pesadilla. Por el contrario, una aplicación web móvil bien diseñada se mostraría correctamente en todos los teléfonos recientes.
  • Necesita tener un canal para distribuir su aplicación. La gente necesitaría descargarlo y cobrar por el ancho de banda requerido. Debería cuidar a los clientes enojados que tienen problemas con la aplicación. Las cosas son más fáciles con un sitio web.
  • Las aplicaciones J2ME se comparan inevitablemente con las aplicaciones nativas (iPhone, Windows Mobile, Symbian). En comparación con estos, son muy pobres y muchos encontrarían que pagar por ellos o incluso usarlos no está justificado.

Mi conclusión: hoy en día los teléfonos inteligentes reales se están volviendo más populares y ganan una cuota de mercado cada vez mayor. En estas circunstancias, las ventajas de J2ME realmente no pueden superar sus restricciones. La única excepción que se me ocurre es tener que desarrollar una aplicación de GPS. Para todos los demás casos, un sitio web móvil es una mejor idea.

Otros consejos

Hay muchos malentendidos y afirmaciones erróneas en las respuestas anteriores.

Te aconsejo que solo hagas tu investigación. Hoy en día, PUEDE desarrollar aplicaciones realmente atractivas con J2ME sin escribir su propio marco GUI. Echa un vistazo a LWUIT realmente. Por ejemplo, tienen un teclado virtual como una de sus funcionalidades de pantalla táctil y esto lo tienes en dispositivos como el N97, que en sí mismo no tiene un teclado virtual. Por cierto, usando LWUIT tienes un puerto Blackberry y Android incluido si a alguien le importa.

También las aplicaciones hoy en día se convierten en el centro de atención en muchas plataformas, no solo en el iPhone. Mire los desarrollos recientes en esta área como OVI, RIM, Samsung, SE, Orange World, todos comienzan con tiendas de aplicaciones.

" Hacer que las personas utilicen un sitio web en su teléfono móvil es más fácil que hacer que descarguen una aplicación. " esto es solo un reclamo sin prueba. No puedes decir eso así. Depende de muchos otros factores. - ¿Por qué los usuarios deben escribir su URL móvil en la pantalla bastante pequeña nuevamente?

De todos modos, esta respuesta es probablemente demasiado tarde, así que no voy a escribir mucho más. La industria móvil está cambiando rápidamente en este momento, pero aún no existe una alternativa a J2ME para el desarrollo de plataformas cruzadas. Quizás en el futuro con mejores navegadores y tecnologías de widgets.

Solo una breve nota, las aplicaciones como google maps o gmail mobile probablemente no usen WebServices para comunicarse con su servidor. Un servicio web tiene muchos gastos generales, especialmente cuando se considera que los usuarios de dispositivos móviles generalmente son calificados por la cantidad de datos que transmiten. La mejor manera de realizar la comunicación entre su aplicación cliente y su parte del servidor es usar datos binarios a través de una conexión de socket.

Personalmente, creo que es realmente difícil crear una aplicación J2ME consistente y confiable que se ejecute en un gran conjunto de teléfonos móviles. Según mi experiencia, solo desarrollaría una aplicación J2ME (en lugar de una aplicación web) si es un requisito estricto, por ejemplo, para poder ver sus reservas sin estar conectado a la red. Hay otros costos asociados con las aplicaciones J2ME: las aplicaciones deben descargarse, se le preguntará al usuario si la aplicación puede conectarse a la red cuando lo intenta (hay excepciones para este caso, pero creo que la aplicación debe estar firmada por una empresa de terceros: más $$$ involucrado), tendrá que mantener diferentes versiones de la aplicación ejecutándose en una variedad de teléfonos móviles (más complejidad para la aplicación), y así sucesivamente ...

Piénselo de esta manera: si estuviera desarrollando algo similar para una computadora, ¿crearía una aplicación de escritorio o una aplicación web? Con los teléfonos celulares de hoy (muchos de los cuales pueden acceder a sitios html completos con javascript, lo que significa ajax), la propuesta de la pregunta es válida.

Creo que una buena regla general debería ser: Si lo que está tratando de lograr se puede hacer con un sitio web móvil, vaya al sitio web.

En mi humilde opinión, las aplicaciones solo deben usarse si no pueden aprovechar el hardware móvil, como ubicación, sonido, video, 3d, imágenes, etc. ...

Incluso si los costos de desarrollo de la aplicación fueran insignificantes (por lo general, no lo son), tendrías que ofrecer algunas capacidades realmente sorprendentes para que los usuarios tengan la molestia de descargarla.

(Todo esto es esencialmente cierto para J2ME / BREW. El iPhone es un poco diferente ya que las aplicaciones toman el centro del escenario)

Una cosa que vale la pena destacar: la única forma estándar de implementar un MIDlet es a través de la descarga OTA, por lo que no esperaría que un teléfono con capacidad J2ME no tenga un navegador web.

El navegador web móvil como Webkit y Opera están mejorando más rápido que J2ME (al menos hasta que MIDP3.0 comience a enviarse, si es que lo hace).

No importa la plataforma que elija, deberá probar su servicio en muchos dispositivos. No creo que cambiar de J2ME a webapp haga una gran diferencia en ese sentido, porque los fabricantes de teléfonos siguen cambiando los binarios que entran en los firmwares de los teléfonos.

Hacer que la gente use un sitio web en su teléfono móvil es más fácil que hacer que descarguen una aplicación. a menos que esa aplicación ya esté instalada cuando compran el teléfono, eso es.

Es posible que desee ver LWUIT para una GUI J2ME mejor y más fácil.

Una cosa que J2ME logrará para un servicio de reserva de vuelos es ahorrar batería al no requerir la transferencia constante de datos de la red, gracias a los mecanismos de almacenamiento local.

hay muchas aplicaciones geniales de j2me que (necesitan) hablar con servicios web. solo piense en las aplicaciones de google, como gmail mobile y maps for mobile. son más rápidos y fáciles de usar que usar los servicios a través del navegador del teléfono celular. así que si puedes diseñar una buena aplicación, definitivamente vale la pena.

EDITAR: también, una aplicación j2me hace posibles funciones que una aplicación web no puede proporcionar: integración con las funciones del teléfono (libreta de direcciones, calendario), " llame a este número " ;, ubicación api, etc.

Creo que para aplicaciones de negocios, o más cosas orientadas a texto / datos, un sitio web / wap móvil podría ser más fácil de mantener, ya que no tendrá que lidiar con enviar actualizaciones de clientes a los teléfonos.

Para las aplicaciones intensivas en UI (mapas, juegos, etc.), las aplicaciones cliente son probablemente el camino a seguir, por lo que puede manejar la mayor parte del procesamiento y la representación en el lado del cliente.

Ambas opciones son difíciles, ya que hay muchos problemas de compatibilidad con los teléfonos. Es posible que le sirva mejor al reducir los tipos de teléfonos que desea admitir para su aplicación. Si cree que la mayoría de sus clientes serán teléfonos iPhone o Android, puede apuntar a esas plataformas (con aplicaciones de cliente o aplicaciones web) y evitar completamente el j2me de la vieja escuela.

Odio las aplicaciones web en los teléfonos. Son lentos y no funcionan en un entorno semi-conectado.

Las aplicaciones J2ME pueden hacer copias de seguridad locales, copias de seguridad de bluetooth, compartir datos de bluetooth entre 2 teléfonos y una interfaz de usuario con mejor respuesta. Sin embargo, eso requiere dinero, habilidad, tiempo, etc.

Sin embargo, mi principal problema con MIDP es impulsar actualizaciones de software y mezclas en tiempo real. Técnicamente, eso es posible dentro del alcance de MIDP, pero los matones al volante no son muy creativos.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top