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.]