tutorial español developer app iphone android html mobile-website

iphone - español - phonegap ios



Comparación entre Corona, Phonegap, Titanio (14)

Soy un desarrollador web y quiero mover mis productos web al iPhone. Uno de los productos es como Google Maps: mostrar mapa en la pantalla del teléfono, puede arrastrar o cambiar el tamaño del mapa y ver la información que agregamos al mapa.

Sé que hay algunas tecnologías que te permiten usar HTML, CSS y Javascript para desarrollar aplicaciones nativas para iPhone. He identificado algunos:

¿Hay otros productos similares? Cuáles son las diferencias entre ellos? ¿Cual deberia elegir?

De las soluciones que mencionó, ninguna de ellas parece darle acceso directo al marco MapKit introducido en OS 3.0.

Como los widgets HTML de Google Maps no son tan buenos como MapKit (vea Google Latitude para ver un ejemplo), es probable que sea mejor desarrollar una aplicación nativa Cocoa Touch o elegir una solución que pueda extender para agregar la integración de MapKit. PhoneGap es extensible de esta manera (es de código abierto, por lo que es de manera predeterminada), y algunas de las otras soluciones podrían serlo también.

Edición: Titanium ahora tiene soporte para MapKit

De lo que he reunido, aquí hay algunas diferencias entre los dos:

  • PhoneGap básicamente genera envoltorios nativos para lo que aún son aplicaciones web . Escupe un proyecto WhateverYourPlatformIs, lo creas y lo implementas. Si estamos hablando del iPhone (que es donde paso mi tiempo), no parece muy diferente a crear un lanzador de aplicaciones web (un acceso directo que tiene su propio icono de Springboard, por lo que puede iniciarlo como ). una aplicación nativa). La "aplicación" en sí misma sigue siendo html / js / etc., Y se ejecuta dentro de un control del navegador alojado. Lo que PhoneGap proporciona más allá de eso es un puente entre JavaScript y las API de dispositivos nativos. Por lo tanto, escribe JavaScript en las API de PhoneGap, y luego PhoneGap realiza la correspondiente llamada nativa correspondiente. En ese sentido, es diferente de implementar una aplicación web antigua y sencilla.

  • La fuente de titanio se compila a bits nativos. Es decir, su html / js / etc. no se adjuntan simplemente a un proyecto y luego se alojan dentro del control de un navegador web: se convierten en aplicaciones nativas. Eso significa, por ejemplo, que la interfaz de su aplicación estará compuesta de componentes de IU nativos . Hay formas de obtener una apariencia nativa sin tener una aplicación nativa, pero ... bueno ... qué pesadilla que suele ser.

Los dos son similares en cuanto a que escribes todas tus cosas utilizando tecnologías web típicas (html / js / css / blah blah blah), y que obtienes acceso a la funcionalidad nativa a través de las API de JavaScript personalizadas.

Pero, nuevamente, las aplicaciones de PhoneGap (¿PhonGapps? No lo sé ... ¿es un nombre estúpido? Es más fácil decirlo, lo sé) comienzan sus vidas como aplicaciones web y terminan sus vidas como aplicaciones web. En el iPhone, su html / js / etc. simplemente se ejecuta dentro de un control UIWebView, y las API de JavaScript de PhoneGap que sus llamadas js se enrutan a las API nativas.

Las aplicaciones de Titanium se convierten en aplicaciones nativas, simplemente se desarrollan utilizando tecnología web dev.

¿Qué significa esto realmente?

  1. Una aplicación Titanium se verá como una aplicación "real" porque, en última instancia, es una aplicación "real".

  2. Una aplicación de PhoneGap se verá como una aplicación web alojada en un control de navegador porque, en última instancia, es una aplicación web que se hospeda en un control de navegador.

¿Cuál es el adecuado para usted?

  • Si quieres escribir aplicaciones nativas con habilidades de desarrollo web, Titanium es tu mejor opción.

  • Si desea escribir una aplicación con habilidades de desarrollo web que pueda implementar de manera realista en múltiples plataformas (iPhone, Android, Blackberry y cualquier otra cosa que decidan incluir), y si desea acceder a un subconjunto de funciones de la plataforma nativa (GPS, acelerómetro, etc.) a través de una API de JavaScript unificada, PhoneGap es probablemente lo que desea.

