Données éditables essentielles : Roaming Settings [Priorité Haute]

Dans l’idéal, si l’utilisateur fait n’importe quelle modification, elle devrait apparaître sur tous ses appareils. En pratique, vous devez prioriser les informations pour les découper en fonction de votre volumétrie et des contraintes de taille de Roaming Settings.

Pour les volumétries attendues par cette application, j’ai pu sauvegarder en Priorité Haute une série d’informations numériques importantes (points d’expérience, dégâts, etc) – ce qui permet à un utilisateur de continuer un combat même en changeant d’appareil.

Astuce 1 : Sachant que nous sommes limités à 8Ko de RoamingSettings en priorité haute, vous devez considérer une sérialisation manuelle de vos objets, pour minimiser la mémoire consommée. Vu que je ne pouvais avoir qu’une seule ApplicationDataCompositeValue en priorité haute, j’ai opté pour avoir une liste de clés-valeurs du style {characterIndex, “0;3;78;0”}.  Après j’ai créé une façade RoamingCharacterData qui permet de simplifier la gestion de ces valeurs. Si, par exemple, je voulais connaitre les points d’expérience d’un personnage,  je pourrais faire :

    new RoamingCharacterData(characterIndex).GetPriority(2)

 

Ici 2 est l’index du nombre demandé dans le tableau en question, c’est à dire 78 dans notre cas. A partir de ça on peut imaginer une classe Character qui contient certaines propriétés qui sont sérialisables (pour sauvegarder dans LocalStorage) et d’autres qui proviennent de RoamingCharacterData (pour sauvegarder dans RoamingSettings).

Astuce 2 : Les API de settings ne présentent pas comment gérer la modification d’une valeur. Dans le cas d’une valeur complexe, il est recommandé de la lire, la recréer avec la modification et écraser l’existante :

    ApplicationDataContainer roamingSettings = ApplicationData.Current.RoamingSettings;
    var priorityData = roamingSettings.Values.ContainsKey("HighPriority")?
                        roamingSettings.Values["HighPriority"] as ApplicationDataCompositeValue :
                        new ApplicationDataCompositeValue();
    //<modifiy priorityData here>

    roamingSettings.Values["HighPriority"] = priorityData;

    

Données éditables non-critiques : Roaming Settings

Et que fait-on avec les 92Ko restants ? Le plus possible ! Dans mon cas j’ai pu les utiliser pour les informations éditables textuelles courtes et pour  les choix utilisateur qui concernent l’interface (exemple : ordre de visualisation des pouvoirs d’un personnage). Ce sont des informations qui ne sont pas critiques pour reprendre l’application depuis un autre appareil.

Librairie et Notes : Local Storage à la suspension

Si vous avez lu les commentaires de SuspensionManager, fourni avec les templates d’application Windows 8, vous savez déjà qu’il est censé sauvegarder des valeurs simples. Oui, vous pouvez sérialiser n’importe quel objet à la suspension d’une application, mais :

• Vous avez peu de marge de réaction en cas d’erreur.
• Vous risquez de dépasser le temps alloué par le système pour la suspension de votre application.
• Vous risquez de perdre ces données en cas d’exception inattendue.

C’est pour ces raisons que dans mon cas j’ai opté pour la sauvegarde de seulement 3 types d’informations :

1. L’état de navigation (fourni en partie par le template de base, mais incluant aussi dans mon cas deux variables qui me permettent de revenir à l’endroit précis où l’utilisateur était).
2. La bibliothèque des personnages : une liste d’informations basiques pour lister les 2-40 personnages. Pour une structure plus complexe, vous devez considérer une base de données locale.
3. Les notes (un champ texte par personnage). Cette donnée était trop grande à inclure dans les données en itinérance. Si vous avez une grosse volumétrie de données de ce type, vous devez considérer une synchronisation à la main (ie sans utiliser RoamingSettings).

Astuce : Si vous optez pour sauvegarder une structure à la suspension au lieu de l’avoir dans une base de données, vous devrez probablement implémenter une résistance aux fautes. Dans mon cas, il suffisait de relire les fichiers stockés dans LocalStorage pour récréer la structure de librairie.

Données éditables sur D&D Insider : Web

Comme déjà mentionné, certaines données (XP, Notes) doivent être synchronisées avec le compte D&D Insider de l’utilisateur. Nous avons déjà présenté comment ces données sont sauvegardées et synchronisées entre les appareils de l’utilisateur, mais il faut aussi appeler les web services de D&D Insider pour mettre à jour les personnages en ligne. Il faut alors mettre en place une infrastructure de suivi de modifications (une date de dernière mise à jour et un champ IsDirty) et aussi appeler les services :

1. En tâche de fond (quand l’utilisateur n’utilise pas l’application) pour chaque personnage avec IsDirty=true.
2. Juste avant chaque mise à jour de personnage par le web (premièrement nous uploadons les modifications récentes et après nous re-téléchargeons la totale).

Astuce : Si l’appel de web service à l’étape 2 ne marche pas, il faut faire attention de ne pas écraser les modifications locales avec le contenu qui provient du web.

    var credential = passwordVault.RetrieveAll().FirstOrDefault(c => c.Resource == PrimaryAccountKey);
    if (credential != null)
       credential = passwordVault.Retrieve(PrimaryAccountKey, credential.UserName); //this will populate the password
    

void App_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
    try
    {
        ApplicationData.Current.LocalSettings.Values[exceptionKey] = e.ToString();
    }
    catch (Exception)
    {
    }
}

private static void ReportLastUnhandledException()
{
    var localSettings = ApplicationData.Current.LocalSettings.Values;
    if (localSettings.ContainsKey(exceptionKey))
         AnalyticsHelper.Track("Exception", "Unhandled", localSettings[exceptionKey].ToString());

    localSettings.Remove(exceptionKey);
}

    AnalyticsHelper.Setup();
    ReportLastUnhandledException();