cordova - react - xamarin vs cordoba español

Xamarin 2.0 vs Appcelerator Titanium vs PhoneGap (6)

Visión general

Según lo informado por Tim Anderson

El desarrollo multiplataforma es un gran problema , y seguirá siéndolo hasta que llegue el día en que todos usen la misma plataforma. ¿Androide? HTML? WebKit? iOS? Windows? Xamarin? Titanum? PhoneGap? ¿Corona? ecc
Algunas veces escucho que se dice que hay esencialmente dos enfoques para las aplicaciones móviles multiplataforma. Puede usar un control de navegador integrado y escribir una aplicación web envuelta como una aplicación nativa , como en Adobe PhoneGap / Cordova o el enfoque similar adoptado por Sencha, o puede usar una herramienta multiplataforma que crea aplicaciones nativas , como Xamarin Studio, Appcelerator Titanium, o Embarcardero FireMonkey.
Dentro de la segunda categoría, sin embargo, hay diversidad. En particular, varían en función de la medida en que abstraen la interfaz de usuario.
Aquí está la compensación. Si diseña su marco multiplataforma, puede hacer que su aplicación funcione casi de la misma forma en todas las plataformas. Si comparte el diseño de la interfaz de usuario en todas las plataformas, es difícil hacer que su diseño se sienta igual de correcto en todos los casos. Podría ser mejor adoptar el enfoque adoptado por la mayoría de los juegos, utilizando un diseño que sea distintivo de su aplicación y hacer que su consistencia sea una virtud en todas las plataformas, aunque no tenga el aspecto y el estilo nativos de ninguna plataforma.

edit Xamarin v3 en 2014 comenzó a ofrecer Xamarin.Forms , así como nativos puros que aún siguen la filosofía mencionada aquí (se tomaron la libertad de editar en línea porque es una gran respuesta)

Por otra parte, Xamarin Studio no intenta proporcionar un marco de GUI compartido:

No intentamos proporcionar una capa de abstracción de interfaz de usuario que funcione en todas las plataformas. Creemos que es un mal enfoque que conduce a las interfaces de usuario con el denominador común más bajo. (Nat Friedman a Tim Anderson)

Esto es correcto; pero el inconveniente es el esfuerzo que implica mantener dos o más diseños de interfaz de usuario para su aplicación.

La comparación sobre PhoneGap y Titanium está bien informada en el blog Kevin Whinnery .

PhoneGap

El propósito de PhoneGap es permitir que las aplicaciones web basadas en HTML se implementen e instalen como aplicaciones nativas . Las aplicaciones web de PhoneGap están envueltas en un shell de aplicación nativa, y se pueden instalar a través de las tiendas de aplicaciones nativas para múltiples plataformas. Además, PhoneGap se esfuerza por proporcionar un conjunto de API nativo común que normalmente no está disponible para las aplicaciones web, como el acceso básico a la cámara, los contactos del dispositivo y los sensores que aún no están expuestos en el navegador.
Para desarrollar aplicaciones PhoneGap, los desarrolladores crearán archivos HTML, CSS y JavaScript en un directorio local, al igual que desarrollar un sitio web estático. Acercarse al rendimiento de la interfaz de usuario de calidad nativa en el navegador es una tarea no trivial: Sencha emplea a un gran equipo de expertos en programación web dedicados a tiempo completo para resolver este problema. Aun así, en la mayoría de las plataformas, en la mayoría de los navegadores actuales, simplemente no es posible alcanzar el rendimiento y la capacidad de respuesta de la interfaz de usuario de calidad nativa , incluso con un marco tan avanzado como Sencha Touch. ¿El navegador ya es "suficientemente bueno"? Depende de sus requisitos y sensibilidades, pero es indudablemente menos bueno que la IU nativa. A veces mucho peor, dependiendo del navegador.

PhoneGap no es tan multiplataforma como se podría creer, no todas las características son igualmente compatibles en todas las plataformas.