Es posible que se esté preguntando: ¿Por qué querría escribir un PhoneGapp (he decidido usar el nombre) en lugar de una aplicación web que está alojada en la web? ¿No puedo seguir accediendo a algunas características nativas de dispositivos de esa manera, pero también tengo la comodidad de una verdadera implementación web en lugar de obligar al usuario a descargar mi aplicación "nativa" e instalarla?

La respuesta es: porque puede enviar su PhoneGapp a la App Store y cobrarlo. También obtienes el ícono del iniciador, lo que dificulta que el usuario olvide tu aplicación (es mucho más probable que olvide un marcador que un ícono de la aplicación).

Sin duda, podría cobrar por el acceso a su aplicación web alojada en la web, pero ¿cuántas personas realmente van a pasar por el proceso para hacerlo? Con la App Store, elijo una aplicación, toco el botón "Comprar", ingrese una contraseña y listo. Se instala. Segundos después, lo estoy usando. Si tuviera que usar la interfaz de transacción web móvil única de otra persona, lo que probablemente significa tener que tocar mi nombre, dirección, número de teléfono, número de CC y otras cosas que no quiero aprovechar, es casi seguro que no lo haría. t pasar por ello. Además, confío en Apple. Confío en que Steve Jobs no registrará mi información y luego cargará un montón de suscripciones de revistas traviesas a mi CC para las patadas.

De todos modos, excepto por el hecho de que Web Dev Tech está involucrado, PhoneGap y Titanium son muy diferentes, al punto de ser solo superficialmente comparables.

Odio las aplicaciones web, por cierto, y si lees las reseñas de la tienda de aplicaciones de iTunes, los usuarios son muy buenos para detectarlas. No nombraré ningún nombre, pero tengo un par de "aplicaciones" en mi teléfono que se ven y funcionan como basura, y es porque son aplicaciones web que están alojadas dentro de las instancias de UIWebView. Si quisiera usar una aplicación web, abriría Safari y, ya sabes, navegaría a una. Compré un iPhone porque quiero cosas que son iPhone-y. No tengo ningún problema en utilizar, digamos, una aplicación web de Google elegante dentro de Safari, pero me sentiría engañado si Google simplemente coloco un marcador en Springboard presentando una aplicación web como nativa.

Debo irme ahora. Mi novia tiene esa cara de "puede, por favor, deja de usar esa computadora" durante tres segundos.

Debes aprender objetivo c y programar aplicaciones nativas. No confíe en estas cosas que cree que harán la vida más fácil. Apple se ha asegurado de que la forma más sencilla sea usar sus herramientas y lenguaje nativos. Para tus 100 líneas de javascript, puedo hacer lo mismo en 3 líneas de código o sin código en absoluto, dependiendo del elemento. Mire algunos tutoriales: si entiende javascript, el objetivo c no es difícil. Las soluciones son miserables y Apple puede desconectar cuando lo deseen.

El Corona SDK (Ansca Mobile) utiliza Lua como su lenguaje de codificación. Ver lua.org para más información sobre Lua.

Si bien planeamos agregar una mayor integración web y elementos nativos de la interfaz de usuario, nuestro enfoque tenderá a ser aplicaciones de gráficos intensivos, como el desarrollo de juegos, en lugar de tecnologías basadas en la web. En otras palabras, no imaginamos que las personas escriban aplicaciones Corona completamente en Javascript / HTML / CSS.

Estoy tomando un curso sobre desarrollo de Android / iPhone y pasamos 8 semanas con Titanium (no a tiempo completo) (la versión era Titanium 1.4.2 y el tiempo fue alrededor de noviembre de 2010). Aquí está mi experiencia.

iPhone dual targeting

Aunque las guías API afirman que la funcionalidad está disponible tanto para Android como para iPhone, este no es el caso. Muchas de las cosas simplemente no funcionan en una de las plataformas. Algunas cosas funcionan de manera diferente.

