Les applications Windows 8 sont souvent trop gourmandes en espace disque

Il y a de plus en plus d’applications disponible sur le Store et si vous êtes comme moi, curieux de voir ce que peuvent développer les autres, vous installez un tas d’applications. Vous les installez afin de les analyser, d’un point de vue design, ergo, etc… Ensuite vous ne les désinstallez pas forcément, pour pouvoir les montrer ou vous inspirer des plus réussies ou encore avoir des exemples de ce qu’il ne faut pas faire.

Dans ce post, je n’attaque personne en particulier, et je ne connais pas forcément le ou les développeurs ayant travaillés sur les applications que je prendrai en exemple. D’ailleurs mon objectif n’est pas de faire la critique d’une ou plusieurs applications, mais de sensibiliser les développeurs d’applications Windows 8 sur un point qui est jusqu’ici très souvent mis de côté, l’espace disque.

Cet espace disque, comme vous le savez, n’est pas infini, et l’est encore moins sur une Surface RT 32Go. Or je constate que beaucoup d’applications stockent des mégaoctets de données voir même pour certaines des gigaoctets dans le répertoire locale de l’application et que ce n’est pas toujours justifié.

Nous avons parlé lors du DevCamp Back to basics de la semaine dernière des différentes API de stockage ou d’accès aux données. Ce n’est que la veille de ce DevCamp que j’ai constaté que les applications que nous installons occupent souvent plusieurs mégaoctets d’espace disque et que l’espace occupé par ces applications grandit au fil des jours et de leur utilisation. Or j’ai du mal à comprendre comment une application pour laquelle je ne produis pas de données, mais que je ne fais qu’en consommer, qui plus est, une infime partie de ce qu’elle me propose, prenne aujourd’hui 10Mo, 100Mo, 500Mo, voir 1Go… Ma pauvre Surface risque de ne pas s’en remettre! Ce constat est intervenu trop tard pour que j’en fasse la démo au DevCamp, mais c’est tout de même pour cette raison que j’ai abordé dans mes slides la notion de TemporaryFolder en réexpliquant à quoi sert ce répertoire…

Mise en Cache et TemporaryFolder

Il existe une API disponible pour les applications Windows 8 qui s’appelle TemporaryFolder (ApplicationData.Current.TemporaryFolder). Cette API est disponible au même endroit que le LocalFolder ou encore que les RoamingSettings. Ce fameux TemporaryFolder sert à stocker des données dans un répertoire temporaire, comme son nom le laisse penser. Cela signifie que l’utilisateur a la possibilité de supprimer le contenu de ces répertoires temporaires via l’outil de nettoyage de disque, ou encore que le système peut lui aussi supprimer ce contenu pour récupérer de la place.

Cela signifie également que si l’on stocke des données dans ce répertoire, on ne peut être sur qu’elles seront encore là au prochain lancement de l’application. C’est en général, le principe de base d’un Cache. Un Cache est souvent utilisé pour stocker des données de manière temporaire. Il a besoin d’être invalidé et rafraichit au bout d’un certain temps, et peut même être supprimé si on n’y a pas accédé depuis un certain laps de temps. Ce qui permet de ne pas occuper d’espace disque inutilement (ou même d’espace mémoire dans le cadre d’un cache mémoire).

Quand doit-on utiliser ce répertoire temporaire ou comment peut-on mieux gérer l’espace occupé par les contenus, souvent éphémères et considéré comme du Cache ?

On peut quasiment toujours utilisé le stockage temporaire. Lorsque j’inspecte les applications installées sur mon poste (je me rends dans le répertoire LocalState des différents packages), je vois très souvent un répertoire nommé “Cache”. Pourquoi dans ce cas ne pas le mettre dans le stockage temporaire ?

Il faut également différencier mise en cache et fonctionnement Offline.

La mise en cache est généralement utilisé pour éviter de devoir télécharger plusieurs fois un même contenu, afin d’améliorer la fluidité de l’application, dans la navigation, les animations, les transitions et éventuellement le chargement.

Prenons l’exemple d’une application de type News/Actus. Il est beaucoup plus agréable en terme d’UX de télécharger les différentes Unes et articles du moment en local, ainsi que les différents médias associés tels que les images. Cependant, a-t-on besoin que ces différents articles soient disponible “à vie” ? Quel serait le soucis si ces données étaient stockées dans le répertoire temporaire ? On aurait les avantages du stockage local, avec en plus l’avantage pour l’utilisateur de gérer son espace disque. Et si le système est en manque de ressources de stockage, il peut lui aussi décider de nettoyer ces données, qui ne sont clairement pas vitales pour l’utilisateur.

Vérifier l’espace occupé par les applications Windows 8

Lorsqu’on est utilisateur de Windows 8, il est possible de vérifier l’espace occupé par les applications depuis les paramètres du PC et ainsi trouvé les applis “Gloutons” :

windows-live-writer_eebaed15233e_99a2_image_thumb

Analyse de quelques applications

Ci-dessous quelques exemples d’applications pour lesquelles j’ai analysé le contenu et la taille du répertoire local. Mon choix s’est arrêté sur ces quelques applications pour plusieurs raisons. Premièrement car je les avais installé lorsque j’ai fait ces analyses. Deuxièmement, car elles étaient représentatives du problème soulevé avec des scénarios de stockage différents. Il y a bien sûr d’autres applications sur le Store avec des problèmes de stockage. Tout ça pour dire que le choix des apps n’est pas arbitraire.

L’application Télé7

Prenons tout d’abord l’exemple de l’application Télé7, qui, si vous ne l’avez jamais testé, l’essayer, c’est l’adopter. Elle fonctionne avec une base de données locale de type SQL LITE, qui pèse environ 24Mo. Cette base est téléchargée à l’ouverture de l’application si la base actuelle a plus de 3 jours. Ceci permet à l’application de fonctionner en mode Offline, vous avez donc accès à votre grille des programmes TV sans avoir besoin d’internet. C’est une très bonne idée, et je l’ai d’ailleurs installé sur tous mes devices (laptop, Slate 7 et Surface).

windows-live-writer_eebaed15233e_99a2_tele7_thumb

Par contre en regardant ce qu’il se passe dans le répertoire LocalState je m’aperçois qu’il contient toutes les bases de données téléchargées depuis l’installation de l’application. Une base de données fait environ 24Mo. Pour l’instant j’en suis à 9 base de données locales, donc 216Mo.

Dans le cas de Télé7, on peut effectivement se dire qu’il est préférable de stocker la base de données en local, et non dans le Temp. Mais il faut dans ce cas une stratégie de rétention des données de l’application, afin de supprimer les anciennes bases. Je suis sûr que ce problème sera rapidement corrigé…

L’application Dior Mag

Prenons un autre exemple, cette fois dans une autre dimension… Le luxe a un cout, et pas seulement au niveau du porte monnaie mais également en stockage. La marque Dior a son application Windows 8, Dior Mag, application très jolie soit dit au passage. Attention si vous l’installez sur une Surface RT 32Go, elle prendra bientôt plus de place que l’OS!

windows-live-writer_eebaed15233e_99a2_diormag_thumb

Actuellement sur mon poste l’application prend pas moins de 1,27Go (11 972 fichiers de type jpeg et text/json), avec en local des fichiers datés d’octobre à janvier. Je vous rassure tout de même, l’utilisateur a la possibilité depuis le Charm des paramètres de l’application de supprimer le Cache. Mais l’utilisateur est-il invité à un moment ou à un autre d’utiliser ce Charm ? D’autre part, l’utilisateur de cette belle application a-t-il besoin d’avoir accès en local à tous les catalogues depuis son installation ?

Si vous voulez faire un petit test, vous pouvez supprimer tout le contenu du répertoire LocalState de ce package, ainsi que le fichier settings.dat. Une fois ces fichiers supprimés, au lancement de l’application, tous ces fichiers seront téléchargés. La logique de présence des fichiers est bien là. Pour les mettre dans le répertoire temporaire, il suffit de changer au niveau du code LocalFolder par TemporaryFolder.

L’application Bing

Un autre exemple, l’application Bing. Cette fois nous revenons dans des tailles de stockage très raisonnable, mais un choix de stockage vraiment incompréhensible.

windows-live-writer_eebaed15233e_99a2_bing_thumb

