Comparación entre Corona, Phonegap, Titanio

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

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

• Ansca Móvil
• brecha telefónica
• acelerador de aplicaciones

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

Jan 01 '70 08:01 Mickey Shine

Por lo que he recopilado, aquí hay algunas diferencias entre los dos:

• PhoneGap básicamente genera contenedores nativos para lo que todavía son aplicaciones web . Escupe un proyecto de WhichYourPlatformIs, usted lo construye y lo implementa. Si estamos hablando del iPhone (que es donde paso mi tiempo), no parece muy diferente de crear un iniciador de aplicaciones web (un acceso directo que tiene su propio icono de Springboard, para que puedas iniciarlo como ( me gusta ) una aplicación nativa). La "aplicación" en sí sigue siendo html/js/etc. y se ejecuta dentro de un control de navegador alojado. Lo que PhoneGap ofrece más allá de eso es un puente entre JavaScript y las API de dispositivos nativos. Entonces, escribe JavaScript en las API de PhoneGap y PhoneGap luego realiza la llamada nativa correspondiente. En ese sentido, es diferente a implementar una aplicación web antigua y simple.

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

Los dos son similares en que escribes todo tu material utilizando tecnologías web típicas (html/js/css/bla, bla, bla) y obtienes acceso a la funcionalidad nativa a través de API de JavaScript personalizadas.

Pero, nuevamente, las aplicaciones PhoneGap (¿PhonGapps? No lo sé... ¿es un nombre estúpido? Es más fácil decirlo, lo sé) comienzan su vida como aplicaciones web y terminan su vida 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, sus llamadas js se enrutan a las API nativas.

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

Qué significa esto realmente ?

1. Una aplicación Titanium parecerá 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 de navegador porque, en última instancia, es una aplicación web alojada en un control de navegador.

¿Cuál es el adecuado para usted?

• Si desea escribir aplicaciones nativas utilizando habilidades de desarrollo web, Titanium es su mejor opción.

• 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 funciones de plataforma nativas (GPS, acelerómetro, etc.) a través de una API de JavaScript unificada, PhoneGap es probablemente lo que desea.

Quizás se pregunte: ¿Por qué querría escribir una PhoneGapp (he decidido usar el nombre) en lugar de una aplicación web alojada 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 cobrar por ella. También obtienes ese ícono de inicio, lo que hace que sea más difícil para el usuario olvidarse de tu aplicación (es mucho más probable que me olvide de un marcador que del ícono de una aplicación).

Ciertamente podría cobrar por el acceso a su aplicación web alojada en la web, pero ¿cuántas personas realmente pasarán por el proceso para hacerlo? Con la App Store, elijo una aplicación, toco el botón "Comprar", ingreso una contraseña y listo. Se instala. Segundos después, lo estoy usando. Si tuviera que utilizar la interfaz web móvil de transacción única de otra persona, lo que probablemente significa tener que escribir mi nombre, dirección, número de teléfono, número CC y otras cosas que no quiero escribir, casi con certeza lo haría. No sigas adelante con esto. Además, confío en Apple: estoy seguro de que Steve Jobs no registrará mi información y luego cobrará un montón de suscripciones a revistas traviesas en mi CC por diversión.

De todos modos, excepto por el hecho de que se trata de tecnología de desarrollo web, PhoneGap y Titanium son muy diferentes, hasta el punto de ser sólo superficialmente comparables.

Por cierto, odio las aplicaciones web, y si lees las reseñas de la App Store de iTunes, los usuarios son bastante 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 alojadas dentro de instancias UIWebView. Si quisiera usar una aplicación web, abriría Safari y, ya sabes, navegaría hasta una. Compré un iPhone porque quiero cosas que sean iPhone. No tengo ningún problema en usar, digamos, una elegante aplicación web de Google dentro de Safari, pero me sentiría engañado si Google simplemente introdujera un marcador en Springboard presentando una aplicación web como nativa.

Debo irme ahora. Mi novia tiene esa expresión de "podrías-por-favor-dejar-de-usar-esa-computadora-durante-tres-segundos" en su rostro.

Oct 04 '2009 03:10 Rory Blyth

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 fue alrededor de noviembre de 2010). Aquí está mi experiencia.

Orientación dual para iPhone y Android

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

Mucha gente en la clase ha hecho aplicaciones para iPhone y no pueden hacerlas funcionar en Android sin reescrituras importantes. Desarrollé una aplicación infantil sencilla llamada Animap (ver Android Market/Appstore en Suecia) y comencé a desarrollarla en Windows. Una vez que el objetivo de Android estuvo funcionando, abrí el proyecto en OS X. No muestra ningún elemento de compilación para iPhone, solo para Android. Debes iniciar un proyecto de doble destino en OS X. (Bien, copié los archivos relevantes en un nuevo proyecto). Siguiente problema: las animaciones no funcionan en iPhone (funcionan en Android). Los eventos de desplazamiento no funcionan igual en el iPhone. (es decir, en Android aparece el evento untouch cuando el usuario deja de desplazarse y suelta el dedo de la pantalla; esto no sucede en el iPhone).

