Pages

vendredi 31 décembre 2010

ASP.NET MVC et mobiles

Lors de ma dernière visite à Redmond, j’ai eu la chance d’avoir été reçu par Vishal Joshi (Senior Program Manager dans l’équipe « Web platform & tools »).
En tant qu’utilisateur final de VS et avec mon penchant pour l’écriture d’application Web Mobile, Vishal était curieux de savoir comment, avec les techniques mises à notre disposition par Microsoft, j’envisageais l’architecture et l’écriture de ma prochaine application.

Préambule

Le développement pour le WEB mobile a quelques particularités :
•    La maitrise du poids des pages et des données transmises est importante
•    Il y a généralement moins de fonctions (ou elles sont plus simple) dans une application WEB mobile par rapport à son équivalent WEB
•    L’ergonomie des applications WEB Mobile est très différentes des applications classiques : elles doivent être moins complexes et moins nombreuses, les interactions doivent être évidentes et les résultats des actions doivent être visibles et sans ambiguïtés
•    Du fait qu’il s’agit d’un marché en plein extension, nos applications doivent elles aussi être facilement et fortement upgradable pour prendre en compte toutes sortes de nouveaux périphériques, les constructeurs nous préparent des tablettes diverses et variées, et je ne parle même des écrans de nos télévisions transformés en navigateur et des consoles de jeux. Une forme d’illustration d’un slogan de MS qui m’avait accroché une appli trois supports.

Définition de « Device »

Dans la suite de cet article, je vais utiliser le terme de « Device » pour nommer les différentes plateformes mobile dans un terme générique.
Ces devices peuvent être schématiquement et succinctement décrit comme suit :





Nous pouvons étendre cette définition de « device » aux browsers et leurs sempiternels problèmes de compatibilité.
Par exemple, J’ai encore rencontré récemment un client équipé d’IE 4.7, j’ai eu l’idée de traiter ce problème en considérant qu’IE 4.7 était un device particulier ayant des écrans plus simples et beaucoup moins de fonctions.
J’ai trouvé ce système plus élégant que les longues énumérations « if (browser LT 6)… » Directement dans les page WEB, Je considère maintenant les navigateurs « à problèmes » comme des devices particuliers. Mon code n’en n’est que plus maintenable et plus lisible.


Réflexion sur le développement

Sa première question était : ASP.NET « classique » ou MVC ? Je lui réponds sans hésiter MVC en le justifiant par les arguments : un meilleur contrôle de code HTML, moins de problèmes de compatibilité avec les browsers et enfin et surtout, une taille des pages mieux maîtrisée, c’est un critère important dans le cadre du développement d’application Web Mobile.


L’architecture MVC

Ensuite, il m’énumère sur son tableau blanc quelques façons d’envisager le développement proprement dit en ASP.NET MVC vu sous l’angle d’application « multi-devices » (web, web mobile pour le téléphone, web mobile pour les tablettes…).
1. Une area pour chaque « device »
  • Avantages :
    • Plus claire, plus lisible
    • Permet de bien isoler les différents devices (notamment au niveau des scripts JavaScript et CSS)
  • Inconvénients :
  • Oblige à avoir autant de contrôleurs, de modèles et de views que de devices, ce qui peut induire pas mal de code redondant et une maintenance difficile dans les cas de nombreux devices
2. « Model » et « Controller » identique mais des « Views » différentes par devices.
  • Avantages :
    • Seule les vues sont adaptés aux devices ce qui simplifie l’écriture et maintient seulement un contrôleur et un seul modèle, ce qui est adapté dans des solutions s’adressant à des devices très similaires (par exemple les mobiles) et aux comportements et données très similaires
  • Inconvénients :
    • Pas très adapté à l’écriture d’une solution complète : WEB + « WEB Mobile », Le contrôleur unique et le modèle unique devenant handicapant autant dans la lisibilité du code que dans le poids des données envoyées aux device 
3.    Un seul « Model View Controller » avec des choix conditionnels au sein des « controllers »
  • Avantages :
    • Un seul et même contrôleur pour tous les devices qui change directement dans le code le comportement à adopter pour chaque device. Efficace et rapide quand on a moins de 3 devices à supporter
  • Inconvénients :
    • Le code peut rapidement devenir compliqué, voire illisible, si le nombre de devices augmentent
    • Rend difficile les comportements complexes ou très différenciés

4.    Différents « View » et « Controller » mais basés sur un même « model »
  • Avantages :
    • Permet une bonne adaptation des vues et des comportements aux devices
    • Permet de garder un seul et même modèle et donc l’unicité des objets « Business/Work »
  • Inconvénients :
    • Le poids des données à envoyer aux devices n’est pas bien calibré et elles ne sont pas forcément adaptées
5.    Différente « View-models» & « View » pour chaque devices :
  • Avantages :
    • Adapte finement les modèles à chaque device (ou à chaque écran) et donc, calibre bien le poids des données à envoyer.
    • Permet l’héritage d’un modèle « principal » qui donne un code plus concis et donc plus maintenable
  • Inconvénients :
    • Plus d’objets « Model » à maintenir, et donc plus de codes, et en définitive, plus de risque de bogues.
A différencier du MVVM applicable à WPF/Silverlight : Blog de Stephen Walther
En résumé, la « view-model » est une forme de modèle adaptée au device.
cf. “NerdDinner Step 6”: ViewData and ViewModel


Les différents modèles


Mon choix

Nous entamons une sorte de brainstorming sur les différentes manières de faire et j’argumente sur mon point de vue « utilisateur final » sur les avantages/inconvénients de chaque solution.

Mon premier  choix est le « ViewModel/View », il a l’avantage d’adapter un seul et même modèle à plusieurs vue (et donc device) par le mécanisme des « Vue-Modèle ». Et cela, c’est bon pour la lisibilité et la maintenabilité du code, même s’il y a des objets en plus, ce découplage du modèle vis-à-vis des vues permet une bonne calibration et un bon contrôle des données envoyés aux devices et donc la possibilité d’alléger les téléchargements des données pour les devices parce qu’il est courant de ne pas avoir autant de données et de fonctions sur un device mobile que sur un PC.

Mon deuxième choix serait « Différents « View » et « Controller » mais basés sur un même « model », c’est celui que j’ai l’habitude d’utiliser pour sa simplicité de compréhension et  sa logique « un modèle »  et des vues et contrôleurs adaptés aux différents devices.


Conclusion

En conclusion, les différentes façons de procéder exposée dans cet article ne sont pas les seules possibilités offertes pas ASP.NET MVC, l’important est de trouver une solution simple et élégante à son problème.
Dans l’optique où les applications Web que nous écrivons sont probablement de plus en plus utilisées sur des téléphones, Smartphones et tablettes, nous  nous devons de les écrire dans tes technologies les plus adaptées, pour que l’expérience utilisateur soit la plus réussie possible quel que soit le support.

Remerciements

Un grand remerciement à Vishal pour m’avoir reçu et avoir pris le temps de discuter avec moi du produit qu’il fabrique et que j’utilise. Le souci de ces équipes MSFT d’avoir les sentiments et ressentis des utilisateurs finaux sur leurs produits m’a beaucoup et agréablement surpris. Même si je suis MS Friendly, j’essaye d’être objectif, et tout n’est pas parfait chez MS, mais cette proximité m’a beaucoup plu.