Muchas de las personas en la clase han hecho aplicaciones de iPhone, y no pueden hacer que funcionen en Android sin reescrituras importantes. Desarrollé una aplicación infantil simple llamada Animap (vea Android market / Appstore en Suecia) y comencé a desarrollar bajo Windows. Una vez que el objetivo de Android funcionaba, abrí el proyecto en OS X. No muestra ningún elemento de compilación para iPhone, solo para Android. Debe iniciar un proyecto de doble destino en OS X. (Ok, copié los archivos relevantes a un nuevo proyecto). Problema siguiente: las animaciones no funcionan en iPhone (funcionan en Android). Los eventos de desplazamiento no funcionan igual en el iPhone. (es decir, en Android se obtiene el evento intacto cuando el usuario detiene el desplazamiento y suelta su dedo de la pantalla, esto no sucede en el iPhone).

Dado que esto no se menciona en algún lugar, básicamente necesita realizar una programación de prueba y error en la primera plataforma, luego en la otra. Por prueba y error quiero decir que tomará aproximadamente dos días para que una aplicación tan simple como Animap funcione en la otra plataforma. También necesitarás tener if (android) entonces ... o if (iphone) ... en todo tu código ...

Descargar y configurar

Debes seguir las instrucciones de la carta. No intente utilizar java de 64 bits. No compilará la aplicación de demostración KitchenSink 1.4.0. (¡1.3 funciona bien!) Debe colocar los archivos directamente en la unidad C, ya que las rutas de acceso largas harán que el programa externo no reciba todos los parámetros de la línea de comandos si se alargan. (Aunque está bien para programas pequeños) 1/3 de las veces, la cadena de herramientas simplemente se detiene y debe presionar ''iniciar'' nuevamente. Entonces probablemente funcionará ... muy poco confiable. El simulador no se encontrará en el inicio y, luego, simplemente debe eliminar adb.exe con Ctrl + Alt + Supr y volver a intentarlo.

Conexión de red

En una red wifi, a veces se pierde la conexión en vivo y Titanium se bloquea en usted (la interfaz de compilación / despliegue) Si no tiene una conexión a Internet que funcione, no se iniciará, ya que no puede iniciar sesión en sus servidores.

API

CSS, HTML y jQuery es una brisa en comparación con esto. Titanium se parece a cualquier otra API de GUI antigua, y necesita establecer algunas propiedades para cada botón / campo / etc. Obtener un campo equivocado es simplemente fácil, ¿recuerda todas las propiedades que deben establecerse? ¿Lo escribiste con letras mayúsculas en el lugar correcto? (ya que esto no es capturado por el compilador, pero se verá como un error de tiempo de ejecución si tiene la suerte de probar esa parte)

En Titanium, las cosas simplemente se rompen cuando agrega otra vista en la parte superior de un control o hace clic en otro lugar en la GUI.

Documentación

Varias páginas API llevan el símbolo de Android, pero solo devolverá un valor nulo cuando intente crear el control. No están simplemente disponibles en la plataforma Android a pesar de los símbolos. A veces se menciona que Android no admite un método en particular, pero falta la API completa.

Baño de cocina

La aplicación de demostración. ¿Mencioné que no se compila si lo pones en la carpeta del proyecto de Eclipse porque la ruta se alarga? Debe colocarse en su unidad C en la carpeta raíz. Actualmente utilizo un enlace symbolik (mklink / J ...)

Métodos no documentados

Usted debe usar apropiadamente las cosas como label.setText (''Hello World'') para cambiar una etiqueta confiable, pero esto no está documentado en absoluto.

Depuración

Titanium.API.info (''Las impresiones son la única forma de depurar'');

Edición

Las API no están disponibles en ningún buen formato, por lo que no puede obtener la terminación de código normal con ayuda, etc. en Eclipse. Aptana por favor ayuda!

Hardware

Parece que el compilador / las herramientas no son multiproceso, por lo que una computadora rápida con un disco duro rápido es una necesidad, ya que debe hacer muchas pruebas y errores. ¿Mencioné la pobre documentación? ¡Debes probar todo allí ya que no puedes confiar en ello!

Algunas cosas positivas

  • Fuente abierta

  • De proyectos anteriores, me prometí nunca más volver a utilizar el código cerrado, ya que no se puede simplemente arreglar las cosas con solo tirar horas y mano de obra. Importante cuando llega tarde en el proyecto y necesita cumplir con un plazo límite. Esto es de código abierto y he podido ver por qué se rompe la cadena de herramientas y, de hecho, también arreglarlo.

  • Base de datos

  • También está abierto. Simplemente puede ver que no está solo y hacer una solución en lugar de otras 4 horas dedicadas a prueba y error.

  • Comunidad

  • Parece estar activo en sus foros.

