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

06
May 2017
Podcast

Caso de uso de una aplicación UWP y otros menesteres

Ya sabéis que periódicamente suelo hacer un día, o fin de semana, o incluso semana “solo con Windows”. Otras veces simplemente enciendo mis wCosas para que las baterías no terminen jodiéndose. A raíz del último Hangout, se me ha ocurrido contaros una historia sobre varios aspectos de las aplicaciones UWP como un ecosistema completo, soporte técnico incluido.

Y de paso os cuento otras miserias de Windows que me han pasado al escribir esta entrada.

La aplicación en cuestión es el juego Lara Croft GO, que “compré” (entre comillas porque fue una oferta de esas que a veces salen gratis). Es un juego que corre dentro de la plataforma UWP. He de decir, en descargo de la aplicación, que solo se me colgó una vez cuando sin querer roté la pantalla de la tableta (la Cube i7) muy rápido dos veces. Cerré sin problemas y volvía a abrir.

Aparte de eso, han sido varias horas las que he estado jugando sin ningún tipo de problema ni cuelgue ni “cosa rara”. Eso sí, tragando batería como una condenada y un poco más, algo a lo que estamos acostumbrados en las aplicaciones UWP realizadas con Unity en C#. La ventaja de la multiplataforma y el inconveniente de no dedicar el tiempo suficiente a pulir las esquinas de un juego en una plataforma minoritaria. De todos modos, el juego es jugable.

Digo que obtuve el juego en un equipo, cuando recibí la oferta y me di cuenta de que era un juego por turnos. Eso fue en el ordenador del trabajo. Bajé, instalé, y le di un tiento de unos diez minutos. Entre otras cosas me creé una cuenta dentro de la aplicación, para mantener el avance del juego en todos mis windows (y con un poco de suerte, quizás también en mis iCosas si algún día decidía comprarlo para ellas).

No problem. El sistema te asigna un ID, pones una clave y listo. En teoría, luego te vas a otro equipo, metes tu ID, que es un número, y tu clave, y listo. Recuperas el estado de tu juego.

La pantalla de abajo muestra el login:

Pues bien, la cuenta fue dada de alta en el ordenador del trabajo. Cuando fui a casa, instalé el juego en la Cube i7 y tras varios intentos fallidos fui capaz de recuperar la cuenta. De hecho es donde casi me he pasado el juego.

Pero la Cube i7, con esa aplicación, se calienta que da gusto. Así que decidí instalarla en el Thinkpad y seguir jugando en él al cabo de unos días. Me bajo el juego, intento hacer login y… ¿Vosotros habéis podido hacer login con mi cuenta? Pues yo tampoco. Decía que mirara mi conexión, a todas luces una excusa para enmascarar que a) la cuenta ya no existe en sus servidores, o b) sus servidores están tontos del culo.

Leches, que no hubo manera. Y no hay lugar a dudas de que el número de cuenta es correcto, porque le hice una foto al login original. Y la clave tampoco, joder, que no soy ningún principiante.

De hecho, esa pantalla de login adolece de bastantes bugs y problemas. Después de un login fallido, el teclado (ya sea físico o virtual) deja de funcionar. O sí funciona la parte del ID pero no la de la clave. Tienes que cerrar y volver a abrir de nuevo la pantalla. No es algo que moleste mucho… no si todo funcionara bien.

Vale, hasta aquí nada fuera de lo normal. Lo extra, primera parte, viene ahora. Decido ponerme en contacto con el servicio técnico. Les comento lo que me pasa y me responden la captura de abajo:

Para los que no sepáis la lengua de Shakespeare (mal, muy mal), vienen a decirme que me joda y baile, que no pueden hacer nada y que me la pique un pollo con verrugas.

Evidentemente con buenas palabras, pero el sentido del mensaje es ese. Ni más ni menos.

Supongamos por un momento que no sea rfog, sino la Señora María que tiene un problema con su juego. En cuanto le sumen cuatro problemas como ese, la próxima vez que se acerque a una tienda y vea una tableta con Windows, le pega fuego y luego mea encima para que cuando los bomberos la apaguen, les escueza.

Esto nos da una idea del cuidado que los desarrolladores ponen en la creación de aplicaciones UWP y el cuidado con que dan servicio técnico sobre dichas aplicaciones. Seguro que si les mando el bug me responden que won’t fix, como hacía MS hace unos años.

En fin, es lo que hay.

La entrada terminaría aquí si no fuera por la segunda parte, que consiste en un vídeo que he grabado. Esta mañana me he decidido a escribir lo de arriba, así que me voy al Thinkpad, lanzo el juego, hago una captura de pantalla con el soporte de tinta (Win+W, elegir editar captura de pantalla)…

