Comparación entre Corona, Phonegap, Titanium


310

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

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

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


1
También está Adobe FLEX, que puede generar aplicaciones para iPhone a partir de junio de 2011. adobe.com/products/flex
neoneye

1
Echale un vistazo. Amigo aquí es una comparación directa. savagelook.com/blog/portfolio/…
Hikmat Khan

Respuestas:


368

Me registré con stackoverflow solo para comentar la respuesta más votada en la parte superior. Lo malo es que stackoverflow 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 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. Básicamente, cualquier función que proporcione el SDK del teléfono móvil se puede "puentear" javascript world. 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. Ciertamente, puede usar PhoneGap para envolver una aplicación web que no utiliza ninguna API de PhoneGap, pero para eso no 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, al igual que 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 un compilador javascript-to-native-code (u to-Objective-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? Si. Primero, Titanium parece tener más funciones que PhoneGap al unir más funciones de teléfonos móviles a javascript. Lo más notable es que PhoneGap no expone muchos (si los hay) componentes nativos de la interfaz de usuario a javascript. Titanium, por otro lado, tiene una API de interfaz de usuario completa que se puede llamar en javascript para crear y controlar todo tipo de controles de interfaz de usuario nativos. Al utilizar estas API de UI, una aplicación Titanium puede verse más "nativa" que una aplicación PhoneGap. En segundo lugar, PhoneGap admite más plataformas de telefonía móvil 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 se dirige principalmente a iPhone y Android, al menos por ahora. Algunas de sus API son específicas de la plataforma (como las API de la interfaz de usuario del iPhone).

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

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

Actualizado el 04/12/2010: decidí darle a esta publicación una revisión anual para mantener actualizada su información. Muchas cosas tienen cambios en un año que hacen que parte de la información en la publicación inicial esté desactualizada.

El mayor cambio provino del 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 IU. Este cambio significa un par de cosas:

  1. La interfaz de usuario de tu aplicación se vuelve completamente nativa. No hay más interfaz de usuario web en su aplicación ya que las API nativas de Titanium toman el control de todas sus necesidades de interfaz de usuario. Titanium merece mucho crédito por 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 no les gusta el lenguaje de programación oficial como alternativa.

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

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

Video de Titanium: Novedades de Titanium 1.0.

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

Pase 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 se unió a finales de este año. Algunas personas incluso argumentaron que IBM está contribuyendo más código a PhoneGap que Nitobi. Siendo 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 características nativas de la interfaz de usuario a JavaScript como lo está haciendo Titanium. Si bien la interfaz de usuario web todavía está por detrás de la interfaz de usuario nativa en cuanto al rendimiento y la apariencia nativa, esa brecha se está cerrando rápidamente. Hay dos tendencias en las tecnologías web que aseguran una función brillante para la interfaz de usuario web móvil en términos de rendimiento:

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

  2. El procesamiento de la página web pasa de depender de la CPU al uso de la aceleración de GPU. Las tareas gráficas intensivas como la transición de página y la animación 3D se vuelven mucho más fluidas con la ayuda de la aceleración de hardware. Composición acelerada por GPU en Chrome

Dichas mejoras que se originan en los navegadores de escritorio se entregan rápidamente a los navegadores móviles. De hecho, desde iOS 3.2 y Android 2.0, el control de la vista web móvil se ha vuelto mucho más eficiente 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 web móvil. Con JQuery Mobile proporcionando dispositivos de interfaz de usuario, y PhoneGap proporcionando funciones de teléfono, ambos combinados crean una plataforma web móvil perfecta en mi opinión.

También debería mencionar 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 al igual que JQuery Mobile.

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


10
Um ... usted dice que "PhoneGap no es solo un contenedor nativo de una aplicación web". Continúa discutiendo el acceso que le da a la funcionalidad del dispositivo nativo. Creo que cubrí esto cuando escribí: "Lo que PhoneGap proporciona más allá de eso es un puente entre JavaScript y las API de dispositivos nativos. Entonces, escribes JavaScript contra las API de PhoneGap, y PhoneGap realiza la correspondiente llamada nativa correspondiente. A ese respecto, es diferente de implementar una aplicación web antigua ". Si se registró para refutar mi declaración, debería haberla leído en su totalidad. Sé que mis publicaciones son largas, pero ... aún así.
Rory Blyth

55
Podría haber sido más claro, pero los detalles de qué API son complicados ya que ha variado con el tiempo de un dispositivo a otro lo que puede hacer (ha mejorado mucho, pero la matriz de características para diferentes plataformas ha sufrido bastantes revisiones). Escribí sobre una de las diferencias clave, y lo que escribí es correcto; de hecho, está de acuerdo con lo que escribiste. Simplemente entró en más detalles sobre a qué API puede acceder.
Rory Blyth

99
En cuanto a Titanium y "bits nativos", supongo que mi error fue leer esto en su sitio, justo en la página principal de Appcelerator: "funcionan muy bien porque compilamos Titanium en código nativo para un rendimiento máximo". Quizás deberías escribirles para hacerles saber que están equivocados. Compruébalo: tinyurl.com/yzlzvk5
Rory Blyth

66
Para obtener más información, consulte las Preguntas frecuentes sobre Titanium: el primer tema, "¿Son estas aplicaciones web móviles o aplicaciones móviles nativas?", Trata el tema de manera sucinta. Volvería a publicar una cita aquí, pero creo que preferiría obtenerla directamente de la compañía, ya que creo que son las autoridades de su producto: tinyurl.com/ya9topg
Rory Blyth

44
Dennis, gracias por la gran respuesta. ¿Sigues desarrollando con Titanium? ¿Puedes comentar ahora que 1.7 ha aterrizado?
PaulM

193

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

  • PhoneGap básicamente genera envoltorios nativos para lo que todavía son aplicaciones web . Escupe un proyecto WhateverYourPlatformIs, lo construyes y lo implementas. Si hablamos 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, por lo que puede 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 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 PhoneGap realiza la correspondiente llamada nativa correspondiente. En ese sentido, es diferente de implementar una aplicación web simple y antigua.

  • 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, se convierten en aplicaciones nativas. Eso significa, por ejemplo, que la interfaz de su aplicación estará compuesta por componentes nativos de la interfaz de usuario. Hay formas de obtener una apariencia nativa sin tener una aplicación nativa, pero ... bueno ... qué pesadilla suele ser.

Los dos son similares en el sentido de que escribe todas sus cosas utilizando tecnologías web típicas (html / js / css / blah blah blah), y que obtiene acceso a la funcionalidad nativa a través de API de JavaScript personalizadas.

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

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

Lo que significa 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 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 características de la plataforma nativa (GPS, acelerómetro, etc.) a través de una API JavaScript unificada, PhoneGap es probablemente lo que desea.

Tal vez se pregunte: ¿Por qué querría escribir un 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 puede enviar su PhoneGapp a la App Store y cobrar por ello. También obtienes ese ícono de iniciador, lo que hace que sea más difícil para el usuario olvidarse de tu aplicación (es mucho más probable que olvide un marcador que el í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 van a pasar 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 usar la interfaz única de transacciones web móviles de otra persona, lo que probablemente significa tener que ingresar mi nombre, dirección, número de teléfono, número CC y otras cosas que no quiero aprovechar, casi seguro que no No sigas adelante. 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 de revistas traviesas a mi CC por patadas.

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.

Por cierto, odio las aplicaciones web, y si lees las reseñas de iTunes App Store, 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 que están alojadas 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 problemas para usar, digamos, una aplicación web elegante de Google dentro de Safari, pero me sentiría engañado si Google simplemente colocó un marcador en Springboard presentando una aplicación web como nativa.

Debo irme ahora. Mi novia tiene esa mirada de "podría, por favor, dejar de usar esa computadora" durante tres segundos.


22
El problema con la respuesta es que es principalmente INCORRECTO. Vea la respuesta de DennisJZH a continuación.
jbwiv

99
@jbwiv: el problema con su comentario es que se basa principalmente en la respuesta de DennisJZH, que en su mayoría es INCORRECTA. Ver mis respuestas a continuación. Para evitar más confusión, sugiero que ambos echen un vistazo a la documentación oficial de los productos y también lean mi publicación completa . Muchas gracias.
Rory Blyth

15
@Matthew - Oh, la novia definitivamente tiene prioridad :) En cuanto a que estas preguntas son irrelevantes, básicamente porque el cambio ocurre (si entendí mal su significado, me disculpo), el hecho es que la gente quiere respuestas a los problemas que existen en este momento. Podríamos argumentar que nada de esto importa ya que la Tierra será cocinada en el futuro por el Sol, ya que quema su combustible y se expande, destruyendo nuestro planeta, pero ... esto nos da algo que hacer mientras esperamos.
Rory Blyth

2
@Matthew - Además, esta persona está dispuesta a probar cosas nuevas. Puede que no sea la forma que prefieres, pero sigue siendo nueva. Todavía tiene que aprender sobre el desarrollo de iPhone (lea los documentos sobre las pautas de la interfaz de usuario, etc.). No hay una razón justificable para tratar de evitar que alguien intente lograr algo solo porque no ve el valor en él. Por ejemplo, odio los hongos, pero no trate de evitar que otras personas se los coman. Entiendo que les gustan los champiñones de la misma manera que me encanta el azafrán, y sé que no quiero que nadie intente quitarme el azafrán solo porque no les gusta.
Rory Blyth

1
Sí, pero si usted es un verdadero asistente de tecnología web, estoy seguro de que nadie podrá darse cuenta de que su "aplicación web" no es realmente una aplicación nativa. En los casos en que es obvio que una aplicación es una "aplicación web" envuelta en UIWebView, eso significa que el creador no se tomó el tiempo o se preocupó lo suficiente como para que fuera de una calidad lo suficientemente alta.
trusktr

62

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

iPhone Android doble orientación

Aunque las guías de 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 para iPhone, y no pueden hacer que funcionen en Android sin reescrituras importantes. Desarrollé una aplicación para niños simple llamada Animap (ver 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 material de compilación para iPhone, solo para Android. Debe iniciar un proyecto de doble objetivo en OS X. (Ok, 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 se obtiene el evento de no tocar cuando el usuario deja de desplazarse y suelta el dedo de la pantalla, esto no sucede en el iPhone).

Como esto no se menciona en algún lugar, básicamente debe realizar una programación de prueba y error en una primera plataforma, luego en la otra plataforma. Por prueba y error me refiero a que llevará unos dos días conseguir que una aplicación tan simple como Animap funcione en la otra plataforma. También necesitará tener if (android) entonces ... o if (iphone) ... en todo su código ...

Descargar y configurar

Debe seguir las instrucciones al pie de la letra. No intente usar 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 los nombres de ruta largos harán que el programa externo no reciba todos los parámetros de la línea de comandos si son demasiado largos. (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 intentar.

Conexión de red

En una red wifi, a veces pierde la conexión en vivo y Titanium se bloquea (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 en sus servidores.

API

CSS, HTML y jQuery es muy sencillo en comparación con esto. Titanium se parece a cualquier otra API GUI anterior, y debe establecer algunas propiedades para cada botón / campo / etc. Obtener un campo incorrecto es demasiado fácil, ¿recuerda todas las propiedades que deben establecerse? ¿Lo deletreaste con letras mayúsculas en el lugar correcto? (ya que el compilador no lo detecta, 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 agrega otra vista encima 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án un valor nulo cuando intente crear el control. No solo están 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 toda la API.

Fregadero

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

Métodos no documentados

Debes 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 obtener la finalización del código ordinario 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 imprescindible, ya que debe realizar muchas pruebas y errores. ¿Mencioné la mala documentación? ¡Debes probar todo allí ya que no puedes confiar en él!

Algunas cosas positivas

  • Fuente abierta
  • De proyectos anteriores, me he prometido a mí mismo nunca más volver a usar el código cerrado, ya que no puedes simplemente arreglar las cosas simplemente arrojando horas y mano de obra. Importante cuando se atrasa en el proyecto y necesita entregar por una fecha límite difícil. Esto es de código abierto y he podido ver por qué la cadena de herramientas se rompe y realmente también lo soluciono.

  • Bugdatabase

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

  • Comunidad

  • Parece estar activo en sus foros.

Loco

  • Titanium 1.4 no es seguro para hilos . Eso significa que si hace uso de subprocesos (use la propiedad url: en una llamada createWindow) y programa como si los subprocesos funcionan y envía eventos con datos de ida y vuelta, se encuentra con muchas cosas muy, muy extrañas: controladores perdidos, perdidos ventanas, demasiados eventos, muy pocos eventos, etc. etc. Todo esto depende del tiempo, poner las filas de código en un orden diferente podría fallar o sanar su aplicación. Agregar una ventana en otro archivo.js interrumpe la ejecución de su aplicación.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.

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 mensajes pasados. 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 por 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 en un puntero nulo, no se bloquean cuando deberían, por lo que puede depurarlo. En cambio, algunas partes de su programa simplemente dejan de funcionar, por ejemplo, un controlador de eventos, porque extravió / formuló mal un personaje.

  • Luego 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 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 aproximadamente 3-5 veces más rápido que en una unidad de 4200 rpm. En una computadora de escritorio, tener unidades duales en RAID 1 (modo de bandas) hace que la construcció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 para las que una herramienta como esta puede ofrecer aplicaciones. El número de API parece ser el punto clave de venta.

Esto brilla mucho cuando comienzas a usarlo. Si observa el rastreador de errores abierto, verá que la cantidad de errores sigue aumentando más rápidamente que la cantidad de errores corregidos. Esto suele ser una señal de que los desarrolladores siguen agregando más funcionalidades, 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 acelerado 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 debes dedicar a una solución alternativa. Simplemente NO puede prometer una cierta funcionalidad para un determinado plazo / tiempo / costo.

Sobre mí: He estado usando Python durante dos años con wxPython. (esa GUI es inconsistente, pero nunca se rompe así. Podría ser yo quien no haya entendido el modelo de subprocesos utilizado por Javascript y Titanium, pero no estoy solo de acuerdo con sus foros de discusión abiertos, los objetos de la 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 ser segura para subprocesos] [Editar - ahora que he trabajado con ella durante un mes o más, principalmente en PC pero también en OS X. Agregado de doble objetivo para iPhone y Android. Se agregó velocidad de ciclo de depuración de prueba y error.]


1
Con la versión 1.4 de Titanium, ahora he examinado los archivos .apk entregados desde Titanium y simplemente no son muy buenos. Funcionan, pero el directorio de compilación completo está comprimido allí. Eso significa que las fallas de compilación menores, como copiar la pantalla de bienvenida en tres ubicaciones diferentes durante la construcción, de repente consumen, ya que tengo una gran imagen de pantalla de bienvenida, aproximadamente 1 meg de almacenamiento en el teléfono. Y eso es solo para una variante muy simple de hello-world. El código fuente de JavaScript también se copia en las compilaciones y en los archivos .apk y, por lo tanto, se entrega a todos los clientes.
user288299

La versión 1.5 ya está disponible y se dice que es una reescritura importante para la plataforma Android. No probaré esto ya que necesito aprender el desarrollo nativo de Android ahora.
usuario288299

La versión 1.5 ya está disponible y se dice que es una reescritura importante para la plataforma Android. No probaré esto, ya que hemos pasado a aprender el desarrollo nativo de Android ahora. Como hoy se nos enseñó sobre el ciclo de vida de Android nativo, creo que los problemas que tuve con algunas ventanas que perdieron contenido variable la segunda vez que se mostraron fueron causados ​​por Titanium que no guardó el estado anterior al estado onPause () del ciclo de vida. developer.android.com/guide/topics/fundamentals.html#lcycles . Llamar a Titanium.Map.MapView.hide () y luego show () podría simplemente matar sus variables locales para el mapa
user288299

1
Acabo de jugar con 1.7, tu descripción es muy correcta. Esta plataforma es muy impredecible, con un rendimiento horrible e innumerables horas de trabajo en torno a la búsqueda. Si tiene los recursos al comienzo de un proyecto, cree una versión nativa para cada plataforma.
Jonathon Kresner

25

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

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


¿Tiene algún plan o escala de tiempo para las secuencias de comandos de interfaz de usuario nativas? He hecho bastante con Lua y realmente quiero amar a Corona. Para el desarrollo no relacionado con el juego, Titanium parece un poco por delante.
uroc

44
Hola uroc Tenemos características de interfaz de usuario nativas que llegarán en la versión 1.1 (¡ETA más adelante esta semana!), Y más en breve. Sin embargo, mi sensación de Titanium es que han hecho un buen trabajo al exponer una gran cantidad de elementos nativos de la interfaz de usuario, mientras que nos vamos a centrar en los elementos de la interfaz de usuario más críticos al tiempo que hacemos un mayor esfuerzo de ingeniería en las funciones de animación y renderizado. El razonamiento es que (i) ya hay buenos productos para aplicaciones solo de interfaz de usuario, (ii) la interfaz de usuario es la parte más amigable de Cocoa (¡relativamente hablando!), Pero (iii) cualquier cosa que involucre animación OpenGL es un punto de dolor en el iPhone en el momento.
Evan Kirchhoff

Parece que Corona es adecuado para desarrollar juegos en lugar de aplicaciones, ¿no es así?
anticafe

18

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

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

2) Una gran cantidad de comportamientos extraños, en el sdk de Android Titanium necesita comprender qué es una ventana "pesada" para que el botón de retroceso funcione, o incluso un mejor seguimiento de eventos de orientación. Así no es realmente la plataforma de Android, es simplemente cómo Titanium intenta hacer que su API funcione.

3) Su lanzamiento en la oscuridad, las cosas se estrellarán y tendrá que comenzar 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) Errores ... hay muchos errores y se informarán, se quedarán sentados durante meses, se solucionarán en unos días. Me sorprende que incluso estén planeando lanzar un sdk móvil Black Berry cuando haya tantos otros problemas con Android.

5) Titanium Iphone versus Titanium Android 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 Android apk lleva tanto tiempo! Iphone nada de eso es posible, también la versión de iPhone tiene un motor JavaScript mucho más rápido.

Si se mantiene alejado de muchas de las partes nativas de la interfaz de usuario, es decir, use setInterval para detectar cambios de orientación, quedarse con las 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 tablero. Realmente puede hacer una API que funcione en ambos que no requiera 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 cada minuto. Puede abstraer la lógica y simplemente crear una interfaz de usuario diferente para cada uno en lugar de hacerlo si lo hace en todas partes. El titanio le permite realizar aplicaciones fluidas, que se sienten rápidas. Pierdes las poderosas capacidades 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 los teléfonos Android del mercado de nivel de entrada, es terriblemente lento para generar una vista web y consume mucha memoria que podría estar utilizando para hacer una lógica más compleja.




8

Hacer widgets HTML5 que parezcan widgets para iphone es una cosa, pero hacer que funcionen igual de bien es otra cosa. El rendimiento de las animaciones html5 (incluso las transiciones de vista simples), el desplazamiento de listas largas, la capacidad de respuesta a los gestos se siente pegajosa 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, lo que resulta en problemas específicos de código y usabilidad de la plataforma.

Me quedaré con aplicaciones nativas por ahora, supongo.


7

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 controlador de vista de modelo (como la mayoría de los marcos 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 construcción alojada): http://rhohub.com
  5. un depurador completo y un emulador sin SDK en RhoStudio IDE
  6. soporte para datos sin conexión sincronizados

6

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.


5

Entiendo que 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 de fondo. Es un simple archivo XML para crear una aplicación básica TabView y luego todo en el área de contenido está controlado por HTML / JS. También sé que Titanium proporciona cierto 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.


Según el "Titanium parece más fácil para un desarrollador web de fondo". declaración. ¿Quieres decir más fácil que el nativo, verdad? Como PhoneGap parece estar más en línea con alguien con experiencia en desarrollo web que Titanium ...
Serhiy

4

Debe aprender el objetivo c y programar aplicaciones nativas. No confíe en estas cosas que cree que le facilitarán la vida. 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 ningún código dependiendo del elemento. Mire algunos tutoriales: si comprende javascript, entonces el objetivo c no es difícil. Las soluciones son miserables y Apple puede desconectarte en cualquier momento que lo desee.


3
Apple podría tirar del enchufe ... eso es lo que estoy relativos a
Mickey Shine

66
Cita: "Apple se ha asegurado de que la forma más fácil es usar sus herramientas y lenguaje nativos". Realmente no lo han hecho. Si quisieran hacer eso, proporcionarían, por ejemplo, soporte de Python. Habría recolección de basura (lo que solo reduciría la frecuencia de los bloqueos; la mayoría de las aplicaciones de iPhone están terriblemente escritas). Excavo ObjC y, como tú, prefiero usarlo que js, pero esa no era la pregunta del operador. Además, MonoTouch hace que el desarrollo sea más fácil que cualquiera de estas opciones. Puedo crear una propiedad en una línea; obtenga una referencia a la carpeta Documento con una línea ... y así sucesivamente. Los bits de Apple podrían mejorarse enormemente.
Rory Blyth

66
Una buena solución sería que Apple proporcionara su propia alternativa ObjC. Algo para aplicaciones que no necesitan el nivel de control que ObjC te brinda. Especialmente para aplicaciones empresariales donde los desarrolladores deben centrarse en la funcionalidad en lugar de contar las referencias y los atributos de propiedad. O al menos automatice la mayor parte de eso con Xcode y el compilador. Dame un cambio que permita hacer ciertas suposiciones y que se pueda omitir en el código que elija el desarrollador (como: retener y @ sintetizar las propiedades de mis objetos de forma predeterminada, y, como el "real" ObjC 2.0, crear mis locales de respaldo para mi). Etc.
Rory Blyth

2
Básicamente, lo que estás diciendo es que escribamos aplicaciones de iPhone en C #. :)
Justin

3

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

Como los widgets HTML de Google Maps no son tan buenos como MapKit (consulte Google Latitude para ver un ejemplo), probablemente sea mejor desarrollar una aplicación nativa de Cocoa touch o elegir una solución que pueda ampliar 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 también podrían serlo.

editar: Titanium ahora tiene soporte para MapKit


Gracias. Pero, ¿hay alguna diferencia esencial entre PhoneGap y Titanium?
Mickey Shine

1
MapKit ha estado disponible de forma nativa en Titanium durante bastante tiempo.
jhaynie

@ jhaynie: gracias. He revisado este respuesta a reflejar que el titanio tiene ahora soporte (no lo hizo cuando fue escrito en septiembre)
rpetrich

1

He intentado corona. Fue bueno hasta que descubrí que no admite la transmisión de audio mp3. Entonces, me detuve allí. 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 estaciones de radio y si haces clic en ellas, comenzaría a reproducirse.


2
Corona admite la reproducción de archivos MP3 ( developer.anscamobile.com/reference/index/mediaplaysound )
Luc Stepniewski
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.