Appcelerator vs SDK de Android

Miramos a Appcelerator al iniciar nuestro proyecto de Android. Sabíamos que tendríamos que hacer un cliente de iOS a continuación, por lo que Appcelerator era tentador.

Decidimos no ir esa ruta porque no apoya todas las características nativas de cada dispositivo.

Por ejemplo, decidimos desde el principio que nuestra interfaz de usuario en Android necesitaría un widget. No hay soporte para eso en Appcelerator, ya que es específico para Android. [Esto fue hace unos meses -usted puede querer comprobar de nuevo].

Compromiso en la interfaz de usuario era demasiado para nosotros. Decidimos ir con C / C ++ para la lógica de la aplicación y usar Android SDK para la interfaz de usuario.

Nuestras aplicaciones ahora tienen dos partes: C / C ++ tanto como sea posible para los "cerebros" y el nativo (Android / Cocoa Touch) para la interfaz de usuario para aprovechar la experiencia de la interfaz de usuario.

Funciona por supuesto para plataformas que pueden integrar C / C ++.

El consejo de despedida: diseñar su interfaz de usuario en primer lugar, a continuación, encontrar una herramienta que puede implementar. Los usuarios tienen altas expectativas de la interfaz de usuario en dispositivos portátiles. Comprometiéndose en él temprano puede ser el KOD para su proyecto.

[EDIT] De vez en cuando veo un upvote para esta pregunta. Me gustaría actualizar con lo que aprendimos en los últimos dos años:

• El uso de C / C ++ para las partes comunes de nuestra aplicación ha dado sus frutos. Requiere un proceso de construcción un poco más complicado, pero los ahorros son gigantescos si el fragmento de código que se comparte es complejo (como en nuestro caso).
• Para la pieza de interfaz de usuario estamos empezando a buscar aplicaciones híbridas (algunos elementos de la interfaz de usuario en HTML). Todavía hay debates sobre las interfaces HTML (Facebook y LinkedIn son dos que se mueven a código nativo para la interfaz de usuario), pero también algunos informes que cuando se elige cuidadosamente funciona. Hay una gran charla de Flipoard en eso; Con diapositivas aquí .

ACTUALIZACIÓN Oct / 2014

En marzo / 2014 Smashing Magazine publicó un excelente artículo comparando iOS nativo, Android nativo, PhongeGap (Cordova) y Appcelerator Titanium. Muestran el desarrollo de una aplicación sencilla en cada entorno.

Esta es la última parte de la serie . En la parte superior de esta parte hay enlaces a las partes anteriores de la serie y en la parte inferior hay la comparación de los enfoques. También hay comentarios interesantes de los lectores al final.

ACTUALIZACIÓN Mayo / 2015

Aún así reciben un upvote para esta pregunta de vez en cuando, así que me gustaría compartir lo que hemos hecho desde que escribí la primera parte de la respuesta.

Ahora estamos trabajando en un proyecto que también tiene un cliente web. Ahora tenemos el cliente iOS, el cliente Android, además del cliente web.

JavaScript es la elección natural para el cliente web.

Dado que queremos compartir tanto código (en la capa de lógica de negocio) en estos clientes, significa que necesitamos encontrar una forma de ejecutar el código JavaScript en iOS y Android.

Y eso es lo que terminamos haciendo.

Este es un resumen de cómo lo manejamos:

• Para todos los clientes: todas las estructuras de datos se definen con el protobuf de Google . Esto permite generar automáticamente el código de serialización / deserialización para iOS y Android.
• IOS: ejecuta el código JavaScript con la ayuda de JavaScriptCore (una buena descripción aquí ).
• Android: ejecuta el código JavaScript con la ayuda del motor V8 de Google.

El puente entre JavaScript y la capa de iOS / Android puede ser un cuello de botella, especialmente la serialización de los objetos. Tuvimos que optimizar algunas cosas y aprendimos algunas lecciones para mantenerse fuera de problemas.

En general, la experiencia ha sido positiva. Guardamos una cantidad significativa de tiempo compartiendo el código entre todos los clientes.

Si tuviera que iniciar otro proyecto como éste (que requiere compartir código con clientes web y móviles), también echaré un vistazo a lo que hizo Google para la bandeja de entrada . No estaba disponible cuando empezamos. Parece prometedor.

ACTUALIZACIÓN Agosto / 2015

Y el mundo sigue girando …

También me gustaría echar un buen vistazo a React Native si tuviera que empezar una nueva aplicación móvil ahora.

Se basa en JavaScript, puenteando la web y el desarrollo móvil con mayor facilidad.

