Hace unos días Microsoft unificó las cuentas de desarrollador, con lo que ahora sólo hay un tipo de programador. Es decir, ya tuvieras una cuenta para crear aplicaciones para Windows Phone o para Windows 8, o ambas, ahora sólo tienes una.
Es un primer paso para una supuesta unificación de todas las plataformas de Microsoft en una sola. En esta entrada os voy a contar mis elucubraciones sobre todo ello.
Tras la infausta actualización a Windows 8.1 de mi Surface PRO, que al final se llevó a cabo de forma satisfactoria tras muchos problemas, mi confianza ha vuelto, en cierta medida, a la plataforma.
Como consejo, todos aquellos que hayáis actualizado a Windows 8.1 desde 8.0 y podáis revertir el proceso, hacedlo y volved a pasar de la 8.0 a la 8.1 porque parece ser que Microsoft ha actualizado cosas en la descarga de la Tienda y ahora sí, ahora el paso de uno a otro se ha llevado a cabo sin traumas en mi PRO.
Dicho esto, y como programador Windows con bastante experiencia a la espalda, me gustaría comentar por aquí qué pienso de todo esto sobre los pasos que Microsoft está dando con el fin de unificar el sistema operativo del teléfono con el de las tabletas.
De hecho, ya se han dado algunos pasos en ese sentido. Por un lado, Windows 7 sólo tenía la interfaz de escritorio que, pese a haber cambiado a lo largo de los años, el concepto y, sobre todo, la interfaz de programación, ha sido la misma. Es decir, en principio siempre ha dado igual cómo se ha visualizado una ventana. Internamente se ha controlado de igual forma desde los tiempos de Windows 1. Se podrán haber hecho “envoltorios” como MFC o .NET, pero debajo de todo el funcionamiento ha sido, siempre, el mismo.
Pero en Windows 8 Microsoft creó una nueva interfaz que llamó Modern UI (aunque en un origen fue “Metro”, que tuvieron que cambiar por problemas de derechos). Esa interfaz es la típica de las tabletas, con todo lleno de cuadrados. En otras palabras, hemos cambiado el concepto de “ventana” por el de “cuadrado”. La interfaz de desarrollo también ha cambiado. No mucho pero lo ha hecho.
Por otro lado teníamos Windows Mobile, que era una compilación especial de Windows CE. Este sistema operativo compartía interfaz de programación con el escritorio clásico incluso cuando se desarrollaba para WM. La última versión de este sistema fue la 6.5.
Ocurrió que las compañías se cansaron de crear aplicaciones para este entorno, justo cuando Apple sacó su iPhone y Google se apresuró a cambiar la interfaz de Android, que imitaba a la de BlackBerry, por la de iOS, generando en el camino una serie de problemas y de ineficiencias que justo ahora están siendo remediadas…
Microsoft lo que hizo fue detenerse por completo y no sacar nada. Ignoro si Ballmer tuvo algo que ver o fue simplemente un consenso dentro de la empresa. De lo que estoy seguro es que Microsoft perdió una oportunidad de oro. O no. Todavía está por ver.
Windows Mobile tenía (tiene) un núcleo muy bueno, que es un subconjunto del núcleo de Windows. Digamos que las tripas de WM respecto a las de Windows eran lo que son las tripas de iOS respecto de las de OS X: un gran subconjunto.
Un par de años después (creo), sacó Windows Phone. Primero una versión 7.0 y luego otra, la 7.1 que se llamó 7.5 pero que internamente tenía en número de versión anterior. Posteriormente salió la 7.8 que incorporaba algunas de las mejoras de la 8.0, que es la actual.
Windows Phone es un nuevo concepto de interfaz gráfica perfectamente adaptada al tamaño de pantalla de un teléfono. Pese a que dentro del todo sigue ejecutando un núcleo Windows CE, la parte visual y la forma de desarrollar cambia por completo.
Es un nuevo paradigma cuyo lenguaje base es C# y que se basa en una versión especial del .NET Framework. Aunque a simple vista el desarrollo puede parecer muy sencillo, la realidad es otra, ya que todo se lleva a cabo de forma asíncrona. Sin entrar en detalles técnicos, cuando un programa abre un fichero para leer su contenido, hasta ahora, uno hacía la llamada y obtenía el contenido del fichero. En Windows Phone eso cambia radicalmente. Uno pide al sistema operativo leer el contenido de un fichero, y cuando este está disponible, el sistema lo comunica a la aplicación. Mientras, el programa sigue su curso normal.
Pues bien, la interfaz de desarrollo de Windows Phone 7.x es diferente a la de 8.0. Es otro de los cambios en el desarrollo. En un primer principio esta nueva interfaz es muy similar a la anterior, pero sólo en apariencia. Aparte de los cambios en el lenguaje de base, C#, la a asincronía se potencia.
Windows Phone 8 puede seguir ejecutando aplicaciones creadas para la versión 7, pero sólo con las características de este último. Es decir, si uno quiere usar el nuevo API para capturar audio, tendrá que actualizar su aplicación a Windows Phone 8 y ya no podrá ejecutarse en 7.x.
Aquí nos estamos dando cuenta de cómo Microsoft nos cambia las cosas sin que nos demos mucha cuenta. Por un lado hemos pasado de una interfaz basada en escritorio a otra basada en teselas, y por el otro, en poco menos de cuatro años, nos ha cambiado la interfaz de desarrollo tres veces.
Y sin retrocompatibilidad. Es decir, el código de Windows Mobile lo tiras a la basura si quieres desarrollar para Windows Phone. El código de WP 7.x lo tienes que tirar a la basura, o casi, para desarrollar para WP 8.
Lo mismo ocurre con Windows. Si quieres pasar del escritorio clásico a las teselas, tira el código a la basura.
En ambos casos, dependiendo de cómo te hayas organizado, podrás aprovechar partes, pero si quieres sacar ventaja de lo nuevo, estas serán bastante pocas.
***
Con esto nos hemos situado en el ahora. El siguiente paso que Microsoft ha dado ha sido el de unificar las cuentas de desarrollo. Aunque de momento la forma de subir una aplicación para Windows Phone es completamente diferente a la de Windows 8.x, la cuenta es la misma.
Han reducido el precio de la misma, y a los que tenemos una MSDN, nos han regalado un nuevo año. De esta forma matan las quejas de quienes hayan pagado las dos cuentas un mismo año.
¿Cuál va a ser el paso siguiente? Muy posiblemente unifiquen la forma de subir una aplicación. La forma de hacerlo en WP es bastante chapucera y falla muchas veces. La de W8 es algo más profesional y más seria, así que ya sabemos qué interfaz se quedará.
***
A fecha de hoy, una aplicación realizada en Windows Phone es completamente inejecutable en Windows 8. Y viceversa. Pese a utilizar el mismo lenguaje de desarrollo, el mismo formato de ejecutable (aunque no de empaquetado) y el mismo .NET Framework.
El mayor problema reside en que las llamadas al sistema operativo completamente diferentes. Por poner un ejemplo no real, en Windows Phone abrir un fichero es File.OpenFile() y en Windows 8, File.FileOpen(). Personalmente creo que es una gran cagada, ya que no hay absolutamente nada que impida que en ambos sistemas el nombre fuera el mismo.
Otro gran problema, y este bastante más insalvable que el anterior es el hecho de que, pese a que ambos interfaces gráficos se construyen no sólo con la misma herramienta, sino hasta con el mismo lenguaje (llamado XAML una variación de XML), y mantener el mismo concepto, la construcción de la interfaz es completamente diferente. No sólo los elementos gráficos tienen diferente nombre, sino que el comportamiento de cada equivalente también difiere.
Aquí Microsoft tiene un gravísimo problema. Y se han metido en él ellos solos, y son conscientes de él porque han creado un tipo de proyecto en Visual Studio (la herramienta con la cual se crean las aplicaciones) que han llamado portable library, y que es una forma de poner ahí todo el código común a Windows Phone y Windows 8 (y otras más, como XBOX, etc).
Básicamente lo que construyes ahí es funcionalidad para tu aplicación que, sin tocar para nada, servirá tanto para una como para otra. Dependiendo de para qué plataformas quieras que esté disponible, habrá más o menos código común.
La idea es muy buena. Como la mayoría de veces con las cosas de Microsoft, el resultado, no tanto. Sólo hay que crear una de ellas y ver cuánto código puedes compartir. Siéndoos sincero, muy poco.
Hay técnicas para que, usando la librería, cada parte implemente las diferencias. Es decir, suponiendo que leer el contenido de un fichero se haga de forma diferente en WP y W8, una llamada dentro de la librería para leerlo, en realidad ejecutaría el código de cada plataforma y retornaría el resultado, unificado por dicha parte común, pudiendo luego procesar el contenido del fichero dentro de la librería y de forma conjunta.
De este modo solucionamos una carencia teniendo que teclear el mismo código hasta tres veces: el común de la librería, y el específico de cada plataforma en cada plataforma. No es la solución óptima ni de lejos, pero es lo que hay.
De nuevo, el mayor problema viene con la interfaz. No sólo son diferentes, sino que se construyen de forma diferente. Es decir, uno podría tener un contenedor que tuviera subcontroles que fluyeran dentro del mismo, de forma que se recolocaran ellos mismos de la forma adecuada dependiendo del tamaño de la pantalla. Eso existe, pero el comportamiento es completamente diferente en cada plataforma, por lo que todo eso tiene que estar fuera de la librería común. Y en este caso el autor no conoce una forma coherente de unificarlo ni creo que exista.
Todo esto nos lleva al gran problema que supone la gran unificación. A fecha de hoy no existe una solución sencilla, o al menos, de nuevo, yo no la veo.
Microsoft podría hacer tres cosas.
La primera es implementar el API de Windows 8 en Windows Phone y viceversa. Entonces ocurriría que los programas de W8 se verían diminutos en WP y los de WP enooooooormes en W8. Este problema tiene una solución no muy sencilla en el caso de querer que las aplicaciones se vean bien en ambas situaciones: hay que mutar el comportamiento de los controles, cambiando la forma en que fluyen. Y haciendo que los Pivot y Panorama de WP se conviertan en columnas.
Dependería entonces de los programadores eliminar algunas restricciones en sus interfaces, como tamaños fijos. Porque, señores programadores, ¿estaréis usando los controles con dimensiones relativas, no? Es decir, poniendo “*”, “Auto”, etc en los tags de los tamaños…
Dada la calidad de las aplicaciones que hay, va a ser que no, pero en este caso aunque en un principio la culpa no es de Microsoft, al final sí que lo es. Volveremos sobre esto más abajo.
La segunda es hacer lo que Apple cuando sacó su iPad: las aplicaciones de Windows Phone se ejecutan dentro de una sandbox de modo que se verán como en un teléfono, desechando el resto de la pantalla. La situación inversa no será posible, pero imaginaos por un momento cómo se vería una aplicación de un teléfono en el centro de una pantalla de 27” sin escalar.
Finalmente, la solución que menos me gusta es la que estoy completamente seguro van a implementar. Quizás sea en Windows Phone 9/Windows 9, o quizás en la siguiente, pero anticipo un nuevo cambio de interfaz de desarrollo.
Es decir, que si quieres que tu programa realizado para WP8 funcione en Windows 9, tendrás que reescribirlo por completo. Y justo al revés. No obstante existen variantes para esta opción.
La más coherente (dentro de la incoherencia) sería que el API de Windows Phone 9 se equiparara a la de Windows 8.x, que seguiría siendo la de Windows 9, con lo que una aplicación escrita para WP9 podría correr en, al menos, W9 si no en W8. No obstante, seguro que tienes que reescribirla.
La otra opción, menos probable, consistiría en que W9 usara el API de W8, ampliado. Sería el mismo caso, pero al revés. De nuevo tendrías que reescribir tu aplicación.
Y finalmente, la más probable es la que yo vaticino, queriendo equivocarme por completo. Windows Phone 9 no será compatible con Windows Phone 8. Windows 9 no será compatible con Windows 8. Y tanto WP9 como W9 tendrán un nuevo interfaz, esta vez común, pero diferente a cualquiera de los anteriores.
Evidentemente, las versiones nuevas podrán ejecutar sus propios programas de su versión anterior, pero si quieres que tu aplicación se ejecute tanto en WP9 como en W9, compartiéndolo todo, tendrás, de nuevo, que reescribirla.
Y entonces será cuando los programadores terminen de abandonar definitivamente la plataforma.
***
Hablando de programadores me gustaría compartir una última opinión. Anticipo que las opiniones son como los culos: todos tenemos uno y el de cada uno es diferente. Con esto quiero decir que en esta entrada hay mucho de opinión personal, y en lo que sigue, todavía más.
¿Por qué C#? ¿Por qué .NET? ¿Por qué hacer una nueva capa nativa sobre Win32 (que es lo que realmente hay debajo tanto de WP como de W) para que funcionen las nuevas interfaces? ¿Por qué no todo en C++/CX, que es el lenguaje con el que está construido todo el interior de la nueva interfaz?
Desarrollar en iOS no es fácil. Objective-C no es fácil. No porque sea un lenguaje complejo en sí, sino porque es muy parecido a C++ en el sentido de que es no-manejado. Aunque las últimas versiones traen su propia destrucción determinista (igual que trae C++/CLI), con anterioridad había que saber no sólo el lenguaje, sino conocerlo a fondo. Y un error significa una caída de tu aplicación.
Con C++ y todas las variantes de Microsoft (C++/CLI y C++/CX) pasa más o menos lo mismo. Has de conocer el lenguaje y has de ser consciente de qué estás haciendo.
Sin embargo, lenguajes como C# o Java son bastante más blanditos en el sentido de que no tienes que estar continuamente alerta con lo que estás haciendo. Si bien C++0×11 es bastante más moderno en ese sentido (y C++0×14 todavía lo será más), continúan siendo lenguajes no manejados bastante difíciles de controlar.
Por lo tanto, al mismo nivel de conocimientos de desarrollo, hacer algo con C# es bastante más sencillo que con C++ u Objective-C. O si le damos la vuelta a la tortilla, en manos de un mismo desarrollador, 1.000 líneas de código en C++ terminan siendo igual de inmanejables que 10.000 de C# si están mal escritas.
Por lo tanto, pese a que Microsoft tiene las herramienta para el desarrollo adecuado, ha preferido el lado fácil y ha hecho como Android para facilitar el acceso y la creación de aplicaciones a más programadores, o más bien a programadores de perfil más bajo.
El resultado ha sido el mismo que en Android: miles y miles y miles de aplicaciones que no sólo no valen para absolutamente nada, sino que encima están tan mal hechas que la mitad de veces se cierran solas.
Por lo tanto, volviendo a los posibles escenarios de unificación, en el caso de que Microsoft eligiera una de las dos primeras opciones íbamos a ver cosas interesantes hasta el punto de que tendría que retirar todas y cada una de esas aplicaciones.
Una cosa más. Me resulta enormemente triste comprobar cómo Microsoft ha copiado las cosas incorrectas de cada plataforma, las cosas que las empequeñecen y no las que las engrandecen.
La tienda de Apple tiene prácticamente las mismas restricciones que las de Microsoft, pero la calidad de sus aplicaciones, aunque sean de tirarse pedos, es mucho mejor que las de Microsoft, casi seguro por el perfil medio del desarrollador.
La tienda de Android permite casi cualquier cosa ya que apenas está controlada por Google, y la mayoría de ellas son igual de basura que las de la tienda de MS porque allí también casi cualquiera puede publicar.
En fin, es lo que hay y espero que Microsoft se ponga las pilas.
| Tweet |
No hay comentarios:
Publicar un comentario