Comparación entre Corona, Phonegap, Titanium

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

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

• Titanium source se compila a bits nativos. Es decir, su html / js / etc. no están simplemente unidos a un proyecto y luego alojados dentro de un control de navegador web, se convierten en aplicaciones nativas. Esto significa, por ejemplo, que la interfaz de tu app estará compuesta por componentes de interfaz de usuario nativos. Hay formas de obtener una apariencia nativa sin tener una aplicación nativa, pero... bien... qué pesadilla que suele ser.

Los dos son similares en que escribes todas tus cosas usando tecnologías web típicas (html/js/css / bla, bla, bla), y que obtienes acceso a funcionalidad a través de api JavaScript personalizadas.

Pero, de nuevo, PhoneGap aplicaciones(PhonGapps? No sé... ¿es un nombre estúpido? Es más fácil decirlo - sé que mucho) comenzar sus vidas como aplicaciones web y terminar sus vidas como aplicaciones web. En el iPhone, su html / js / etc. se acaba de ejecutar dentro de un control UIWebView, y las API de JavaScript de PhoneGap sus llamadas js se enrutan a las API nativas.

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

¿Qué hace esto realmente significa ?

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 PhoneGap se verá como una aplicación web alojada en un control del navegador porque, en última instancia, es una aplicación web alojada en un control del navegador.

¿Cuál es el adecuado para usted?

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

• Si desea escribir una aplicación utilizando 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 características nativas de la plataforma (GPS, acelerómetro, etc.) a través de una API JavaScript unificada, PhoneGap es probablemente lo que quieres.

Podrías estar preguntando: ¿Por qué querría escribir una PhoneGapp (he decidido usar el nombre) en lugar de una web aplicación que está alojado en la web? ¿No puedo seguir accediendo a algunas funciones nativas del dispositivo de esa manera, pero también tener la conveniencia de una verdadera implementación web en lugar de obligar al usuario a descargar mi aplicación "nativa" e instalarla?

La respuesta es: Porque puedes enviar tu PhoneGapp a la App Store y cobrarla. También obtienes ese icono de lanzador, lo que hace que sea más difícil para el usuario olvidarse de su aplicación (soy mucho más probable que se olvide de un marcador que de un icono de aplicación).

Usted podría ciertamente cobran por el acceso a su aplicación web alojada en la web, pero ¿cuántas personas realmente van a pasar por el proceso para hacer eso? Con la App Store, elijo una aplicación, toque 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 CC y otras cosas que no quiero tocar, es casi seguro que no pasaría por consigo. Además, confío en Apple-estoy seguro de que Steve Jobs no va a registrar mi información y luego cobrar un montón de suscripciones a revistas traviesas a mi CC por diversión.

De todos modos, excepto por el hecho de que la tecnología de desarrollo web está involucrada, PhoneGap y Titanium son muy diferentes, hasta el punto de ser solo superficialmente comparables.

Odio las aplicaciones web, por cierto, y si lees las reseñas de iTunes App Store, los usuarios son bastante buenos para detectarlas. No voy a dar ningún nombre, pero tengo un par de " aplicaciones" en mi teléfono que se ven y se ejecutan como basura, y es porque son aplicaciones web que se alojan dentro de instancias 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 con el uso, por ejemplo, una aplicación web de Google elegante dentro de Safari, pero me sentiría engañado si Google acaba de colar un marcador en el trampolín mediante la presentación de una aplicación web como una nativa.

Tengo que irme ahora. Mi novia tiene que podrías-por-favor-dejar-de-usar-esa-computadora-por-tres-segundos mirar su cara.

Estoy tomando un curso de 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 era alrededor de noviembre de 2010). Aquí está mi experiencia.

IPhone Android dual targetting

Aunque las guías de la 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 ha hecho aplicaciones de iPhone, y no pueden hacer que funcionen en Android sin reescrituras importantes. Desarrollé una simple aplicación para niños llamada Animap (ver android market / Appstore en Suecia) y comencé a desarrollar bajo Windows. Una vez que el objetivo de Android estaba trabajando abrí el proyecto en OS X. No muestra ningún material de compilación para iPhone, solo para Android. Necesita iniciar un proyecto de doble destino bajo OS X. (Ok, copié los archivos relevantes a un nuevo proyecto). Siguiente problema - las animaciones no funciona en iPhone (funcionan en Android). Los eventos de desplazamiento no funcionan igual en el iPhone. (es decir, en Android se obtiene el evento intocable cuando el usuario deja de desplazarse y libera su dedo de la pantalla, esto no sucede en el iPhone).

Dado que esto no se menciona en algún lugar, básicamente necesita hacer programación de prueba y error en una plataforma primero, luego en la otra plataforma. Por ensayo y error me refiero a que tomará unos dos días para obtener una aplicación tan simple como Animap trabajando en la otra plataforma. También tendrá que tener if (android) entonces... o si(iphone)... por todo tu código...