Javascript no es un lenguaje de programación a escala de aplicación, demasiadas interacciones de alcance global, bibliotecas diferentes que a menudo no coexisten bien. Pasamos muchas horas intentando que knockout.js y jQuery.mobile jueguen bien juntos, y todavía tenemos problemas.
Paisaje fragmentado para marcos y bibliotecas. Demasiadas opciones, y demasiadas no son lo suficientemente maduras.
Por extraño que parezca, para las necesidades de nuestra aplicación, se podría lograr un rendimiento decente (aunque no con jQuery.Mobile). Probamos jqMobi (no muy maduro, pero rápido).
Capacidad muy limitada para la interacción con otras aplicaciones o capacidades de dispositivos, y esto no sería multiplataforma de todos modos, ya que no hay estándares en HTML5, excepto algunos, como la geolocalización, la cámara y las bases de datos locales.

por Karl Waclawek

Appcelerator Titanium

El objetivo de Titanium Mobile es proporcionar un tiempo de ejecución de JavaScript multiplataforma de alto nivel y una API para el desarrollo móvil (hoy admitimos iOS, Android y Windows Phone. Titanium en realidad tiene más en común con MacRuby / Hot Cocoa, PHP o node). Js que con PhoneGap, Adobe AIR, Corona o Rhomobile. Titanium se basa en dos afirmaciones sobre el desarrollo móvil: - Existe un núcleo de API de desarrollo móvil que se pueden normalizar en todas las plataformas. Estas áreas deben destinarse a la reutilización del código. - Existen API, convenciones de UI y características específicas de la plataforma que los desarrolladores deben incorporar al desarrollar para esa plataforma. Debe existir un código específico de la plataforma para estos casos de uso para proporcionar la mejor experiencia posible.

Así que por esas razones, Titanium no es un intento de "escribir una vez, correr en todas partes" . Igual que Xamarin.

El titanio va a dar un paso más en la dirección similar a la de Xamarin. En la práctica, harán dos capas de diferentes profundidades: la capa Titanio (en JS), que le da una abeja JS-de-Titanio. Si desea ir a un nivel más bajo, ha creado una capa adicional (llamada Hyperloop), donde (siempre con JS) le devuelve la llamada directamente a las API nativas de SO

Xamarin (+ MVVMCross)

AZDevelop.net

Xamarin (originalmente una división de Novell) en los últimos 18 meses ha lanzado al mercado su propio IDE y complemento para Visual Studio. La premisa básica de Mono es crear aplicaciones móviles dispares que utilicen C # manteniendo las estrategias de desarrollo de la interfaz de usuario nativas.
Además de crear una plataforma de diseño visual para desarrollar aplicaciones nativas, tienen suites de prueba integradas, soporte de biblioteca nativa incorporada y una tienda de componentes de estilo Nuget. Recientemente proporcionaron el diseño visual de iOS a través de su IDE, lo que liberó al desarrollador de abrir XCode. En Visual Studio, las tres plataformas ahora son compatibles y una suite de pruebas en la nube está en el horizonte.
Desde el principio, Xamarin ha proporcionado una rica experiencia de diseño visual con Android. Todavía tengo que descargar o abrir Eclipse o cualquier otro IDE además de Xamarin. Lo que es realmente sorprendente es que puedo usar LINQ para trabajar con colecciones, así como para crear delegados y eventos personalizados que me liberen de las limitaciones de Object-C y Java. Muchas de las bibliotecas con las que he sido mimada, como Newtonsoft JSON.Net, funcionan perfectamente en los tres entornos.

En mi opinión hay varias GRANDES ventajas que incluyen

rendimiento nativo
Código más fácil de leer (IMO)
probabilidad
Código compartido entre cliente y servidor
Soporte (aunque Xam podría hacerlo mejor en bugzilla)

Actualizar para mí es utilizar Xamarin y MVVMCross combinados. Todavía es un marco bastante nuevo, pero nace de la experiencia de varios otros marcos (como MvvmLight y monocross) y ahora se ha utilizado en varios proyectos multiplataforma publicados.

Conclusión

Mi elección, después de conocer todos estos marcos, fue seleccionar una herramienta de desarrollo basada en las necesidades del producto . En general, sin embargo, si comienza a utilizar una herramienta con la que se sienta cómodo (incluso si requiere un mayor costo inicial) después de usarla para siempre.

