jueves, 28 de abril de 2016

Lo bueno, lo malo y lo feo de Xamarin (Mi experiencia con Xamarin)

Decidí escribir este post para hablar un poco como me ha ido estos últimos años trabajando con Xamarin y compartir algunos aspectos que pueden ser de ayuda cuando hay que decidir entre usar esta plataforma o crear apps nativas.

Los últimos tres años he trabajado con Xamarin (Xamarin.Android y Xamarin.iOS no he usado Xamarin.Forms en proyectos "reales") creando todo tipo de apps y en distintos escenarios, he creado apps para las plataformas móviles, otra que solo son Android y Desktop, una mas que además de los móviles comparte código con una pagina web, apps que se ejecutan en tabletas Android con hardware a la medida, he integrado dispositivos de hardware de terceros, entre otras cosas.

A lo largo de esos desarrollo me he encontrado con muchos retos, retos técnicos relacionados directamente al código que estoy creando y otros relacionados a los factores que son importantes durante el desarrollo, por ejemplos los entornos de desarrollo, la documentación, la calidad del soporte técnico de Xamarin, etc.

Básicamente en ese contexto ha sido mi trabajo y partiendo de eso voy a escribir sobre las cosas que mas me han gustado y las que no me han gustado sobre esta plataforma, por supuesto hay mas cosas que puedo no estar mencionando.



Lo bueno


1 – Uso de código .NET

La causa por la que se decidió usar Xamarin en la empresa en la que trabajo fue porque ya se tenía una lógica de negocios en C# (mas de 50 clases), la cual llevaba muchos años funcionando en ambientes “tradicionales” (desktop y servidor). Para usar esta lógica en Xamarin.Android y Xamarin.iOS fue tan simple como compartir el proyecto Core con estas plataformas usando un plugin para Visual Studio (Project Linker, *ya VS permite hacerlo sin plugins), en el caso de WP hubo que modificar algunas clases por unas mas modernas para el manejo de XML, lo mejor es que esta actualización de clases funcionaba en las demás plataformas, de este modo no hubo que mantener varias versiones del Core.


2 – El soporte técnico

Otra de las ventajas es el soporte técnico, en general cuando he preguntado algo al mail de soporte obtengo respuesta al siguiente día hábil y siempre me ha respondido gente con toda la disponibilidad de resolver el resolver el problema.


3 – La documentación

La documentación es muy completa, prácticamente todo lo necesario para comenzar se encuentra en su sitio web para desarrolladores, también los errores mas comunes ya tienen respuesta en su foro o en sitios como stackoverflow. Si eso no funcionaba había mucha documentación buscando como MonoDroid y MonoTouch (antecesores de Xamarin.Android y Xamarin.iOS) aunque hace mucho tiempo que no he tenido que recurrir a eso.


4 – Uso de código Java y Objective C

Algo que me ha parecido muy bueno es la capacidad de poder utilizar librerías nativas en los proyectos Xamarin, por ejemplo si por cuestiones de tiempo o falta de experiencia es necesario el apoyo de alguien que solo conoce de Android con Java u iOS con Objective C, para mi ha sido muy sencillo que esta persona de apoyo encapsule todo en una librería nativa y yo consumirla desde Xamarin. 


5 – Curva de aprendizaje para iOS

De las cosas que mas me han gustado de iOS es que no es necesario conocer Objective C para poder crear apps si solo usaremos código C# sin usar alguna librería creada en Objective C podemos manejar métodos, el ciclo de vida, objetos, etc. como en cualquier programa .Net con C#, por ejemplo no es necesario crear outlets y actions de manera manual cuando se trabaja con interfaces gráficas, Xamarin hace esto transparente para nosotros.


6 - ALM

Finalmente algo que me ha funcionado perfectamente bien es la integración con Visual Studio Team Services para el control de código fuente, nunca he tenido problemas con los diferentes archivos que se usan para el trabajo con las apps Xamarin.Android o Xamarin.iOS. Hace poco comencé a probar HockeyApp en una de mis apps y ha funcionado de maravilla.


Lo malo y lo feo


1 – Actualizaciones

Creo que una de las cosas que deben mejorar es el tema de las actualizaciones, en ocasiones cuando he actualizado cualquier cosa del entorno (principalmente la Mac) todo deja de funcionar, por ejemplo una vez salió una versión nueva de Xamarin Studio en el canal “estable” de actualizaciones y dejo de funcionar todo mi proyecto de iOS, tuve que regresar a la versión anterior (un proceso muy tedioso) y esperar a una versión mas actual para poder actualizar. Contactando al soporte me pedían usar una versión Beta, lo cual para una app empresarial conlleva ciertos riesgos.  Creo que si el instalador de actualizaciones y/o el IDE verificaran las versiones compatibles de ambiente (Sistema Operativo, XCode, Java, etc. ) se evitarían estos problemas o sería mas fácil saber que corregir.


2 – Soporte técnico

Otro tema es que aunque el soporte es muy amable y busca solucionar los problemas, siempre solicitan el código fuente de tu proyecto que falla, lo cual es difícil porque no siempre puedo obtener autorización para andar enviando proyectos por correo. Algo importante que mencionar es que generalmente los problemas son del entorno de desarrollo y no del código por lo cual no me hace sentido que me pidan el código si les informo de un problema de con el diseñador de interfaces de Android o si Visual Studio se cierra cuando quiero ver las propiedades del proyecto y eso no sucede en Xamarin Studio. Los logs que genera Xamarin tanto en PC o en Mac tiene mucha información y muy rara vez los solicitan, por lo cual si uno no sabe de su existencia puede perder mucho tiempo antes de que ellos los soliciten, explicando de donde se deben obtener.