Loco

  • Titanio 1.4 no es seguro para hilos . Eso significa que si utiliza subprocesos (usa la propiedad url: en una llamada a createWindow) y los programas como los que están funcionando y envía eventos con datos de ida y vuelta, se encuentra con muchas cosas muy extrañas: controladores perdidos, perdidos ventanas, demasiados eventos, muy pocos eventos, etc. Esto depende de la sincronización; poner las filas de código en un orden diferente puede colapsar o curar su aplicación. Agregar una ventana en otro file.js rompe la ejecución de app.js ... Esto también destruye las estructuras de datos internas en Titanium, ya que a veces pueden actualizar las estructuras de datos internas en paralelo, sobrescribiendo un valor recién cambiado con otra cosa.

Gran parte de los problemas que he tenido con Titanium provienen de mi experiencia en sistemas en tiempo real como OSE que admiten cientos de subprocesos, eventos y paso de mensajes. Se supone que esto funciona en Titanium 1.4, pero simplemente no lo hace de manera confiable.

  • Javascript (que es nuevo para mí) muere silenciosamente en los errores de tiempo de ejecución. Esto también significa que los errores pequeños y comunes, como escribir mal el nombre de una variable o leer en un puntero nulo no se bloquean cuando debería, por lo que puede depurarlo. En lugar de eso, partes de su programa simplemente dejan de funcionar, por ejemplo, un administrador de eventos, porque colocó incorrectamente o colocó un carácter incorrecto en un personaje.

  • Luego tenemos errores más simples en Titanium, como algunos parámetros que no funcionan en las funciones (lo cual es bastante común en la plataforma Android al menos).

  • Velocidad de ciclo de depuración de prueba y error Habiendo ejecutado Titnium Developer en varias computadoras, noté que el cuello de botella es el disco duro. Una unidad SSD en una computadora portátil hace que el ciclo de construcción sea de 3 a 5 veces más rápido que en una unidad de 4200 rpm. En una computadora de escritorio, tener unidades de disco duales en RAID 1 (modo de trazado de bandas) hace que la compilación sea un 25 por ciento más rápida que en una sola unidad con una CPU algo más rápida y también supera a la computadora portátil con unidad SSD.

Resumen

  • De los comentarios en este hilo, parece haber una lucha por la cantidad de plataformas por las que una herramienta como esta puede entregar aplicaciones. El número de API parece ser el punto de venta clave.

Esto brilla mucho cuando empiezas a usarlo. Si nos fijamos en el bugtracker abierto, verá que la cantidad de errores sigue aumentando más rápido que la cantidad de errores corregidos. Esto suele ser una señal de que los desarrolladores siguen agregando más funcionalidad, en lugar de concentrarse en reducir el número de errores.

Como consultor que intenta ofrecer aplicaciones bastante simples para multiplataformas para un cliente, no estoy seguro de que esto sea realmente más rápido que el desarrollo de aplicaciones nativas en dos plataformas. Esto se debe al hecho de que cuando está al día es rápido con Titanium, pero de repente mira hacia abajo y se encuentra en un agujero tan profundo que no sabe cuántas horas debe dedicar a una solución. Simplemente NO puede prometer una cierta funcionalidad para un determinado plazo / tiempo / costo.

Acerca de mí: He estado usando Python durante dos años con wxPython. (esa GUI es inconsitente, pero nunca se rompe de esta manera. Podría ser que yo no haya entendido el modelo de subprocesamiento utilizado por Javascript y Titanium, pero no estoy solo de acuerdo con sus foros de discusión abiertos, los objetos de GUI de repente están usando el contexto incorrecto / no actualizando ... ???) antes de eso tengo antecedentes en programación en C y ASM para dispositivos móviles.

[editar: parte agregada con errores y no estar seguro de subprocesos] [Editar: ahora he trabajado con él durante más de un mes, principalmente en PC, pero también en OS X. Añadido doble destino para iPhone y Android. Se agregó velocidad de ciclo de depuración de prueba y error.]

