Pues eso… que este post iba a ser una especie de declaración de «mi» incapacidad a la hora de trabajar de forma asíncrona con los ficheros de una aplicación de Windows Store, y al final será una especie de truco o consejo de cómo hacer las cosas con todo esto de el acceso a ficheros de forma asíncrona (la única que conozco para Windows Store).

Y la solución no es porque «yo» haya dado con la respuesta, bueno, un poco sí, ya que si no hago un par de búsquedas en Google lo mismo no hubiese dado con la respuesta.

Y digo «un par» de búsquedas por no decir tres, ya que es complicado algunas veces encontrar respuestas, sobre todo porque la mayoría de las preguntas con respuestas están en inglés y después porque no sabes con certeza cómo «plantear» la búsqueda…

Y lo curioso es que al tercer intento con esto: «GetFileFromApplicationUriAsync don’t» es cuando ha salido la respuesta, y precisamente en el primer lugar:

 

 

Y eso que en la búsqueda anterior lo puse un poco más concreto, en fin… estos buscadores y/o los usuarios de los mismos… ¡habrá que apañarlos! 😉

 

Te explico de qué va la cosa:

Estoy haciendo una aplicación para Windows 8 (Windows Store) en la que quiero mostrar el contenido de unos ficheros de textos. Para ello estoy usando una versión adaptada del tipo de proyecto Split App en el que todo el contenido está basado en «bindings», pero ese no es el problema, el problema es que en la clase SampleDataSource estoy haciendo una serie de cambios para que se adapte a lo que yo quiero, y como el texto a mostrar es bastante grande como para «pegarlo» en la propia clase (tal como hacen en el proyecto de ejemplo) me puse a crear un código que leyera el contenido del fichero y lo asignara adecuadamente a una propiedad de la clase usada como «binding» que es la que muestra el texto final.

Así que… se me ocurrió usar este código (y algún otro con distintas pruebas):

 

Dim ficUri = New Uri("ms-appx:///contenido/" & fic)

' aquí se queda colgado (algunas veces)
' las veces que pasa de aquí es en modo debug y haciendo un break
' (pero no siempre)
Dim file = Await StorageFile.GetFileFromApplicationUriAsync(ficUri)

' Aquí también se para, y pasa si hay un breakpoint
Dim sf = Await file.OpenStreamForReadAsync

Using sr As New StreamReader(sf, Encoding.UTF8, True)
    sBody = sr.ReadToEnd()
End Using

Return sBody

 

Y tal como comento en los comentarios (valga la redundancia) cuando estaba en funcionamiento «natural» no pasaba de ahí y se quedaba colgada la aplicación.

Ya estaba por desistir cuando me ha dado el punto de buscar en Google ya que suponía que no sería cosa mía y que seguramente a alguien más le habrá ocurrido… ¡y así es!

Nota: antes de buscar en Google ya busqué información en la documentación de Visual Studio, pero no encontré nada, aparte de los ejemplos triviales que suelen poner que que dan por hecho de que prácticamente te lo sabes todo, todo, todo… en fin…

No me voy a enrollar más de la cuenta y te pongo el código correcto para hacer esa tarea de leer un fichero de forma asíncrona y que no se quede colgada la aplicación de Windows Store.

 

También te pondré el enlace a esa pregunta y un artículo del autor de la respuesta donde explica porqué pasa eso, no, mejor dicho: «porqué nos pasa eso a los principiantes» del acceso asíncrono, o eso he entendido yo de este párrafo:

«I think it’s the most-asked question by async newcomers once they’ve learned the basics.»

Y tiene razón ya que reconozco que soy un newcomer en esto de el acceso asíncrono, al menos para los ficheros en el directorio de la aplicación, ya que antes he estado accediendo de forma asíncrona a otros ficheros (del Local storage) y ha funcionado… en fin…

 

Dim ficUri = New Uri("ms-appx:///contenido/" & fic)

Dim file = Await StorageFile.GetFileFromApplicationUriAsync(ficUri).AsTask().ConfigureAwait(False)

Dim sf = Await file.OpenStreamForReadAsync().ConfigureAwait(False)

Using sr As New StreamReader(sf, Encoding.UTF8, True)
    sBody = sr.ReadToEnd()
End Using


Return sBody

 

Como puedes ver, la solución es agregar .AsTask().ConfigureAwait(False) al final del método GetFileFromApplicationUriAsync que es el que se encarga de obtener el fichero desde el directorio de la aplicación, y de ConfigureAwait(False) al método OpenStreamForReadAsync que es el que se encarga de convertir dicho fichero en un Stream de lectura.

 

La explicación del porqué del uso de esos métodos está en el comentario que hizo Nito al preguntarle el «buscador de respuestas» porqué era necesario hacer eso:

(te lo pego en inglés que la traducción automática como que no me convence)

Explanation is quite simple: when you use task.Result ortask.Wait() on GUI thread in conjunction with await keyword you’re causing deadlock. This happens because after awaiting code is resumed on the same context it was invoked (in your case – GUI thread). And because GUI thread currently waiting for task to complete (via Result or Wait()) deadlock arises and code after await keyword will never be invoked. ConfigureAwait(false)specifies that current context can be ignored and thus allows your code to complete successfully. More details on this here: http://nitoprograms.blogspot.com/2012/07/dont-block-on-async-code.html

 

Este es el enlace a la pregunta/respuesta esa que te comentaba y este otro es al artículo de Nito Programming.

 

Espero que te sea de utilidad.

 

Nos vemos.

Guillermo

…