Acerca de...
El equipo
Encuestas
Política de privacidad
WinTablets

Encuesta

¿Cual crees que triunfará?

Ver Resultados

Cargando ... Cargando ...

últimas entradas importantes

Categorías

Archivos

14
Jun 2014
AnálisisDesarrolloGuíasMetroModern UIrfogdevSoftware

Empezando a desarrollar para la tienda de Windows 8 y Windows Phone (y III de III)

Esta es una entrada de regalo que os hago. Básicamente porque se me quedaron algunas cosas en el tintero. Os voy a hablar sobre cómo funciona la tienda, cómo compilar para Windows Phone y Windows 8 en todas sus variantes, ya sea x86, x64 o ARM. También trataré por encima los proyectos universales y las bibliotecas compartidas.

Para poder subir una aplicación a la tienda de Windows (o de Windows Phone) tienes que tener una cuenta de desarrollador. Hasta hace unos meses si querías publicar en los dos sistemas necesitabas una para cada tipo de plataforma y la broma podía salirte por unos 150 o más euros.

Ahora solo cuesta 14 dólares (si no lo han cambiado) y sirve para ambas tiendas. La idea de Microsoft es unificarlo todo en un mismo servicio, pero a fecha de hoy existen dos tiendas separadas y tenemos que subir nuestras aplicaciones en cada una de ellas respectivamente. Sí, incluso las universales.

La idea de todo esto es bastante similar a lo que hace Apple. Tu te das de alta como desarrollador en su plataforma, pagas una cuota anual (79 euros para iOS, lo mismo para OS X y otro tanto para las extensiones de Safari) y eso te da derecho a subir tantas aplicaciones como quieras durante el año de vigor. Es decir, en Apple, si quieres desarrollar para todo, necesitas unos 240 euros frente a los 14 dólares de Microsoft.

Ellos las revisan y las aprueban o rechazan. En este último caso te dan un informe sobre lo que has hecho mal para que lo corrijas y reintentes. No debes desanimarte si el rechazo se repite varias veces. No se puede ser un tío guapo e inteligente como yo que, de unas diez subidas a tienda, sólo se la han rechazado una vez, y no fue la primera.

También pueden aprobarla con un informe de aviso, o recibir uno de repente sin más, diciéndote que cambies esto o aquello antes de volver a subir una nueva versión. El segundo caso suele ocurrir cuando un usuario envía una queja a Microsoft. Yo recibí una, hace tiempo, en la que una pantalla de la aplicación que hago en donde trabajo no se veía bien cuando el usuario tenía el tema claro activo. Es tan simple como corregirlo y esperar a la siguiente versión que tengas previsto subir o hacerlo de forma inmediata.

Supongo que también podrían retirártela por incumplimiento de las normas, o por violación de copyright o similar. En ese caso el proceso es el mismo. Corriges y subes. No hay más. Bueno, a lo mejor luego te llama el FBI o la NSA, pero eso ya es cosa tuya. :-)

Si haces aplicaciones de pago, el reparto es 30-70 o 20-80 dependiendo del precio de tu programa. Es decir, Microsoft se queda el 30% de la venta por gastos de representación y mantenimiento de la plataforma, y el resto te lo ingresa donde digas. El valor de la aplicación lo pones tu en ambas plataformas. Puede ser el mismo o no, o variar entre países, o ser gratis en unos y de pago en otros, etc.. Eso sí, hasta que no factures 200 dólares, no te pagan. Podrías tener una aplicación tres años, generar menos de esa cantidad y no ver un duro.

 

Te puedes dar de alta aquí (ya sabes lo que tienes que hacer si la tienda no sale en tu idioma). Has de hacerlo como particular o como empresa (como tal creo que vale algo más de pasta). Das tus datos, tarjeta de crédito incluida y ya está, ya eres desarrollador de aplicaciones de las tiendas de Windows y Windows Phone.

Si tienes alguna pega, el servicio técnico no es exquisito, es lo siguiente. Yo tuve un problema serio con la renovación de la cuenta de la tienda de Windows 8 (cuando todavía estaban separadas) y cuatro horas después de poner el incidente ¡¡me llamaron por teléfono de USA, fuera de su horario de trabajo, y en español!! En cosa de un rato solucionaron el tema.

Otro buen punto de entrada para todo el tema del registro de cuentas es este. En la columna de la derecha verás mucha información sobre el registro y lo que hace falta, todo ello en castellano.