Hacer widgets HTML5 que parezcan widgets de iphone es una cosa, pero hacer que funcionen igual de bien es otra cuestión. El rendimiento de las animaciones html5 (incluso transiciones de vista simple), el desplazamiento de listas largas, la capacidad de respuesta a los gestos se sienten pegajosos y bruscos. Un usuario de iPhone notará la diferencia.

También hay algunas diferencias en los tipos de gestos que son compatibles con diferentes dispositivos, lo que da como resultado también códigos específicos de la plataforma y problemas de uso.

Me quedaré con aplicaciones nativas por ahora, supongo.

He estado trabajando con Titanium durante más de una semana y siento que tengo una buena idea de su debilidad.

1) ¡Si espera usar el mismo código en varias plataformas, buena suerte! Verá algo como backgroundGradient y se sorprenderá hasta que descubra que la versión de Android no lo admite. Luego, hay que volver a usar una imagen de degradado, así como usarla en ambas versiones para facilitar el código, ¿no?

2) Muchos comportamientos extraños, en el sdk Titanium para Android, es necesario comprender qué es una ventana "pesada" para que el botón de retroceso funcione, o incluso para un mejor seguimiento de eventos de orientación. No es así como es realmente la plataforma Android, sino cómo Titanium intenta hacer que su API funcione.

3) Tu tirado en la oscuridad, las cosas se estrellarán y tienes que comenzar a comentar el código y luego, cuando lo encuentres, nunca lo uses. Hay ciertos errores obvios, como la orientación y los porcentajes en Android que han sido un problema durante más de seis meses.

4) Bichos ... hay muchos bichos y serán reportados, sentados por meses, arreglados en unos pocos días. Me sorprende que incluso estén planeando lanzar un SDK móvil de Black Berry cuando hay muchos otros problemas con Android.

5) Titanium Iphone versus Titanium Android, los motores javascript son completamente diferentes. En la versión de Android, puede descargar archivos javascript remotos, incluir y usar bibliotecas como mootools, jquery, etc. Estaba en el cielo cuando descubrí esto porque no tenía que seguir compilando mi aplicación de Android. El proceso de instalación de apk android lleva tanto tiempo! Iphone nada de eso es posible, también la versión iPhone tiene un motor javascript mucho más rápido.

Si se mantiene alejado de muchas de las partes de la interfaz de usuario nativas, es decir, utilice setInterval para detectar cambios de orientación, mantener imágenes de degradado, olvidarse del botón Atrás, crear sus propias animaciones, olvidar el encabezado de la ventana, las barras de herramientas y el panel. Realmente puedes hacer una api que funcione en ambos que no requiera mucha reescritura. Pero en ese punto es tan lento como una aplicación web.

Entonces ¿Vale la pena? Después de todo el dolor, vale cada minuto. Puede abstraer la lógica y simplemente construir una IU diferente para cada uno en lugar de hacerlo en cualquier lugar. El titanio te permite hacer aplicaciones fluidas, que se sienten rápido. Pierde las potentes capacidades de diseño de cada plataforma, pero si piensa que es simple, las cosas se pueden hacer en un solo idioma.

¿Por qué no una aplicación web? En el mercado básico, los teléfonos Android son terriblemente lentos para generar una vista web y consumen una gran cantidad de memoria que podría estar usando para hacer lógica más compleja.

He intentado corona. Fue bueno hasta que descubrí que no es compatible con la transmisión de audio mp3. Así que, me detuve allí mismo. Creo que si realmente quiero ser un desarrollador de aplicaciones para iPhone debería aprender obj c. Todo lo que quería hacer era una aplicación que tuviera una lista de emisoras de radio y tú haces clic en ellas para comenzar a reproducir.

Mapkit nativo es compatible con Titanium

Me registré con solo con el propósito de comentar sobre la respuesta mayoritariamente votada en la parte superior. Lo malo de no permite que los nuevos miembros publiquen comentarios. Así que tengo que hacer que este comentario parezca más una respuesta.