Hay un gran tutorial en el sitio de Ray Wenderlich .

ACTUALIZACIÓN Febrero 2016

Mi lista corta para el desarrollo multiplataforma es de dos:

• iónico
• Reaccionar nativo

He estado prestando más atención a iónicos porque nuestra aplicación web utiliza AngularJS y también lo hace iónico (Cordova + AngularJS). React Native forzará al equipo a aprender otro marco (por supuesto, el argumento es lo opuesto si su aplicación web usa React).

Sin embargo, consideraría seriamente React Native , incluso teniendo que aprender otro marco, debido al funcionamiento y mirada-y-sensación divulgados de la aplicación. Del sitio de React Native:

Con React Native, puede utilizar los componentes estándar de la plataforma como UITabBar en iOS y Drawer en Android

Si usted está comenzando ahora, le recomiendo tomar el tiempo para, como mínimo, completar sus tutoriales para que obtenga una mejor sensación de cada marco. Cada tutorial puede completarse en una o dos horas:

• Tutorial iónico
• React Native tutorial

Para un enfoque más simple: Smashing Magazine acaba de publicar (en el momento en que escribí esta actualización) un buen artículo que muestra cómo usar los elementos de navegación nativos para que la aplicación se sienta (bien …) nativa, mientras usa vistas web para procesar el contenido . El artículo entra en los detalles de cómo hacer el HTML / CSS utilizable en los dispositivos móviles (no es sólo empujando el HTML / CSS que ya tiene).

Si sólo se centran en desarrollar aplicaciones para la plataforma Android, le recomiendo que utilice Android nativo (Eclipse + Android SDK como usted ha dicho) en lugar de Titanium.

Razón: Titanio es adecuado si

1. Desea desarrollar aplicaciones de forma rápida o

2. Tus aplicaciones son simples o

3. Usted ve Java es tan difícil (tal vez: p), por lo que elegir el más fácil (Javascript de Titanio).

Y aquí están las razones por las que debe utilizar Android nativo en lugar Titanium:

1. Desea desarrollar una aplicación compleja, o

2. Desea personalizar la apariencia de la aplicación. Es muy importante. Imaging que hacer una aplicación para el cliente, y necesitan su aplicación para ser personalizado para más llamativo. La elección de titanio significa que debe utilizar su control, que carece de la capacidad de personalizar. Sería mejor si se utiliza Android nativo que se puede personalizar todo lo que quieras.

Que es una pregunta muy difícil de responder sin ninguna información específica sobre los requisitos de la solicitud.

Le sugeriría que eche un vistazo rápido a la documentación API de Appcelerator para ver lo que proporciona el marco y también tomar un momento para enumerar los requisitos básicos de su aplicación y luego determinar qué herramienta será mejor para su proyecto.

Creo que estás en un buen comienzo utilizando Appcelerator, ya que utiliza JavaScript, etc Fácil de aprender, pero buenos ejemplos. También le permitirá utilizar el mismo código y llegar a iPhone, iPad apps. Aprender a usar sólo el SDK de Android es más complicado. Incluso entonces usted todavía necesita para desarrollar aplicaciones iPhone más tarde. Si usted viene de un fondo web esto tiene sentido. Hay buenos videos para un aprendizaje rápido. Buena suerte

Mis experiencias con Appcelerator parecen sugerir que son más de una tienda iOS. Su conjunto de herramientas para Android es, IMHO, bastante carente. ADT admite la creación y depuración visual de interfaz de usuario en el dispositivo, que Titanium Studio no tiene. Ha habido un error presentado sobre esto desde hace varios meses, y sigue siendo retrasado. Si su enfoque es Android, utilice Google ADT o MOTODEV Studio para Android. Estos IDEs son bastante agradables y son utilizados por los profesionales.

La respuesta anterior presenta una gran manera de desarrollar aplicaciones móviles. NO COMPROMETIR EN UNA EXPERIENCIA DE USUARIO DE ALTA CALIDAD.

Falta de soporte bluetooth es una gran deficiencia para Appcelerator y nadie da una pista sobre la hoja de ruta.

Edit: appcelerator ahora tiene soporte BT en Tizen 3.1

Bueno, en la nueva versión de appcelerator (APPCELERATORSTUDIO 4.0) puedes tener proyectos de aleación, y algo así como archivos css para tu interfaz de usuario (tss), así que de hecho son realmente personalizables.

Greatings

Appcelerator tiene mucho soporte y es muy fácil de usar. Ahora es compatible con el 100% de las llamadas de api nativas. Tienen documentación muy buena también.