3 – Dificultad para usar librerías Objective C

Es muy útil poder usar código nativo sin embargo en el caso de iOS es un poco complicado hacer los binding para utilizar librerías nativas en el proyecto Xamarin,   hay que tener conocimientos medianamente solidos de Objective C, lo cual quita la ventaja de la curva de aprendizaje si nuestro proyecto depende de algo ya creado de manera nativa, por ejemplo el SDK de un dispositivo de hardware.


4 – Dificultad para ejecutar un proyecto nuevo

Uno de los temas que no me parece muy grave pero si es un poco molesto es lograr que un proyecto se ejecute por primera vez, sobre todo Xamarin.Forms. Entre errores por la descarga de paquetes nuget, errores con las API de Android seleccionadas por defecto, etc. podemos perder un par de horas (sobretodo si estamos empezando a conocer la plataforma) en lograr ejecutar el proyecto en blanco. La parte rescatable es que mucho errores son comunes y la solución es fácil de encontrar en los foros de Xamarin, la otra parte buena es que después de que logramos ejecutarlo casi nunca vuelve a haber problemas de este tipo a lo largo del desarrollo.


5 – Integración con Visual Studio

Por último algo que creo debe mejorar mucho (sobretodo ahora que están pidiendo que se use Visual Studio y nos olvidemos de Xamarin Studio para PC) es el soporte para Visual Studio, este es demasiado inestable cuando se trabaja con Xamarin, en ocasiones un mismo proyecto puede funcionar perfecto en Xamarin Studio y no en Visual Studio. Es importante aclarar que no he tenido ningún problema de estabilidad con las apps ya empaquetadas,.



Al final ¿recomiendas Xamarin?

Si lo recomiendo, les puedo decir que es una plataforma muy buena para el desarrollo de apps iOS y Android (Mac no lo he usado) y fácilmente se integra con proyectos Microsoft .NET (Desktop, Web, Consola, ensamblados dll, etc.). La plataforma aun tiene mucho por mejorar (en ocasiones hay que tener mucha paciencia, sobretodo siendo nuevo) sin embargo al día de hoy no tengo quejas en cuanto a la estabilidad de los productos finales y creo que la clave para lograr crear aplicaciones que aprovechen esta plataforma esta en entender los conceptos básicos sobre los diferentes tipos de proyectos y las estrategias para compartir el código, de lo contrario se terminan haciendo aplicaciones nativas independientes con la diferencia de usar C# en lugar de Objective C y Java.

miércoles, 6 de abril de 2016

Haciendo deployment a un dispositivo Android mediante la red TCP IP

En este pequeño tutorial voy a demostrar como se puede hacer la instalación de una app a un dispositivo Android usando la red en lugar del cable USB. Hay varios escenarios donde esto puede ser útil, dos de los casos con los que me he encontrado son los siguientes:
  • Alguna vez tenia que instalar y debuggear una app en un dispositivo hecho a la medida, que tenia Android como Sistema Operativo y del cual no me dieron los driver para el USB y el dispositivo tenia acceso Root y la Terminal funcionando.
  • Actualmente trabajo con una MacBook Pro donde tengo virtualizado Windows con Parallels, esto para poder trabajar con Visual Studio conectado a los Visual Studio Team Services. Para no instalar dentro de la maquina virtual el emulador “Android Player” que provee Xamarin, lo cual no parece una buena idea, lo que hice fue instalar el Android Player en la maquina host y conectarlo a la maquina virtual mediante la red que se crea entre las dos maquinas.
Como lo mencione hace unas líneas para este ejemplo estoy utilizando lo siguiente:
  • Una MacBook Pro con OS X El Capitan
  • Windows 10 virtualizado con Parallels
  • Android Player con una instancia de un Nexus 4 con Lollipop
  • En ambos sistemas tengo Xamarin con todas sus actualizaciones tanto de Xamarin como de XCode en el caso de OS X
En el caso del emulador ya viene configurado con las opciones de desarrollador activadas y listo para el debug mediante TCP. En el caso de un dispositivo físico hay que usar estos comandos antes de realizar la conexión

En un dispositivo con acceso Root desde la terminal usamos los siguientes comandos
su
setprop service.adb.tcp.port 5555
stop adbd
start adbd

En este caso no hablare de un dispositivo sin acceso Root el cual de inicio debe conectarse por USB para habilitar el Debug por TCP.

Ya que tengamos nuestro dispositivo listo continuamos abriendo la consola “Android ABD” desde Visual Studio, podemos hacer la ejecución desde la consola normal solo si tenemos las variable de entorno bien configuradas o si usamos la ruta completa de donde tengamos abd.exe. En el caso de abrir la consola desde Visual Studio esta consola ya esta lista para trabajar sin escribir toda la ruta, para hacerlo presionamos el siguiente icono

image

O podemos acceder desde el menú Tools/Android/Android Adb Command Prompt
En nuestro Android Player presionamos el siguiente botón para obtener la dirección IP asignada al emulador

image
image

Ahora en la consola realizamos la conexión con el siguiente comando
adb connect <Dirección_IP>

image

Si obtenemos las respuesta “connected to” ya se realizo la conexión, tras esto ya podríamos hacer el deployment en el dispositivo conectado como lo hacemos normalmente seleccionando el dispositivo desde la barra de herramienta de VS

image

NOTA: si no aparece el dispositivo hay que intentar reiniciando VS para que lo muestre.