Elegí Xamarin + MVVMCross y debo decir que estoy contento con esta elección. No tengo miedo de acercarme a Native SDK para obtener actualizaciones de software o ver la funcionalidad limitada de un sistema o lo más trivial de una característica de gráficos. Escribir código bastante estructurado (DDD + SOA) es muy útil para tener un proyecto central compartido con la implementación nativa de vistas de C #.

Referencias y enlaces

Esta pregunta ya tiene una respuesta aquí:

Comparación entre Corona, Phonegap, Titanium 14 respuestas

Después de todas las evoluciones de IDE (todas las plataformas sobre el tema han cambiado) de este año, busco entender cuál es el estado de la tecnología para esas plataformas.

¿Cuáles son las fortalezas y debilidades de cada uno? ¿Hay algunas limitaciones de uno de esos enfoques?

Tengo una buena experiencia en C # y Javascript, que no hay influencia de lenguaje programático que pueda inclinarse hacia un lado.

Como alternativa, puede consultar BridgeIt en bridgeit.mobi. De código abierto, resolvió el problema de rendimiento / coherencia del navegador descrito anteriormente, ya que aprovecha el navegador estándar en el dispositivo frente al navegador de vista web. También le permite acceder a las funciones nativas sin tener que preocuparse por las implementaciones de la tienda de aplicaciones y / o los contenedores nativos.

Lo he usado para acceso simple basado en cámara y acceso de escáner y funciona bien para aplicaciones simples. La documentación es un poco ligera. No estoy seguro de cómo lo haría en aplicaciones más complejas.

He trabajado con Xamarin. Aquí están los aspectos positivos y negativos que he encontrado:

Positivos

Fácil de codificar, C # facilita el trabajo
El rendimiento no será una preocupación
Interfaz de usuario nativa
Buen IDE, al igual que Xcode y Visual Studio.
Depurador de Xamarin
Xamarin SDK es gratuito y de código abierto. Wiki

Negativos

Debe conocer la API para cada plataforma a la que desea dirigirse (iOS, Android, WP8). Sin embargo, no es necesario conocer Objective-C o Java.
Xamarin comparte solo algunas cosas a través de plataformas (cosas como bases de datos y servicios web).
Tienes que diseñar la interfaz de usuario de cada plataforma por separado (esto puede ser una bendición o una maldición).

No he trabajado mucho con Appcelerator Titanium, pero al final lo entenderé.

Puedo hablar un poco más sobre las diferencias entre PhoneGap y Xamarin, ya que trabajo con estos dos (o más) días a la semana.

Si ya está familiarizado con C # y JavaScript, entonces la pregunta es, ¿la lógica de negocios se encuentra en un área más adecuada para JavaScript o C #?

PhoneGap

PhoneGap está diseñado para permitirle escribir sus aplicaciones utilizando JavaScript y HTML , y gran parte de la funcionalidad que proporcionan está diseñada para imitar las especificaciones propuestas actuales para la funcionalidad que eventualmente estará disponible con HTML5. El gran beneficio de PhoneGap en mi opinión es que, dado que estás haciendo la interfaz de usuario con HTML, se puede portar fácilmente entre plataformas . El inconveniente es que, como está portando la misma interfaz de usuario entre plataformas, no se sentirá como en casa en ninguna de ellas. Lo que significa que, sin más ajustes, no puede tener una aplicación que se sienta como en casa en iOS y Android , lo que significa que tiene el estilo de iOS y Android. La mayoría de su lógica se puede escribir utilizando JavaScript, lo que significa que también se puede portar entre plataformas . Si la API de PhoneGap actual hace la mayor parte de lo que desea, entonces es bastante fácil ponerse en marcha. Sin embargo, si hay cosas que necesitas del dispositivo que no están en la API, entonces te metes en la diversión del desarrollo de complementos , que estará en el lenguaje de desarrollo del dispositivo nativo elegido (con una advertencia, pero llegaré a that), lo que significa que probablemente necesite ponerse al día rápidamente en Objective-C, Java, etc. Lo bueno de este modelo es que, por lo general, puede adaptar muchas bibliotecas nativas diferentes para cumplir su propósito, y muchas bibliotecas ya tienen Plugins de PhoneGap . Aunque es posible que no tenga mucha experiencia con estos idiomas, habrá al menos una gran cantidad de ejemplos para trabajar.