La primera en la frente. Ha tardado un montón a abrirse, tanto, que he mirado si el Thinkpad estaba haciendo throttling. Pero no, estaba yendo bien.

La segunda viene cuando tiro a guardar la captura. Pero mejor lo veis en el vídeo:

Iba tan jodidamente lento, y tan poco feedback visual, que simplemente he pulsado una segunda vez el botón de guardar al ver que no pasaba nada. La primera vez, fuera del vídeo, como ya he dicho, con bastante intervalo. Luego ya en el vídeo, rápidamente para ver si reventaba cual rana intentando competir contra los otros machos… pero no, simplemente abre dos cuadros de diálogo de guardar. Menos mal, porque en otras versiones habría sido un pete en condiciones, con la consiguiente caída de todo el sistema de tinta. Algo hemos avanzado, pero solo algo.

Lo peor de todo no es eso, lo peor de todo es que este error nos da una idea de lo mal que están funcionando las tripas de Windows. Los cuadros de diálogo de abrir/guardar, los estándar, que son los que se muestra, son modales. Eso quiere decir que, en una aplicación, abierto uno, la aplicación deja de funcionar hasta que se cierre, al menos el thread de la UI, que es lo que puede tocar el usuario.

Sin embargo aquí vemos dos errores simultáneos:

1.- Dos cuadros modales simultáneos. El segundo no debería haberse abierto, ni luego dejar que se pueda saltar de uno a otro. La única solución a eso que se me ocurre es que los hayan abierto sin modo, cosa que se puede hacer pero que es más peligrosa que una caja de bombas conmigo al lado: vas a guardar un archivo que puede ser modificado mientras lo guardas… Como poco, habrá cambios que no se guarden, y eso si no revienta todo por problemas de sincronización (que es intentar leer/escrbir a la vez en una misma dirección de memoria, pudiendo dejar la aplicación completamente inestable.

2.- ¿Cómo es posible que se pueda disparar un segundo evento mientras se está ejecutando el anterior? Me explico. Al pulsar el botón en la UI, este genera una llamada a función en el hilo principal, y esa función (ese pedazo de código) es el que creará el diálogo modal y lo mostrará, esperando la acción del usuario, sin hacer nada más y bloqueando el hilo principal de la aplicación, hasta que el usuario elija un archivo, y lo guarde (o lo abra).

Por lo tanto, a simple vista, y según el concepto clásico de Win32, no es posible disparar un segundo evento generado por un elemento visual hasta que el anterior haya terminado. Además, uniendo eso al hecho de que los cuadros de diálogo son modales… uf, me da muy mala espina, pero muy mala.

Porque… los eventos y las aperturas de cuadros de diálogo, en las aplicaciones UWP, se deben ejecutar mediante el API asíncrono… ¿A cualo? Es más fácil de entender que de explicar. Lo que ocurre cuando disparas un evento, aunque el evento es síncrono, el código de su interior se ejecuta de forma asíncrona, y la UI debe o bien ejecutar la llamada asíncrona con await, o encadenar las diferentes acciones una dentro de otra…

Internamente Windows crea una máquina de estados con el código, de manera que deje “vivir” a la interfaz y que la aplicación pueda responder ante eventos externos (como un redimensionamiento, un cambio de orientación, o algo recibido, digamos, por un puerto serie).

En Windows [Phone] 8, ese código estaba roto de origen, y la máquina de estados petaba periódicamente sin motivo aparente, de forma bastante aleatoria y frustrante para los desarrolladores, que veían cómo código perfectamente válido no terminaba de funcionar bien, y encima de forma aleatoria.

Parece ser que en Windows 10 esos crashes ya no se producen, pero se producen otras cosas raras como la comentada aquí…

Lo siento, no lo he explicado bien ni en profundidad. Hacerlo requeriría casi un libro, pero me da una muy mala espina que eso pudiera ocurrir.

Una explicación bastante peregrina sobre el que se abran las dos ventanas puede venir porque Windows guarde el segundo evento en su cola de eventos, y una vez haya terminado el primero, ejecute el segundo sobre el mismo botón, pero resulta que el primero todavía no ha terminado, lo que me hace sospechar de una chapuza [más] en el código UWP.

Ahora, si no estuviera hasta los cojones de Windows 10 y las UWP, haría una aplicación demo, experimentaría un poco y escribiría sobre ello. Por qué realmente ocurre y si es un error de Windows o algo intencionado. Pero lo siento, chicos, tengo cosas mejor que hacer, como tumbarme a la bartola a leer mis Julio Verne.

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