Visual Studio Tools for Cordova: Lecciones


Tengo algo de tiempo jugando con Apache Cordova a través de Ionic y me parece que es lo mejor que hay para desarrollo en móviles a pesar de que existen otras alternativas muy interesantes, tal como NativeScript. Nunca tuve problema alguno para generar aplicaciones tanto para Android como para iOS que funcionaran igual y con buen rendimiento, pero estos no son los únicos en el mercado.

Windows Phone 8.1 creo que ha sido una plataforma menospreciada sin razón alguna, pues tiene muchas ventajas, comenzando con el hardware. Desde el punto de vista de desarrollo, era posible utilizar Ionic para generar para WP8.1 pero había que hacer algunos cambios. Desde la publicación de Cordova 6, se anunciaba el soporte de Windows, faltaba ver si era Windows 10 , 8.1 o WP8.1 o el aún no nacido Windows 10 for mobile.

Finalmente he publicado mi primera aplicación para Windows Store con Visual Studio Tools for Cordova y aquí les dejo algunos consejos para que no gasten tanto tiempo como yo. Un adelanto: Realmente sirve para generar tu app en la nueva Universal Windows Platform.

  1. UWP no asegura que tu aplicación funcione bien en Windows 8.1 o en WP8.1. Mi decisión en este punto fue dejar de lado Windows 8.1, claramente la tendencia es dejar de lado esa plataforma, además que es muy fácil hacer el upgrade a 10.
  2. UWP si asegura que tu aplicación funcione en todo lo que sea Windows 10. Lo que generes y funcione en Windows 10 funcionará bien tanto en 32 y 64 bits y también en Windows 10 for Mobile. Obviamente en algunos ira más rápido o lento pero todo lo demás será igual.
  3. Apache Cordova tiene muchos plugins pero no todos funcionaran con TACO. La arquitectura de Apache Cordova se basa en el uso de plugins para acceder a las capacidades nativas del equipo en la que se ejecuta, tratando de definir un conjunto de métodos comunes para facilitar el desarrollo. Esto se puede gracias a que el desarrollador del plugin, crea un código por cada plataforma que quiere soportar que se encarga de implementar lo definido en los métodos comunes, en algunos casos, se crea un código universal y listo, esto gracias a que debemos recordar que usamos las capacidades del navegador nativo. En sencillo: creo un plugin para Apache Cordova que acceda al lector de huellas y tengo que crear un “conector” para Android, otro para iOS y otro para WP, entonces si alguien quiere usar mi plugin en Blackberry pues simplemente no funcionará. La razón de la ausencia de este conector es que el sistema operativo que queremos soportar puede ser que no soporte lo que queremos hacer, o simplemente no sabemos programar para esa plataforma. Por ejemplo, hay un Plugin para leer el IMEI, que funcionaba en Android y iOS, nunca funcionó en WP y recientemente ya dejó de funcionar para iOS. Para todos los efectos, UWP es una nueva plataforma identificada como “windows” en Cordova, así que cada plugin que no tenga un conector universal, o uno que soporte “windows” no podrá ser usado con TACO.
  4. Nunca publiquen un Appxbundle para Windows Phone 8.1. Windows Store ya ha sido unificado y permite que declaremos varios binarios para una sola aplicación, lo cual está muy bien. Lo malo es que hay reglas algo confusas si es que quieres soportar Windows Phone 8.1. Una de esas reglas es que si subes un Appxbundle para una soportar una plataforma, deberás usar también Appxbundle si quieres subir una actualización. Para Windows 10 esta bien pues es super fácil. El problema es para WP8.1 pues hay dos tipos de proyecto: Silverlight y para Windows Store, y como ya sospecharán, si trabajas en Silverlight no podrás generar un appxbundle. Lo malo es que es  muy probable que tu app en Cordova sólo funcione en Silverlight que sólo genera XAP. Por esto, si quieres soportar WP8.1 debes dejar de lado Appxbundle. Tendrás que hacer un paquete XAP sólo para esta plataforma.
  5. No existe un ancho de pantalla. En Apache Cordova se diseña principalmente en escalas porque en móviles hay muchas resoluciones de pantalla. Es por eso que no se definen dimensiones de pantalla, al menos no a cada rato. En Windows la cosa se pone peor, porque las apps pueden correr maximizadas o en una ventana y las dimensiones pueden ser cambiadas por el usuario. Por esto deben diseñar pensando en posiciones relativas para todos los elementos del UI de su app.
  6. TACO genera un proyecto CordovaApp dentro de platforms. Esto es propio de Cordova, cada plataforma tiene su carpeta donde se pone el código generado. En Vstudio TACO también sucede esto y lo mejor es que podemos abrirlo y tener un mayor control en la publicación de nuestra App. Utilicen este proyecto para publicar a Windows Store, se ahorrarán muchos problemas
  7. Para WP81, mejor generen para WP8 y suban a Silverlight. Sobre el punto anterior, el proyecto que les menciono puede generar para Windows 8.1, Windows 10 y WP 8.1, pero no les recomiendo para nada que usen este proyecto para WP8.1. Desde el proyecto Taco original, pueden generar para WP8 que generará otra carpeta dentro de “platforms” wp8 donde encontrarán otro proyecto WP8 que fácilmente pueden actualizar a WP8.1 mediante la opción Retarget que sale al abrirlo. Este tipo de proyecto funciona mucho mejor que el original y de pasada, soporta mas plugins.
  8. Incluye sólo archivos javascript locales. Esta es una recomendación Cordova en general. En el archivo index.html se fijan todas las librerías que vamos a utilizar y estas deben ser locales pues de esa manera evitará problemas si es que el móvil no tiene conectividad. Hay excepciones pero son pocas, por ejemplo, Google Analytics quiere siempre ser llamado en línea, y como no podemos pelearnos con ellos entonces fijemos a esa librería como la única excepción. Todo lo demás local.
  9. Bower es tu mejor amigo. Javascript es un mundo completo y lo mejor que puedes hacer es utilizar un package manager como Bower. En Visual Studio esta tan bien integrado que incluso puedes cambiar las versiones de librerias y éstas se actualizarán automáticamente. Siempre es mejor usar Bower que copiar los archivos js manualmente.
  10. Las librerías Javascript cambian muy seguido. Ya les dije que Bower es lo mejor, pero faltó decirles que las librerías javascript cambian muy seguido, así que lo mejor es tomar nota las versiones que usamos. Una costumbre muy buena es usar GIT para controlar los cambios al código. Con Bower pueden probar la versión de la libreria que mejor les funcione y luego fijar esa versión.
  11. Typescript es la voz. Typescript es como el papá de javascript y hay muchas ventajas al utilizarlo. Vamos a condensar todas en una sola: Puede que cambien los frameworks que utilizas pero todas estarán basadas en Typescript, por lo que tu código será “future-proof”.

Y para cerrar, la recomendación definitiva es que usen GIT y así evitarán que algún cambio accidental malogre su proyecto.

Finalmente, aquí les va el resultado que he logrado para mi aplicación SuperComics para Windows 10 que funcionará en sus PCs o en sus teléfonos con Windows 10. Spanish_wstore_black_258x67




    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s



%d bloggers like this: