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.

mercredi 20 octobre 2010

Open ou Pas ?

Il y a 12 ans, j’ai essayé d’installer un serveur Linux pour utiliser HylaFax, l’Open Source, libre et gratuit démarrait en France. L’entreprise dans laquelle je travaillais étant toujours en pointes des dernières technologies, je me suis dit : pourquoi pas nous ?
Quelle distribution prendre ? Pas facile, je me décide pour un Suse, et me voilà partie pour l’installation et là, la découverte que Linux, ce n’est pas Windows, ce n’est pas simple à installer.
Après de nombreux essais mon serveur fonctionne et remplit son rôle de serveur de fax.

Conclusion de ce premier essai
On ne lance pas sur Linux comme ça, il faut se « préparer », ce n’est pas aussi simple que le « Microsoft World »

Peu après, nous avons quelques pages web à  développer, je m’oriente vers le choix Java sur un serveur Tomcat, nous choisissons comme Framework de mappage de base de données, Torque. Vers la fin de développement, l’initiateur et quasi-unique contributeur, Martin Poelch, décède dans un accident, avec pour conséquence l’arrêt du développement de Torque.

Deuxième conclusion


Quand on veut utiliser un outil Open Source « libre » bien s’assurer de sa pérennité aussi bien humaine, financière et contextuelle.
Question subsidiaire : Qu’adviendrait-il de Linux si Linus Torval disparaissait ?

Dernièrement, Oracle a mis la main sur MySQL puis Java, et d’un seul coup, les communautés prennent conscience que l’avenir de leurs produits n’est pas gravé dans le marbre et que de Open Source Libre et Gratuit, ceux peuvent devenir payant et plus libre du tout. De cela, nait la confusion pour les utilisateurs finaux que nous sommes. Entre les rachats et leur roadmap « changeante » et les projets dissidents qui éclosent à cause de cela, pas facile de s’y retrouver
.
Dernière conclusion

Une entreprise commerciale a une motivation : vendre ces produits, ce qui la rend prévisible, ce qui n’est pas toujours le cas des outils « open source libre et gratuit ». Bien sûr, des exceptions existent des deux côtés mais, en règle générale, quand Oracle rachète MySQL ou Sun, c’est dans un but précis. Inutile d’attendre sur le long terme d’autres stratégies que celle-ci

Je suis devenu un Microsoft Friendly, même si parfois, on peut aussi leurs reprocher de changer les roadmaps, d’abandonner des produits ou services, de ne pas avoir de visions claires.
Il n’empêche que je connais leur motivation première : le profit, et cela les rends vraiment plus prévisibles.///

Un article qui illustre assez bien mon billet

mercredi 17 mars 2010

2.0 ou pas

Le premier écueil que je rencontre lors de réunion d’utilisateurs d’un de mes softs « 1.0 », est de leur  expliquer la différence entre deux concepts qui me semblais évident : la convergence entre « Mon équipe/mes utilisateur » et les « tiers ».
Naïvement, je pensais que le concept 2.0 de réseau social et ce qui différencie mon « équipe » des autres, c’est que justement ils appartiennent à la même « équipe » au même groupe était une évidence.
Devant moi, l’assemblé fronce les sourcils : « ben* non, les utilisateurs c’est nous, les autres se sont les… autres » (* terme très usité dans ma région). Je n’arrive pas à expliquer le concept de réseau (ou Network pour faire geek), je demande : « qui utilise FaceBook ? », « ben, oui, mes gosses l’utilisent ». Et oui, tous le monde n’utilise pas FaceBook, tous le monde n’est pas geek.
Première leçon, dans un milieu utilisant massivement l’outil informatique, ne pas croire que les gens sont très au fait des dernières tendances et que des concepts, qui nous semblent basiques, peuvent ne pas être compris.
A suivre.///

jeudi 11 mars 2010

Devenir plus sociale

Après avoir vu la présentation de Marc Benioff, CEO de Salesforce.com, J’ai pris conscience que notre monde du logiciel était à un moment charnière.

Après avoir longtemps écrit des logiciels repliés sur eux-mêmes, sur leurs microcosmes, je devais revoir ma façon de penser, d’architecturer. Je dois devenir « 2.0 ».

C’est ce cheminement que je vais tenter d’écrire au travers de ces billets d’humeur.

jeudi 4 mars 2010

Coming Soon

Un article en préparation