• Home

Gestion du cache avec HttpClient & Windows Phone

Introduction

Aujourd’hui la meilleure option pour consommer un service REST qui renvoie du JSON est d’utiliser la classe HttpClient. Or lorsque l’on utilise cette dernière dans une application Windows Phone, il faut prendre garde à la gestion spécifique du cache avec cette plateforme. En effet pour une application de type Windows, chaque requête sera transmise au serveur et les données récupérées seront bien celles attendues. Par contre avec une application Windows Phone, plusieurs appels successifs à la même adresse retourneront la même réponse car celle-ci sera issue du cache intégré à l’application.

Mise en évidence du problème

Pour mettre en lumière le problème décrit précédemment, voici une méthode qui permet de récupérer les horaires des transports en commun de Los Angeles. Cette dernière appelle l’api toute les deux secondes et affiche l’horaire retourné. En toute logique, ce dernier évolue dans le temps car le bus ou le métro correspondant à la ligne demandée se déplace.

Résultat avec une application console

Lorsque le code est appelé depuis une application console, on constate bien que le champ « seconds » diminue à chaque appel. Nous avons donc bien le comportement souhaité.

Résultat avec une application Windows Phone

Maintenant si le même code est appelé depuis une application Windows Phone, vous pouvez constater que toutes les lignes sont identiques. Ceci est dû à la mise en cache des données. Ainsi lors du premier appel, l’application récupère bien les données, mais pour les appels suivants, ce sont les informations en cache qui sont retournées.

Solution

Pour avoir un fonctionnement conforme à ce que l’on peut attendre, il faut désactiver le cache. Pour cela il faut modifier l’objet « DefaultRequestHeaders » pour lui ajouter la date actuelle à la propriété « IfModifiedSince ». Ainsi le cache est désactivé.

Si l’on relance le même code avec le workaround activé, on constate que les données sont bien récupérées. Il est cependant important de noter que la désactivation du cache est intéressante pour des données qui sont très volatiles. En effet si vous utilisez des services type météo dont les données ne changent que quelques fois par jour, il est préférable de laisser le cache activé, cela réduira la consommation réseau de l’application mobile.

Formatage du code avec Resharper

Pour moi Resharper est un des outils indispensables lorsque l’on souhaite développer en .Net. Je ne m’attarderais pas sur l’étendue des possibilités offertes par cet outil car ce n’est pas l’objectif de ce billet. Cependant, parmi ces fonctionnalités, il en existe une qui permet de reformater son code selon un schéma qui est modifiable. On peut donc définir ses propres règles. Je vous propose donc de voir comment faire et quelle est la syntaxe à utiliser pour avoir un code parfaitement ordonné.

resharper

Méthode virtuelle & async await

Introduction

Dans une application utilisant MVVM, j’écris souvent une classe de base pour mes ViewModels. Cela me permet par exemple de définir une méthode LoadData qui sera appelée automatiquement lorsque la vue est affichée. Voici un exemple d’implémentation de cette classe :

Navigation avec Windows Phone

Introduction

La première chose qui est un peu déroutante lorsque l’on écrit sa première application Windows Phone est la navigation entre les différentes vues. En effet contrairement à une application WPF, il faut utiliser le NavigationService pour basculer d’une vue à une autre. Or ce service n’est accessible qu’à partir du code de la vue. Et lorsque l’on utilise un Framework MVVM pour construire son application mobile, ce dernier ne sera donc pas accessible depuis un ViewModel. Nous allons donc voir dans cet article comment créer un handler de message (avec MVVM Light) qui prendra en charge la navigation entre les différentes vues et ce depuis n’importe quel ViewModel.

Définition du handler de message

Cette première étape consiste à enregistrer dans le code de la vue principale le message qui contient l’Uri de navigation et qui servira à appeler le NavigationService.

Async Await par l’exemple – Partie 1

Introduction

Cet article est le premier d’une série dont l’objectif est de fournir un exemple concret sur l’utilisation des nouveaux mots clés async et await. Pour débuter nous verrons l’utilisation des éléments suivants : CancellationTokenSource, Progress et ContinueWith.

Présentation du projet

Le projet qui servira d’exemple se base sur un problème mathématique : le tour du cavalier. Ce problème consiste à trouver une solution pour déterminer l’ensemble des chemins que peut parcourir un cavalier sur un échiquier sans jamais passer deux fois par la même case. Le projet ci-dessous calcul à partir d’une case donnée l’ensemble des solutions possibles.

Lightbox Image

Ce problème est intéressant dans le cadre de cet article car lancer les calculs en parallèle permet de trouver les solutions plus rapidement et donc ainsi mettre en œuvre nos mots clés async et await. Pour ce faire l’algorithme de résolution va construire un arbre des solutions. Ainsi pour chaque nœud de l’arbre qui représente une case, on lui ajoutera autant de branches qu’il y a de destinations possibles pour le cavalier. A la fin on obtient un arbre qui contient toutes les solutions.

Pourquoi la complexité du code est importante pour les tests unitaires

Lors de l’écriture d’un code complexe comme par exemple un algorithme de calcul, les tests unitaires sont des éléments importants car ils vont permettre de vérifier le bon fonctionnement de ce dernier.

Imaginons donc que notre application ait besoin d’un algorithme de calcul et que ce dernier puisse être écrit de la façon suivante :

Après l’écriture de cet algorithme, il sera nécessaire de réaliser un certains nombres de tests unitaires afin de s’assurer que le résultat retourné pour la méthode GetResult correspond bien à celui attendu.

Web Analytics