Dado que esto no se menciona en ninguna parte, básicamente necesita realizar una programación de prueba y error primero en una plataforma y luego en la otra. Por prueba y error quiero decir que tomará unos dos días lograr 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 al pie de la letra. 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 comando si son demasiado largos. (Aunque está bien para programas pequeños) 1/3 de las veces, la cadena de herramientas simplemente se detiene y debes presionar "iniciar" nuevamente. Entonces probablemente funcionará... muy poco confiable. El simulador no se encontrará al inicio y luego simplemente deberá eliminar adb.exe con Ctrl+Alt+Delete y volver a intentarlo.

Conexión de red

En una red wifi, a veces pierdes la conexión en vivo y Titanium falla (la interfaz de compilación/implementación). Si no tienes 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 son muy sencillos en comparación con esto. Titanium se parece a cualquier otra API GUI antigua y es necesario establecer algunas propiedades para cada botón/campo/etc. Equivocarse en un campo es demasiado fácil, ¿recuerdas todas las propiedades que deben configurarse? ¿Lo deletreaste con mayúsculas en el lugar correcto? (ya que el compilador no detecta esto, pero se verá como un error de tiempo de ejecución si tiene suerte de probar esa parte)

En Titanium, las cosas simplemente se rompen cuando agregas otra vista encima de un control o haces clic en algún otro lugar de la GUI.

Documentación

Varias páginas API llevan el símbolo de Android, pero solo devolverán 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 luego falta toda la API.

Fregadero

La aplicación de demostración. ¿Mencioné que no se compila si lo colocas en la carpeta de tu proyecto Eclipse porque la ruta es demasiado larga? Debe colocarse en su unidad C en la carpeta raíz. Actualmente uso un enlace simbólico (mklink /J...)

Métodos no documentados

Probablemente debas usar 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 completar el código normal con ayuda, etc. en Eclipse. Aptana por favor ayuda!

Hardware

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

Algunas cosas positivas

• Fuente abierta

• En proyectos anteriores, me prometí a mí mismo no volver a utilizar código cerrado nunca más, ya que no se pueden arreglar las cosas simplemente dedicándole horas y mano de obra. Importante cuando llega tarde en el proyecto y necesita entregarlo en una fecha límite estricta. Esto es de código abierto y pude ver por qué se rompe la cadena de herramientas y también solucionarlo.

• Base de datos de errores

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

• Comunidad

• Parece estar activo en sus foros.

Insectos

• Titanium 1.4 no es seguro para subprocesos . Eso significa que si utiliza subprocesos (use la propiedad url: en una llamada a createWindow) y programa como si los subprocesos estuvieran funcionando y envía eventos con datos de un lado a otro, se encontrará con un montón de cosas muy, muy extrañas: controladores perdidos, pérdida de datos. ventanas, demasiados eventos, muy pocos eventos, etc., etc. Todo esto depende del tiempo, poner las filas de código en diferente orden podría bloquear o reparar su aplicación. Agregar una ventana en otro file.js interrumpe 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 modificado 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 subprocesos, eventos y transmisión 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 debido a 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 un puntero nulo, no fallan cuando deberían, por lo que puedes depurarlos. En lugar de eso, partes de su programa simplemente dejan de funcionar, por ejemplo, un controlador de eventos, porque colocó mal o escribió mal un carácter.

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

• Velocidad del ciclo de depuración de prueba y error Después de ejecutar 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 entre 3 y 5 veces más rápido que en una unidad de 4200 rpm. En una computadora de escritorio, tener dos unidades en RAID 1 (modo de división) hace que la construcció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 computadora portátil con unidad SSD.

Resumen

• A partir de los comentarios en este hilo, parece haber una lucha por la cantidad de plataformas para las que una herramienta como esta puede ofrecer aplicaciones. La cantidad de API parece ser el punto clave de venta.

Esto se nota mucho cuando empiezas a usarlo. Si observa el rastreador de errores 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 funciones, en lugar de concentrarse en reducir la cantidad 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 desarrollar aplicaciones nativas en dos plataformas. Esto se debe al hecho de que cuando estás al día eres rápido con Titanium, pero de repente miras hacia abajo y te encuentras en un agujero tan profundo que no sabes cuántas horas se deben dedicar para solucionarlo. Simplemente NO puede prometer una determinada funcionalidad durante un plazo/tiempo/costo determinado.

Acerca de mí: He estado usando Python durante dos años con wxPython. (esa GUI es inconsistente, pero nunca se rompe de esta manera. Puede que sea yo quien no haya entendido el modelo de subprocesos utilizado por Javascript y Titanium, pero no estoy solo según 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.

[editar: parte agregada con errores y no es segura para subprocesos] [Editar: ahora he trabajado con él durante más de un mes, principalmente en PC, pero también en OS X. Se agregó orientación dual para iPhone y Android. Se agregó velocidad del ciclo de depuración de prueba y error.]

Oct 25 '2010 17:10 user288299

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

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

Jan 11 '2010 23:01 Evan Kirchhoff