Una recomendación es utilizar la misma cuenta que usas de login en tu Windows, tanto para crear la cuenta de desarrollador como para luego activar las licencias de Visual Studio (abajo más sobre esto).

 

¿Qué debe cumplir mi aplicación?

En contra de lo que ocurre con Apple, las normas que debe cumplir una aplicación para ser subida y aceptada son muy claras y están detalladas punto por punto en los siguientes enlaces:

 

Dependiendo de lo que haga tu aplicación, deberás cumplir más o menos requisitos de los citados arriba. Una cosa curiosa es que cada vez ponen menos cortapisas y limitaciones a lo que puedes hacer. Fijaos cómo hay muchos puntos que dice “Eliminado”. Con anterioridad eso eran reglas que debías cumplir pero que han retirado.

Una cosa muy importante que debe llevar tu aplicación es tu “política de privacidad” (Privacy Policy). Debes ponerla en algún lado o te rechazarán la aplicación aunque ésta solo ponga una pantalla en negro. Básicamente tienes que decir qué vas a hacer con los datos del usuario. Si los recoges, si no los recoges, si los procesas, si los envías por internet etc etc.

 

¿Cómo puedo probar mis aplicaciones?

Puedes hacerlo de tres formas aunque en principio, tu propio ordenador es tu máquina de pruebas.

La primera es simplemente lanzar la aplicación, que se instala en tu propio equipo y la pruebas. Sin más. Es lo que debes hacer en los primeros estadios del desarrollo, hasta que pienses que la cosa ya anda más o menos fina.

Pasted Graphic

La segunda es abrir el desplegable de la imagen de arriba y elegir “Simulador”. Cuando la ejecutes aparecerá un simulador de Windows 8.x que es tu propio equipo pero conectado como si fuera un emulador. Con ese programa puedes cambiar la orientación, definir resoluciones y tomar capturas de pantalla.

Si te fijas, hay una tercera opción que se llama “Equipo remoto”. Es lo que se conoce como depuración remota y si tienes algún tipo de Surface (RT o no), deberías probar tu programa allí también.

En principio uno se puede instalar Visual Studio en la tableta de destino y hacer todo el tema allí. Os adelanto que eso es un completo error. En primer lugar estás marcando el núcleo de esa tableta como núcleo de desarrollo, con lo que la seguridad de la misma baja ya que existe un nuevo rol dentro del sistema que le permite a un proceso controlar a otro.

Por lo tanto, en las tabletas de prueba no se instala Visual Studio a no ser que sea tu equipo de desarrollo principal. Ya sabéis, VS en Surface, caca.

¿Entonces cómo lo hago? Fácil, has de instalar el depurador remoto en dicha tableta. Sí, para RT también lo hay, y de hecho ahí es la única forma de probar tu aplicación (y deberías tener una RT sí o sí si te vas a dedicar a esto de forma seria). Una vez instalado el depurador remoto, lo inicias y configuras tu VS para que se conecte a la máquina y haces el debugging. Aquí tenéis documentados todos los pasos y cómo hacerlo.

 

En Windows Phone se hace de otra forma. También debes empezar con los emuladores si los tienes, pero también debes ir ejecutando de vez en cuando en algún teléfono, porque a veces las cosas van diferente en real que en emulado. Me refiero a que un terminal real suele tener menos memoria disponible, ir más lento por tener otros servicios funcionando, etc. Eso no quiere decir que debas matarte con la lentitud de la carga de una aplicación en el teléfono real, pero de vez en cuando, prueba.

Y por supuesto, las pruebas finales siempre, siempre, en todos los teléfonos que puedas. Sobre todo en lo que menos memoria tengan. Hazte con un Nokia 520 sí o sí. Y con un HTC 8S, que es uno de los que más problemas dan con las aplicaciones. Un 920 es otro must, ya que también es un poco tiquismiquis (sobre todo con la multimedia), y el que diga que en Windows Phone todos los terminales funcionan igual miente como un bellaco (o no se ha puesto a desarrollar en serio).

Igual que con iOS, puedes convertir cualquier teléfono en equipo de desarrollo mediante la utilidad Developer Phone Registration que debes tener instalada en tu ordenador de desarrollo. Es tan fácil como conectar el terminal al ordenador, lanzar el programa citado y seguir los pasos, que suelen consistir en introducir tus credenciales de la cuenta Live con la que te diste de alta en la tienda.