Si nous inspectons le répertoire de stockage de cette application, nous nous rendons compte qu’elle stocke les images de background utilisée par Bing. Or ces images changent régulièrement, parfois plusieurs fois par jours, et ne sont apparemment jamais supprimées.

Bien sûr ici l’espace de stockage utilisé par ces images n’est que de 4,5Mo (32 images depuis octobre, pour moins d’une dizaine d’ouverture de l’application). Par contre ceci est vraiment incompréhensible, dans le sens où les quelques images du jour ne pèsent que 300Ko et que toutes les autres images ne serviront plus jamais. Et pour cette application, on ne peut pas dire qu’il y a un mode Offline… Ici les images auraient dû être stockées dans le répertoire temporaire.

L’application Techdays 2013

L’application Techdays 2013, que je trouve très réussie, fluide et agréable à utiliser, est idéale pour gérer votre agenda de sessions pour cet évènement.

windows-live-writer_eebaed15233e_99a2_techdays2013_thumb

Cette application est fonctionnelle en mode Offline. Je désactive mon accès internet, et j’ai accès à toutes les sessions, les fiches des speakers, les photos, mon agenda… Nous avons donc en local toutes les informations nécessaires au bon fonctionnement de l’application. De ce côté c’est parfait.

Par contre, si je regarde ce qu’il se passe du côté du stockage local, ça fait peur… Dans un répertoire nommé Cache, j’ai pas moins de 625 fichiers (json), qui pour la plupart ont exactement le même contenu. On s’aperçoit que, quasiment à chaque lancement de l’application, tout le contenu est re-téléchargé en local si connexion internet il y a. Et que l’ancien contenu n’est pas supprimé.

Le fait d’avoir tout le contenu en local est évidemment une bonne idée, et c’est entre autre pour cette raison que l’application se charge rapidement et qu’elle est fluide et agréable à utiliser. Mais d’une part, je ne pense pas qu’il y ait besoin de télécharger et restocker ce contenu à chaque lancement de l’application (un numéro de version dans le json permettrait de palier à ce problème), et d’autre part il faudrait que les contenus précédemment téléchargés soient supprimés. Ce matin j’étais à 15Mo de stockage pour cette application. Cet après midi, après 4 ou 5 ouvertures de l’application, je suis à 21Mo. Et pourtant, le contenu est le même, pas de sessions ou de speakers supplémentaires.

Ici on voit bien que ces données sont utilisées comme un cache local pour fluidifier la navigation de l’application et à la fois pour offrir un mode Offline. Ces données pourraient être placées dans le TemporaryFolder, sauf pour l’agenda, qui doit rester local ou distant. Si l’on persiste à enregistrer ces données dans le LocalFolder, il faut mettre en place une politique de rétention des fichiers.

Conclusion

Je pense que l’API TemporaryFolder est vraiment méconnue des développeurs ou qu’ils n’en connaissent pas l’utilité. Mais ce n’est pas une excuse. Le fait que des anciens fichiers, qui ne serviront plus et qui vont rester dans le stockage local jusqu’à désinstallation de l’application n’est pas normal. L’utilisateur n’a pas d’autre choix que de désinstaller l’application pour nettoyer ce stockage. Vous pouvez vous même faire l’expérience suivante : rendez-vous dans le répertoire UsersYOUR_ACCOUNTAppDataLocalPackages. Parmi tous ces packages, effectuez une recherche des répertoires TempState, puis LocalState et comparez la taille totale utilisé par chacun de ces répertoires.

Parmi les applications que j’ai installé sur mon laptop, celle qui est la moins jolie, mais qui reste fonctionnelle, c’est l’application Windows Phone, qui permet de transférer/synchroniser des données entre son téléphone et son PC. Et bien parmi toutes les applications que j’ai actuellement (68 applications au total), c’est la seule qui possède du contenu dans le répertoire temporaire… Comme quoi, on peut faire des applications moches, mais fonctionnelles, et techniquement bien pensées.

Si vous pensez que votre application doit finalement utiliser ce stockage temporaire plutôt que le stockage local, il vous suffit simplement de changer dans votre code LocalFolder par TemporaryFolder. Et si ce n’est pas le cas, n’oubliez pas de supprimer les anciens fichiers, sinon ce sont les utilisateurs qui supprimeront votre application.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s