¿Conocéis la canción esa de “chapuza sobre chapuza, y sobre chapuza una…”? Pues más o menos así es.

Ahora que Xamarin es gratis, y como todo jodío developer que se precie, me he liado la manta a la cabeza y me he puesto a hacer una aplicación Universal de verdad, de las que pueden funcionar en todas las plataformas actuales: iOS, Windows Phone, OS X, Windows…

El resultado después del corte.

La gente de QT deben estar partiéndose la caja con todo esto. En fin. Empezamos.

El primer tropezón viene cuando uno abre la ventana de crear proyecto de Visual Studio y se topa en la cara con varias decenas de proyectos universales bajo cada uno de los lenguajes.

¿Cuál elegir?¿ Ah, amigo, primero tienes que hacerte el máster de saber qué es cada cosa. Aquí viene en nuestra ayuda el amigo Peztold, gracias al libro que la propia Xamarin regala.

En las primeras páginas te lo explica más o menos: tienes que elegir el tipo de proyecto que está en C# -> Cross Platform -> Blank App (Xamarin.Forms Portable).

Bueno, ya hemos pasado el primer escollo. Después de aceptar la creación de la Solución. Hay que esperar un buen rato. Pero buen rato. Puedes hacerte un café.

Al terminar, te dice que conectes con tu MAC. Lo que no te dice, ni en la ayuda ni en ningún lado, es que tienes que tener Xamarin instalado en el MAC. Sí, evidente, Vicente, para quien lo ha implementado. Para un developer luser eso no es tan evidente. No lo fue para mi.

Ah, ¿pensabas que para hacer una app iOS no ibas a necesitar un MAC? Eso sería como si Steve Jobs no hubiera aparcado en las plazas de minusválidos, o no hubiera cambiado de coche cada mes para no pagar el coste de la matriculación. Quizás en otro universo. En este no.

(También es cierto que puedes ignorar esa pantalla y al menos, compilar, vas a poder compilar sin un MAC).

Un rápido vistazo al árbol de la solución te pone los pelos como escarpias. ¡6 Proyectos diferentes! ¡6 putos proyectos!

Vale, vale, me estoy pasando de crítico. Es lógico que así sea, porque hay un proyecto para:

• iOS
• Android
• Windows Universal (UWP)
• Windows 8
• Windows Phone 8
• Portable

¿Portable? Ajajá, ahí es donde va todo el código común a todas las aplicaciones. ¿Cuánto? Pues no lo sé (o más bien sí, luego lo veremos).

Lo que sí tengo claro es que podemos añadir una más: WPF, para hacer una aplicación .NET tradicional (en cursiva, porque WPF de tradicional tiene poco). Después de eso solo hay que añadir la referencia de la Portable.

Ahora a tirar líneas de código, ¿no? Pues no, ahora tienes que crear la intefaz de tooooodas y cada una de las plataformas.

¿Portable? Tus muertos.

Para más inri, este tipo de aplicación exige que cada proyecto tenga su propia interfaz. Creo, y solo creo porque no lo he probado ni lo voy a hacer, que hay otro tipo de proyecto que puede compartir interfaz.

—

Bueno, ahora a compililar, digo compilar. Control, Mayúsculas y la letra B.

¡Ja!

No compilila.

No lo hace porque faltan referencias. Es decir, todavía hay que añadir más paquetes, casi a mano.

Yo me pregunto, ¿habrá alguien, con la versión definitiva de esto, probado en una máquina limpia, si este tipo de proyecto funciona de verdad simplemente sacado de la caja.

Sinceramente lo dudo mucho no, muchísimo. Casi estoy convencido de ello, estoy convencido de que la persona de QA que hacía estas pruebas fue directo al puta calle en el último despido masivo.

Al final se soluciona. Uno va a Tools -> Options -> NuGet Package Manager -> Package Sources y marca la casilla de “Microsoft and .NET”.

Después de un rato de bajar paquetes, ahora sí, ahora compila bien. También ejecuta, aunque solo he probado la UWP y la XAML. No tengo ganas de configurarme un emulador Android o de tener que trastear con el Mac.

—

Vale, ya tenemos toda la ferretería en su sitio. Ahora a picar código como un loco.

La primera en la frente.

Creamos una clase en la parte portable. Picamos la línea

if(File.Exists(…

¡Zas en toda la boca! Nos dice que “usemos” System.IO.

¡Zas, en toda la boca! File no está en System.IO para portables. F1.

¡Zas, en toda la boca! Nada sobre ello. ¿Por qué cojones el asistente primero me dice que “use” System.IO si esa clase no está.

Primer bug asqueroso.

Miramos en la ayuda y vemos un ejemplo hecho con StreamReader…

Copiamos y pegamos.

¡Zas, en toda la boca! StreamReader no acepta una cadena como nombre de fichero, aunque la documentación diga que sí.

Volvemos a pulsar F1 sobre StreamReader. Nos lleva a una página en la que tenemos otro ejemplo, esta vez con FileStream.

¡Zas, en toda la boca! Tampoco está FileStream, pero el sistema de ayuda contextual nos ofrece PipStream…

…

…

¡Que, jodidamente, tampoco está disponible!

—

¿Sabéis una cosa?

A TOMAR POR CULO

No me quejo del deficiente sistema de ayuda, que yo pensaba no podía llegar a un peor nivel, pero parece que sí.

No me quejo del deficiente sistema de IntelliSense, porque posiblemente el culpable sea Visual Assist, que tengo instalado.

Simplemente, yo ya estoy demasiado mayor para estos combates.

Y si queréis saber la opinión de alguien con más de 20 años en el mundo del desarrollo: a esto le faltan un par de años, siendo de Microsoft, entre cinco y diez. Espero que no se aburran antes y sean ellos los que abandonen.