Lo que hace la utilidad es instalar un certificado digital en el teléfono que permite que VS depure en él. Aquí tenéis explicados los pasos con más detalle.

 

Tests y más tests

Tanto para W8 como para WP, el propio VS trae todo un conjunto de tests automatizados que debes ejecutar antes de poder subir tu aplicación. Para proyectos de Windows 8, el test se ejecuta desde el menú de contexto de la solución, eligiendo “Analizar -> Ejecutar análisis de código”. Deja que tu ordenador se vuelva loco un rato y cuando termine, te dirá qué has hecho mal.

En Windows Phone 8.1 está situado en el mismo lugar, pero para versiones anteriores tienes que abrir el fichero “WMAppManifest.xml” desde el explorador de soluciones.

 

Subiendo la aplicación

El proceso de subida a la tienda tarda un poco. Lo primero que debes hacer es generar el paquete para subir, que se hace desde el menú contextual del proyecto, opción “Tienda”.

Una vez generado el fichero, hay que subirlo. Los procesos, si no han cambiado, son completamente diferentes en los casos del teléfono y las tabletas. Sin embargo, en ambos casos, consiste en crear una nueva aplicación y seguir los pasos. En el artículo que os cité en la entrada anterior, está mejor explicado, junto a todos los gráficos y demás elementos que hacen falta. A él os remito.

Al cabo de unos días, tendréis vuestra aplicación publicada (o rechazada).

 

Ignoro si ya se puede hacer en Windows 8, pero en Windows Phone tenemos la posibilidad de probar nuestra aplicación en teléfonos de terceros sin hacer nada extra. Son las aplicaciones de tipo beta, que se crean igual que una normal pero en el paso adecuado eliges este tipo.

Tienes un cajetín en el que debes poner los correos electrónicos de las cuentas Live de los terminales de destino. Tiene que ser el mismo correo con el que el usuario que va a probar tu aplicación se instala las aplicaciones. En general es la cuenta microsoft que aparece en la configuración.

Tan sólo podrán instalarse la aplicación aquellas cuentas que estén ahí. Una recomendación que os hago es que, al menos, os la instaléis vosotros así en vuestro teléfono ya que el proceso es idéntico a cuando se hace con la aplicación definitiva y a veces las imágenes y los recursos de la instalación se muestran diferentes si se hace desde Visual Studio.

Cuando haya pasado el proceso de certificación (que no suele tardar más de dos o tres horas en contra del proceso real), recibirás un correo con la URL de la aplicación. Y en otras dos horas o así, la tendrás disponible para bajar.

La documentación dice que el sistema envía un correo a los beta-testers. En mi caso jamás ha ocurrido, así que lo que tienes que hacer es enviar dicha URL a tus testers y que la ejecuten desde el navegador de su teléfono. También se pueden bajar el XAP e instalarlo localmente.

Como te habrás dado cuenta, hay un componente de seguridad extra. Ese XAP está encriptado (igual que el de la aplicación definitiva), con la diferencia de que sólo lo podrán instalar en aquellos terminales que tengan uno de los correos que pusiste. Por lo tanto, si alguien no autorizado consiguiera ese fichero, no podría ni descomprimirlo ni instalarlo en su terminal.

 

Miscelánea

Os cuento aquí algunas cosas que no sé dónde poner. La primera de ellas es que puedes bajar desde aquí algo así como trescientos megas (comprimidos) de aplicaciones de demo. Supongo que serán todas las de la MSDN.

En Windows Phone, que yo sepa, no están disponibles como un paquete para descargar, pero si que hay un listado con la posibilidad de filtrar por tipo y cosas que hacen.

La primera vez que lancéis Visual Studio os pedirá una licencia para desarrollar aplicaciones de la tienda. Ojo, no es la cuenta de desarrollo, es una licencia local para esa combinación de Visual Studio y de Windows. La licencia es gratuita y caduca a los tres meses, por lo que será un proceso por el que deberás pasar de forma periódica si terminas dedicándote a esto.

Hay que meter las credenciales Live, quizás las mismas con las que registraste la cuenta de desarrollo y/o el propio Visual Studio. Mi recomendación es que uses la misma para todo, pero no es obligatorio ni mucho menos.

La ventaja de tener VS registrado es que cuando cambies de máquina la configuración se mantiene y, cuando cambies algo en un equipo, se cambia en todos.

Existen otras ventajas en relación al código, que os contará el amigo Juan Quijano.

