¿Cómo puedo decirle a mi jefe de trabajo con Xamarin no lo hará más rápido

Soy el único desarrollador móvil en mi trabajo. Antes de ser contratado, mi actual jefe estaba pensando en usar Xamarin como su comercialización dice las palabras código compartido y nativo . Me considero un desarrollador de Android avanzado desde que he construido grandes sistemas de información. En este momento estoy trabajando en aplicaciones sencillas que podría terminar en una semana, pero Xamarin me está dando dolor de cabeza ya que su demasiado buggy, y el código reutilizable es de alrededor del 10% que podría ser copiado / pegado en iOS , ya pesar de que Usted puede compartir ese código del 10%, a veces usted todavía tiene que utilizar directivas de la compilación #if / #endif .

Quiero decir, no hay realmente ninguna ventaja para mí, ya que ya conozco los lenguajes Java y Objective-C . Ya tengo un amplio conocimiento de SQLite y almacenamiento de datos con Core Data tanto en iOS como en Android SDK para que aprender Xamarin lo haga más lento.

Ya he tratado de decirles que no vayan a Xamarin ya que es sólo un pequeño código que pueden compartir, pero no parecen entender.

Necesito un buen argumento para convencerlos de que no lo compre, para poder hacer mi trabajo de una manera más productiva y más rápida. Gracias de antemano.

Algunos buenos puntos del blog de Lee Whitney: ¿Por qué no recomiendo Xamarin para el desarrollo móvil :

Sobrecarga de la aplicación

Las aplicaciones basadas en Xamarin tienen un overhead que las hace más grandes en promedio. Esto afecta el tiempo de descarga y el almacenamiento que se utiliza en un dispositivo. El tamaño adicional mínimo suele ser de unos pocos megabytes y puede crecer proporcionalmente a medida que el código utiliza más API. Esto se debe a la forma en que el código de los ensamblados .NET está enlazado estáticamente (como código nativo) en aplicaciones a medida que se hace referencia a los ensamblados. En Android también hay un retraso de inicio adicional para aplicaciones por razones específicas del sistema operativo. Para el crédito de Xamarin esta sobrecarga solía ser mucho mayor y la compañía ha hecho grandes progresos en su reducción. Sin embargo, el impacto en los usuarios de aplicaciones es aún medible.

Intercambio limitado de código de interfaz de usuario a través de iOS y Android

El desarrollo de la interfaz de usuario no es portátil entre iOS y Android.
Esto significa que las API, la lógica de eventos, los widgets y los diseñadores deben utilizarse y codificarse de forma diferente para cada plataforma. Hay algunas excepciones a esto para operaciones comunes de bajo nivel.

Xamarin argumentaría que tratar de abstraer API de interfaz de usuario a través de plataformas muy diferentes puede crear complejidad innecesaria o conducir a una experiencia de usuario pobre con un diseño LCD (denominador común más bajo). Tienen un punto aquí. Titanium intenta hacer esto parcialmente, y el resultado ha hecho a muchos desarrolladores descontentos con los resultados inconsistentes o impredecibles. Las aplicaciones HTML5 tienen más éxito al sacar esta abstracción de la interfaz de usuario sin forzar el diseño de una pantalla LCD, pero no tienen el rendimiento nativo de Xamarin.

Los problemas de la interfaz de usuario pueden ser algunos de los aspectos que más tiempo consumen en el desarrollo de aplicaciones para móviles. A pesar de tener una buena justificación, la importante para llevar es que para muchos problemas de la interfaz de usuario móvil, Xamarin no ahorrará tiempo a los desarrolladores o diseñadores.

Compartición limitada de código fuera de Xamarin

Xamarin no permite la creación de componentes o módulos reutilizables fuera de su propio entorno. Por ejemplo, el código escrito en Xamarin no se puede utilizar en aplicaciones nativas o HTML5. Esto significa que cualquier código desarrollado por un equipo que utiliza Xamarin no puede ser compartido o reutilizado con equipos que usen cualquier otro tipo de herramientas para iOS y Android. Cuánto esto importa depende de la situación, pero el problema con el desarrollo es que no podemos predecir todas nuestras situaciones. Así que es una limitación incómoda tener derecho fuera de la puerta.

Ecosistema y Comunidad

Esto es algo que no es culpa de Xamarin. ¿Qué compañía tiene un ecosistema móvil que coincide con Apple, Google o HTML5? Sin embargo, importa. Cuando los desarrolladores tienen 10 veces más probabilidades de encontrar resultados al buscar en la Web acerca de un problema, afecta directamente la productividad. El ecosistema de soporte disponible, servicios y componentes de terceros, y herramientas relacionadas es, y continuará siendo, significativamente más pequeño que para aplicaciones nativas o basadas en HTML5.

La tercera curva de aprendizaje

Algunos conceptos y técnicas requieren un conocimiento especial específico para el entorno Xamarin. Esto agrega efectivamente una tercera curva de aprendizaje para los desarrolladores más allá del lenguaje de programación y las API nativas. Por ejemplo, los desarrolladores tienen que entender el recuento de referencia de iOS para evitar problemas con la recolección de basura de Xamarin ( ¿Es esto un error en MonoTouch GC? ). Otro ejemplo son las estructuras de datos y genéricos que trabajan de formas sutilmente diferentes ( http://docs.xamarin.com/guides/ios/advanced_topics/limitations ). Estos son los tipos de problemas que son difíciles de ver antes de adoptar una nueva plataforma, por lo que merecen consideración especial.

Más piezas móviles

Xamarin presenta su propio conjunto de errores que afectan la calidad del producto y la productividad del desarrollador. El problema no es que Xamarin tiene un mal producto, pero que agregar cualquier sistema grande o complejo a la cadena de herramientas de la aplicación viene con problemas y errores que no existen en aplicaciones nativas.

El registro histórico de estos errores puede ser revisado usando el rastreador de errores de Xamarin ( https://bugzilla.xamarin.com ).

Sí, todo el software tiene errores. El punto es cuando se mide la ventaja de agregar nuevas herramientas; La desventaja de los nuevos problemas debe tenerse en cuenta.

Resumen

Al final tenemos que tratar de cuantificar los beneficios de una abstracción de desarrollo como Xamarin sobre otras abstracciones, o sobre el desarrollo nativo. ¿Es C # mejor que Objective-C? Sí, de lejos en mi opinión, pero eso es sólo un factor. Al agregar todo lo que las puntas de las escalas lejos de Xamarin en favor de otros enfoques para el desarrollo móvil. A partir de 2013 (este material puede cambiar rápidamente) Tiendo a elegir una solución de código nativo o una solución HTML5 / Cordova. Me gustan ambos por diferentes razones y trataré de explicar algunos de los factores de decisión en otro artículo.