La respuesta de Rory Blyth contiene algunos puntos válidos sobre los dos marcos móviles de javascript. Sin embargo, sus puntos clave son incorrectos. La verdad es que Titanium y PhoneGap son más similares que diferentes. Ambos exponen las funciones del teléfono móvil a través de un conjunto de API de javascript, y la lógica de la aplicación (html, css, javascript) se ejecuta dentro de un control nativo de WebView.

  1. PhoneGap no es solo un contenedor nativo de una aplicación web. A través de las API de javascript de PhoneGap, la "aplicación web" tiene acceso a las funciones del teléfono móvil, como la geolocalización, la cámara del acelerómetro, los contactos, la base de datos, el sistema de archivos, etc. mundo javascript. Por otro lado, una aplicación web normal que se ejecuta en el navegador web móvil no tiene acceso a la mayoría de estas funciones (la razón principal es la seguridad). Por lo tanto, una aplicación PhoneGap es más una aplicación móvil que una aplicación web. Sin duda, puedes usar PhoneGap para envolver una aplicación web que no utiliza ninguna API de PhoneGap, pero no es para eso que se creó PhoneGap.

  2. Titanium NO compila su código html, css o javascript en "bits nativos". Se empaquetan como recursos para el paquete ejecutable, como un archivo de imagen incrustado. Cuando se ejecuta la aplicación, estos recursos se cargan en un control UIWebView y se ejecutan allí (como javascript, no bits nativos, por supuesto). No existe tal cosa como un compilador de javascript a código nativo (o to-object-c). Esto se hace de la misma manera en PhoneGap también. Desde el punto de vista arquitectónico, estos dos marcos son muy similares.

Ahora, ¿son diferentes? Sí. Primero, Titanium parece ser más rico en funciones que PhoneGap al vincular más funciones de teléfonos móviles a javascript. Lo más notable es que PhoneGap no expone muchos (si alguno) componentes de la interfaz de usuario nativos a JavaScript. Titanium, por otro lado, tiene una API de IU completa que se puede utilizar en javascript para crear y controlar todo tipo de controles de UI nativos. Al utilizar estas API de UI, una aplicación Titanium puede parecer más "nativa" que una aplicación PhoneGap. En segundo lugar, PhoneGap admite más plataformas de teléfonos móviles que Titanium. Las API de PhoneGap son más genéricas y se pueden usar en diferentes plataformas como iPhone, Android, Blackberry, Symbian, etc. Titanium está dirigido principalmente a iPhone y Android al menos por ahora. Algunas de sus API son específicas de la plataforma (como las API de interfaz de usuario de iPhone). El uso de estas API reducirá la capacidad multiplataforma de su aplicación.

Entonces, si su preocupación por su aplicación es hacerla más "nativa", Titanium es la mejor opción. Si desea poder "portar" su aplicación a otra plataforma más fácilmente, PhoneGap será mejor.

Actualizado el 13/8/2010: enlace a la respuesta de un empleado de Titanium a la pregunta de Mickey.

Actualizado 12/04/2010: Decidí darle a este post una revisión anual para mantener su información actualizada. Muchas cosas han cambiado en un año que hizo que parte de la información en la publicación inicial fuera de fecha.

El mayor cambio vino de titanio. A principios de este año, Appcelerator lanzó Titanium 1.0, que se apartó drásticamente de sus versiones anteriores desde el punto de vista arquitectónico. En 1.0, el control UIWebView ya no está en uso. En su lugar, llama a las API de Titanium para cualquier función de UI. Este cambio significa un par de cosas:

  1. Su aplicación UI se vuelve completamente nativa. No hay más UI web en su aplicación, ya que las API nativas de Titanium toman el control de todas sus necesidades de UI. Titanium merece mucho crédito al ser pionero en la frontera de la "interfaz de usuario nativa multiplataforma". Ofrece a los programadores que prefieren la apariencia de la interfaz de usuario nativa, pero que no les gusta el lenguaje de programación oficial, una alternativa.

  2. No podrá utilizar HTML o CSS en su aplicación, ya que la vista web desaparece. (Nota: aún puede crear una vista web en Titanium. Pero hay algunas características de Titanium que puede aprovechar en la vista web.) Preguntas y respuestas sobre titanio: ¿Qué le sucedió a HTML y CSS?

  3. No podrá usar bibliotecas JS populares como JQuery que suponen la existencia de un objeto DOM. Continúas usando JavaScript como tu lenguaje de codificación. Pero esa es prácticamente la única tecnología web que puede utilizar si llega a Titanium 1.0 como programador web.

Video Titanium: Que hay de nuevo en Titanium 1.0.