Xamarin

Xamarin.iOS y Xamarin.Android (también conocidos como MonoTouch y MonoDroid), están diseñados para permitirle tener una biblioteca de lógica empresarial , usarla dentro de su aplicación y conectarla a su interfaz de usuario. Debido a que se basa en .NET 4.5, obtienes notables lambda notaciones , LINQ y un montón de otros aspectos de C #, lo que puede hacer que escribir tu lógica empresarial sea menos doloroso. El inconveniente aquí es que Xamarin espera que usted desee que sus aplicaciones se sientan realmente nativas en el dispositivo, lo que significa que probablemente terminará reescribiendo su IU para cada plataforma , antes de conectarla con la lógica empresarial. He oído hablar de MvvmCross , que está diseñado para hacer esto más fácil para usted , pero todavía no he tenido la oportunidad de investigarlo. Si está familiarizado con el sistema MVVM en C #, es posible que desee echar un vistazo a esto. Cuando se trata de bibliotecas nativas, MonoTouch se vuelve interesante. MonoTouch requiere una biblioteca de enlaces para indicar a su código C # cómo vincularse con el código subyacente de Objective-C y Java . Algunas de estas bibliotecas ya tendrán enlaces, pero si las suyas no tienen, crear una puede ser interesante. Xamarin ha creado una herramienta llamada Objective Sharpie para ayudar con este proceso, y en su mayor parte, obtendrá el 95% del camino . El 5% restante probablemente tomará el 80% de su tiempo intentando enlazar una biblioteca.

Actualizar

Como se señala en los comentarios a continuación, Xamarin ha lanzado Xamarin.Forms que es una abstracción multiplataforma en torno a los componentes de la interfaz de usuario específicos de la plataforma. Definitivamente vale la pena el look.

PhoneGap / Xamarin Hybrid

Ahora porque dije que lo haría, la advertencia mencionada anteriormente en PhoneGap es un enfoque híbrido , en el que puede usar PhoneGap para la parte y Xamarin para la parte. Tengo bastante experiencia con esto y le advierto que no lo haga . Altamente El problema con esto, es que es una tierra tan noble que si alguna vez te encuentras con un problema, casi nadie se habrá acercado a lo que estás haciendo y cuestionará lo que estás tratando de hacer. Es factible, pero definitivamente no es divertido .

Appcelerator Titanium

Como mencioné anteriormente, no he trabajado mucho con Appcelerator Titanium, por lo que para las diferencias entre ellos, le sugeriré que compare Comparing Titanium y Phonegap o Comparison entre Corona, Phonegap, Titanium ya que tiene una descripción muy detallada de las diferencias. . Básicamente, parece que a pesar de que ambos usan JavaScript , la forma en que ese JavaScript se interpreta es ligeramente diferente. Con Titanium, escribirás tu JavaScript en el Titanium SDK , mientras que con PhoneGap, escribirás tu aplicación usando la API de PhoneGap . Como PhoneGap es muy compatible con los estándares de HTML5 y JavaScript, puede utilizar prácticamente cualquier biblioteca de JavaScript que desee, como JQuery. Con PhoneGap tu interfaz de usuario estará compuesta de HTML y CSS. Con Titanium, se beneficiará de su multiplataforma XML que parece generar componentes nativos . Esto significa que definitivamente tendrá una mejor apariencia nativa.

Phonegap es bastante lento: hacer clic en un botón puede tardar hasta 3 segundos en mostrar la siguiente pantalla. iscroll es lento y nervioso.

Hay otros errores divertidos y problemas que pude superar, pero en total, no han madurado completamente.

EDIT: Según el comentario de Grumpy, no es Phonegap quien es realmente lento, es el motor nativo de JS / Browser

También hay esteroides AppGyver que combinan muy bien con PhoneGap y la interfaz de usuario nativa.

Con los esteroides puede agregar elementos como pestañas nativas, barra de navegación nativa, animaciones y transiciones nativas, ventanas modales nativas, cajón / panel nativo (menú lateral de Facebook), etc. a su aplicación PhoneGap.

Aquí hay una demostración: http://youtu.be/oXWwDMdoTCk?t=20m17s