Freigeben über


APPS: Depurando un error de navegación desde un Tile

Tanto Windows Phone como Windows 8 tienen la capacidad de poder adicionar un tile primario y uno secundario al inicio del teléfono o la tablet. Cuando se hace tap sobre alguno de estos tiles, se genera una navegación hacia alguna página o vista dentro de la app.

Pero en ocasiones al tratar de lanzar la app desde un tile, la app abre y de inmediato se cierra. Esto es obviamente causado por un error en la forma en que programamos la navegación o en el estado que se encuentra la app.

En condiciones normales pondríamos un breakpoint y chequearíamos que sucede; pero dado que estamos lanzando la app desde el inicio, esto quiere decir el el debugger ya no está anclado al proceso de ejecución de la app, así que no podemos hacer depuración.

Cómo proceder entonces para detectar el error?
Una alternativa muy que traigo de mis batallas en la Web, sencillamente consiste en manipular el evento de error no manejado en la clase principal de la ejecución... en Web, esta era la Global.asax.cs y en las apps es App.xaml.cs. Por ejemplo en Windows Phone tenemos dentro de esta clase el manejador del evento:

     private void Application_UnhandledException(object sender, 
        ApplicationUnhandledExceptionEventArgs e)
    {
        if (System.Diagnostics.Debugger.IsAttached)
        {
            // An unhandled exception has occurred; break into the debugger
            System.Diagnostics.Debugger.Break();
        }
        var storage = IsolatedStorageFile.GetUserStoreForApplication();
        using (var writer = new StreamWriter(new IsolatedStorageFileStream(
            "LastError1.txt", FileMode.CreateNew, storage)))
        {
            writer.Write(DateTime.Now.ToLongTimeString() + "\n\n");
            writer.Write(WOW.HistoryTracker.ToString());
            writer.Write(e.ExceptionObject.Message);
        }
    }

Como se observa, lo que hice fue adicionalmente a las líneas de debugging, adicionar una pequeña rutina que copia el contenido de la última excepción a un archivo en el Isolated Storage, que queda como si de caja negra de avión se tratará, con las evidencias de lo que pasó antes de que el avión (la app) se estrellara. De esta manera podríamos por ejemplo poner pistas dentro del código que se escribieran en el archivo para saber en donde está el error. Por ejemplo, podemos tener un StringBuilder global que vaya acumulando la historia de hasta donde se llegó y luego descargue todo su contenido en el archivo. De hecho, podemos usar directivas de preprocesador, para estructurar más el asunto:

 #if DEBUG

            if (WOW.HistoryTracker == null)
            {
                WOW.HistoryTracker = new System.Text.StringBuilder();
                WOW.HistoryTracker.AppendLine("I was Null");
            }
            WOW.HistoryTracker.AppendLine("Directive is working.");
#endif

Luego sencillamente descargamos el contenido del isolated storage a una carpeta en el sistema de archivos convencional, y revisamos:

image

de esta manera ya podemos saber qué nos hace falta arreglar para que la app se lance bien por ejemplo desde un tile secundario.