Ahora, ¿Titanium 1.0 compila su JavaScript en "bits nativos"? No. Appcelerator finalmente se aclaró sobre este problema con este blog de desarrolladores: Titanium Guides Project: JS Environment. Los programadores somos más personas genuinas que los del departamento de Marketing, ¿no es así? :-)

Pasa a PhoneGap. No hay muchas cosas nuevas que decir sobre PhoneGap. Mi percepción es que el desarrollo de PhoneGap no fue muy activo hasta que IBM saltó a bordo más adelante este año. Algunas personas incluso argumentaron que IBM está contribuyendo más código a PhoneGap que Nitobi. Que sea cierto o no, es bueno saber que PhoneGap se está desarrollando activamente.

PhoneGap continúa basándose en tecnologías web, a saber, HTML, CSS y JavaScript. No parece que PhoneGap tenga ningún plan para unir las funciones de la interfaz de usuario nativas a JavaScript como lo está haciendo Titanium. Si bien la interfaz de usuario web sigue estando rezagada con respecto a la interfaz de usuario nativa en cuanto a rendimiento y apariencia nativa, esta brecha se está cerrando rápidamente. Existen dos tendencias en las tecnologías web que garantizan una característica brillante para la interfaz de usuario web móvil en términos de rendimiento:

  1. El motor de JavaScript se mueve de un intérprete a una máquina virtual. JavaScript es JIT compilado en código nativo para una ejecución más rápida. Motor Safari JS: SquirrelFish Extreme

  2. La representación de la página web pasa de depender de la CPU a utilizar la aceleración de GPU. Las tareas intensivas de gráficos, como la transición de páginas y la animación 3D, se vuelven mucho más fáciles con la ayuda de la aceleración de hardware. Composición acelerada de GPU en Chrome

Dichas mejoras que se originan en los navegadores de escritorio se envían a los navegadores móviles rápidamente. De hecho, desde iOS 3.2 y Android 2.0, el control de vista web móvil se ha vuelto mucho más funcional y compatible con HTML5. El futuro de la web móvil es tan prometedor que ha atraído a un niño grande a la ciudad: JQuery ha anunciado recientemente su marco de web móvil. Con JQuery Mobile que proporciona dispositivos de UI y PhoneGap con funciones de teléfono, en mi opinión, ambos combinados crean una plataforma web móvil perfecta.

También debería mencionar a Sencha Touch como otro marco de gadget de interfaz de usuario web móvil. La versión 1.0 de Sencha Touch se lanzó recientemente bajo un modelo de licencia dual que incluye GPLv3. Sencha Touch funciona bien con PhoneGap tal como lo hace JQuery Mobile.

Si eres un programador de GWT (como yo), es posible que desees revisar GWT Mobile , un proyecto de código abierto para crear aplicaciones web móviles con GWT. Incluye un envoltorio PhoneGap GWT que permite el uso de PhoneGap en GWT.

Mi entendimiento de PhoneGap es que proporcionan API de Javascript para la mayoría de las API de iPhone.

El titanio parece más fácil para un desarrollador web. Es un archivo XML simple para crear una aplicación TabView básica y luego todo lo que se encuentra en el área de contenido está controlado por HTML / JS. También sé que Titanium proporciona algún acceso de javascript a algunos de los marcos (particularmente el acceso a la información de ubicación, la identificación del teléfono, etc.).

ACTUALIZACIÓN: Titanium agregó Maps API en la versión 0.8 de su marco.

Para cualquier persona interesada en Titanium, debo decir que no tienen una muy buena documentación. Faltan algunas clases, propiedades y métodos. Pero mucho está "documentado" en su aplicación de muestra, KitchenSink, por lo que no es tan malo.

Rhomobile Rhodes ( http://rhomobile.com/products/rhodes ) tiene un enfoque muy similar a PhoneGap, pero es el único marco con:

  1. un patrón de Model View Controller (como lo proporcionan la mayoría de los marcos web)
  2. un administrador relacional de objetos
  3. soporte para todos los teléfonos inteligentes populares (incluido Windows Phone 7)
  4. un servicio de desarrollo alojado (no solo una compilación alojada): http://rhohub.com
  5. un depurador completo y un emulador sin SDK en el IDE de RhoStudio
  6. Soporte para datos offline sincronizados