Supongo que tendréis la duda sobre cómo compilar tu aplicación Windows para x86, x64 y ARM. En principio, si sólo usas C# ó VB.NET, no tienes que hacer nada ya que el código generado es del tipo “AnyCPU”, lo que significa que el mismo ejecutable es válido para cualquier arquitectura. Es decir, cuando generéis el paquete para la tienda, sólo os hará falta uno de ellos. Luego, a la hora de ejecutar la aplicación, el motor de tiempo de ejecución ya se encarga de traducir ese pseudo-ensamblador (llamado MSIL) al código máquina real de cada equipo.

Pero si estás utilizando algún tipo de biblioteca nativa (que no sea .NET o que siendo .NET no esté compilada como AnyCPU), tienes que generar hasta tres paquetes diferentes. También si has escrito tu aplicación en C++/CX (recordemos de entradas anteriores que eso compilaba a nativo, no a .NET).

Imagina que has conseguido una biblioteca muy chula de un tercero pero que sólo está compilada para x86. Pues sólo podrás generar ese tipo de paquete, y sólo correrá en tabletas x86 (y en las x64 pero en modo x86). Si quieres que tu aplicación se ejecute en una tableta ARM, lo siento, amigo, necesitas dos cosas: que dicha biblioteca compile para ARM y que luego ejecute sin problemas.

No es lo mismo, compilar es el primer paso, luego ha de funcionar, lo que muchas veces no está tan claro ya que si viene para un solo procesador es porque usa instrucciones máquina específicas (léase SSE o equivalente).

Ya sabéis por qué algunas aplicaciones, aun siendo Modern UI, sólo están para x86, x64. No entro en más detalles sobre esto porque no creo que ningún programador novel o con experiencia media deba enfrentarse al problema.

 

Bibliotecas portables y aplicaciones universales

Antes de comentar la engañifa que son la aplicaciones universales, os cuento de pasada lo que es una biblioteca portable. Actualmente casi todo el ecosistema de Microsoft comparte en común un subconjunto de APIs que, conforme vamos subiendo de versión, van teniendo más y más partes en común hasta, supongo, la futura integración total en Windows 9 o cuando llegue, y si llega.

Imaginad que vais a hacer una aplicación y queréis que esté en la XBOX, en Windows Phone y en Windows. Una solución es hacer tres (o más bien cinco: XBOX, Windows 8.x, Windows Phone 7.x, 8.0 y 8.1). Otra es simplificar un poco el escenario y utilizar una biblioteca de este tipo.

La idea es que cuando la creas, le dices en qué plataformas se va a ejecutar, y Visual Studio restringe los APIs al subconjunto común de todas esas plataformas. Y es ahí donde puedes poner todo el código que puedas. De nuevo, esto queda mucho mejor explicado en el artículo que cité en la entrada anterior.

El siguiente paso en todo esto son las aplicaciones universales. Una aplicación universal es aquella que se ejecuta en diferentes plataformas sin cambios.

¿Sí? Pues no. Una aplicación universal, según Microsoft, es una biblioteca portable más una o varias aplicaciones para cada plataforma. Incluso cuando compiles y generes los paquetes, debes generar uno diferente para cada plataforma.

¿Cuál es, pues, la ventaja? Sencillo: una aplicación universal contiene casi todo el código en la biblioteca, dejando muy pocas cosas en cada uno de los proyectos independientes.

Por los mentideros de la red se comenta que se pueden compartir incluso el código XAML de las páginas, pero cuando tu creas un tipo de aplicación de este tipo, el asistente te pone el XAML en cada proyecto en lugar de en la zona común, así que no sé cuán cierto será ya que no lo he probado y no tengo previsto hacerlo pronto.

Eso sí, las aplicaciones universales sólo funcionan así si las versiones de destino son Windows 8.1 y Windows Phone 8.1. Si quieres añadir una versión inferior (o a XBOX), bajas de nuevo al modelo descrito al principio de la sección.

Como veis, todo un éxito de márqueting cuando en Apple sí que son universales de verdad.

Bueno, creo que con estas tres entradas, que realmente son cuatro si juntamos el artículo que os he citado, podemos cerrar el tema.

Espero que os guste leerlo tanto como a mi escribirlo.

Por RFOG | 9 Comentarios | Enlaza esta entrada
contacto@wintablet.info tema WinTablet.info por Ángel García (Hal9000)