Descargar y configurar

Debe seguir las instrucciones al pie de la letra. No intente usar java 64 bit. No compilará la aplicación de demostración KitchenSink 1.4.0. (1.3 funciona bien!) Debe poner los archivos directamente en la unidad C, ya que los nombres de ruta largos harán que el programa externo no reciba todos los parámetros de la línea de comandos si llegan a largo. (Multa para programas pequeños aunque) 1/3 de las veces, la cadena de herramientas simplemente se detiene y debe presionar 'launch' nuevamente. Entonces probablemente funcionará... muy poco fiable. El simulador no se encuentra en el inicio y entonces usted debe simplemente matar de adb.exe con Ctrl + Alt + Supr y reintentar.

Conexión de red

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

API

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

En Las cosas de titanio simplemente se rompen cuando agrega otra vista encima de un control o hace clic en otro lugar en la interfaz gráfica de usuario.

Documentación

Varias páginas de API llevan el símbolo de Android, pero solo devolverán un null cuando intentes 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 es compatible con un método en particular, pero entonces falta toda la API.

KitchenSink

La aplicación de demostración. Lo hice mencione que no compila si lo pone en su carpeta de proyecto Eclipse porque la ruta se vuelve demasiado larga? Debe colocarse en su unidad C en la carpeta raíz. Actualmente uso un enlace symbolik (mklink / J ...)

Métodos no documentados

Probablemente debes usar cosas como etiqueta.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 manera de depurar');

Edición

Las APIs no están disponibles en ningún buen formato, por lo que no puede obtener una finalización de código ordinaria con ayuda, etc. en Eclipse. Aptana por favor ayuda!

Hardware

Parece que el compilador/herramientas no son multiproceso por lo que un equipo rápido con un disco duro rápido es una necesidad, ya que debe hacer mucho ensayo y error. ¿Mencioné la mala documentación? Usted debe probar todo allí, ya que no se puede confiar en él!

Algunas cosas positivas

• Código abierto

• De anterior proyectos Que me he prometido a mí mismo nunca volver a utilizar el código cerrado, ya que no se puede simplemente arreglar las cosas con solo tirar horas y mano de obra en él. Importante cuando llega tarde al proyecto y necesita entregar para una fecha límite difícil. Esto es de código abierto y he sido capaz de ver por qué la cadena de herramientas se rompe y realmente arreglarlo también.

• Bugdatabase

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

• Comunidad

• Parece estar activo en sus foros.

Errores

• Titanium 1.4 no es threadsafe . Eso significa que si haces uso de subprocesos (usa la propiedad url: en una llamada CreateWindow) y programas como los subprocesos están funcionando y envían eventos con datos de ida y vuelta, te encuentras con un montón de cosas muy, muy extrañas: controladores perdidos, ventanas perdidas, demasiados eventos, muy pocos eventos, etc. sucesivamente. Todo esto es dependiente en el momento, poner las filas de código en un orden diferente podría bloquear o curar su aplicación. Agregar una ventana en otro archivo.js rompe tu aplicación.ejecución js... Esto también elimina las estructuras de datos internas en Titanium, ya que a veces pueden actualizar las estructuras de datos internas en paralell, sobrescribiendo un valor que acaba de cambiar con otra cosa.

Muchos de los problemas que he tenido con Titanium provienen de mi experiencia en sistemas en tiempo real como OSE que admiten cientos de hilos, 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 errores de tiempo de ejecución. Esto también significa que los errores pequeños y comunes, como escribir mal un nombre de variable o leer un puntero nulo no se bloquean cuando debería, por lo que puede depurarlo. En su lugar, partes de su programa simplemente dejan de funcionar, por ejemplo, un eventhandler, porque ha extraviado/escrito incorrectamente un carácter.

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

• Velocidad del 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 compilación sea aproximadamente 3-5 veces más rápido que en una unidad de 4200 rpm. En un escritorio, tener unidades duales en RAID 1 (modo de rayas) hace que la compilación sea aproximadamente 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 unidad SSD portátil.

Resumen

• De los comentarios en este hilo parece haber una lucha por el número de plataformas de una herramienta como esta puede entregar aplicaciones para. 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 se ve que el número de errores sigue aumentando más rápido que el número 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 entregar aplicaciones bastante simples a multiplataformas para un cliente, no estoy seguro de que esto sea realmente más rápido que desarrollar aplicaciones nativas en dos plataformas. Esto se debe al hecho de que cuando estás al día eres rápido con el titanio, pero de repente miras hacia abajo y te encuentras en un agujero tan profundo usted no sabe cuántas horas se deben pasar para una solución. Simplemente NO puede prometer una cierta funcionalidad para un cierto plazo/tiempo/costo.

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

[edit-parte añadida con errores y no es seguro hilo] [Editar - ahora después de haber trabajado con él durante un mes+, sobre todo en PC, pero algunos en OS X también. Añadido doble targetting para iPhone y Android. Se ha añadido la velocidad del ciclo de depuración de prueba y error.]

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

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

He estado trabajando con Titanio durante más de una semana y siento que tengo una buena sensación sobre su debilidad.

1)Si usted espera que utilice 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. A continuación, tiene que volver a utilizar una imagen de degradado, también podría utilizarlo para ambas versiones para hacer el código más fácil derecho?

2) Un montón de comportamientos extraños, en el titanio android sdk necesita entender lo que es una ventana "pesada" solo para que el botón atrás funcione, o incluso mejor seguimiento de eventos de orientación. Así no es como la plataforma Android realmente es, es solo cómo Titanium trata de hacer que su API funcione.

3) Su arrojado en la oscuridad, Las cosas se estrellarán y usted tiene que empezar a comentar el código y luego cuando lo encuentre, nunca lo use. 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) Error .... hay muchos errores y serán reportados, se sentarán durante meses, se arreglarán en unos pocos días. Me sorprende que incluso estén planeando lanzar un sdk móvil Black Berry cuando hay tantos 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 para Android. El proceso de instalación de Android apk toma tanto tiempo! Iphone nada de eso es posible, también la versión para iphone tiene un motor javascript mucho más rápido.

Si se mantiene alejado de muchas de las partes de la interfaz de usuario nativa, es decir, en su lugar use setInterval para detectar cambios de orientación, quedarse con imágenes degradadas, olvidarse del botón atrás, construir sus propias animaciones, olvidar el encabezado de la ventana, las barras de herramientas y el panel de control. Realmente puedes hacer una api que funcione en ambos que no requiere de mucha reescritura. Pero en ese momento es tan lento como una aplicación web.

Entonces, ¿vale la pena? Después de todo el dolor, vale la pena cada minuto. Puede abstraer la lógica y simplemente construir una interfaz de usuario diferente para cada uno en lugar de si elseing en todas partes. El titanio le permite realizar aplicaciones fluidas, que se sienten rápidas. Pierdes las poderosas habilidades de diseño de cada plataforma, pero si piensas simple, las cosas se pueden hacer en un solo idioma.

¿Por qué no una aplicación web? En nivel de entrada de mercado teléfonos Android su horriblemente lento para generar una vista web y consume una gran cantidad de memoria que podría estar utilizando para hacer lógica más compleja.

Aquí hay un análisis más reciente y profundo de Appcelerator y PhoneGap: http://savagelook.com/blog/portfolio/a-deeper-look-at-appcelerator-and-phonegap

Y aquí hay aún más detalles sobre cómo difieren programáticamente: http://savagelook.com/blog/portfolio/phonegap-is-web-based-appcelerator-is-pure-javascript

Mapkit nativo es compatible con Titanium

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

También hay algunas diferencias en los tipos de gestos que son compatibles con diferentes dispositivos que se traduce en código específico de la plataforma y problemas de usabilidad, así.

Me quedaré con las aplicaciones nativas por ahora, supongo.

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

1. un patrón de Controlador de Vista de modelo (como la mayoría de los frameworks web proporcionan)
2. un Gestor 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 RhoStudio IDE
6. soporte para datos sincronizados sin conexión

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

Mi comprensión de PhoneGap es que proporcionan API de Javascript a gran parte de las API de iPhone.

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

ACTUALIZACIÓN: Titanium agregó API de mapas en versión 0.8 de su framework.

Usted debe aprender objective c y aplicaciones nativas del programa. No confíes en estas cosas que crees que harán la vida más fácil. Apple se ha asegurado de que la forma más fácil es usar sus herramientas y lenguaje nativos. Para sus 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. Mira algunos tutoriales - si entiendes javascript entonces objective c no es difícil. Las soluciones alternativas son miserables y Apple puede desconectarte en cualquier momento que lo desee.

De las soluciones que mencionaste, ninguna parece darte acceso directo al framework MapKit introducido en OS 3.0.

Como los widgets HTML de Google Maps no son tan buenos como MapKit (vea Google Latitude para un ejemplo), probablemente 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 por defecto), y algunas de las otras soluciones podrían ser así.

editar: Titanium ahora tiene soporte para MapKit

He intentado corona. Era bueno hasta que descubrí que no es compatible con la transmisión de audio mp3. Así que me detuve justo ahí. Creo que si realmente quiero ser un desarrollador de aplicaciones de Iphone debería aprender obj c. Todo lo que quería hacer una aplicación que tiene una lista de estaciones de radio y haga clic en ellos comienza a jugar.