# Mais tout d’abord : Que-ce que Sencha Touch ?
Sencha Touch est un framework Javascript basé sur JQTouch et ExtJS, utilisant massivement HTML5 et CSS3. Il permet de créer des interfaces pour tout navigateur utilisant comme moteur de rendu WebKit et pour une utilisation au doigt. Ce framework offre une gestion des données très puissante contrairement à certains de ses concurrents comme jQueryMobile. En contrepartie, le framework est lourd : la librairie pèse plus de 300ko, et le code complexe à exécuter. Les principes de fonctionnement ainsi que les noms des éléments sont très similaires à la libraire ExtJS4.
dont un exemple assez complet : http://dev.sencha.com/deploy/touch/examples/kitchensink/
Intéressons-nous aux contraintes de développement des applications sur un plan ergonomique. Suivant le type de terminal (smartphone, tablette…), deux éléments de saisie restent très disparates au sein du marché : la présence ou non d’un clavier physique, et l’écran. Mais désormais tous les smartphones récents s’utilisent au doigt. Exit le stylet, mais on pourra le regretter sur quelques points tout de même. Contrairement à celui-ci, un doigt, c’est gros et peu précis. Mais cela apporte un avantage indéniable : cela rend l’interface plus naturelle à utiliser, si tant est qu’elle soit bien conçue.
Afin de manipuler les interfaces tactiles, on peut identifier des “gestures”, c’est à dire les interactions possibles avec l’écran qui ressortent de manière événementielle. Voici les principales :
Sencha Touch permet d’identifier ces gestures et de les intercepter sur les éléments d’interface. A noter que certains peuvent être rattrapés au niveau du navigateur et non dans l’interface elle-même. C’est le cas du Pinch rattrapé sur certains smartphone Android gérant le multi-page, le Spread servant à zoomer ou encore le Hold permettant de faire des actions spécifiques sur certains éléments, tel le copier/coller. Voici un exemple de panel sous Sencha Touch rattrapant des événements :http://dev.sencha.com/deploy/touch/examples/kitchensink/ -> Touch Events.Afin de parfaire l’expérience utilisateur il convient d’adapter l’interface à l’utilisation aux doigts, et il y a certains principes plus ou moins évidents à respecter :S’il est généralement aisé de comprendre l’action que va faire un bouton avec du texte ou une image, ça l’est beaucoup moins lorsqu’il s’agit d’un objet quelconque où il n’y a aucune indication dessus et où il faut faire une action particulière. Par exemple un flick (ou swipe) vers un côté pour switcher l’écran en cours de visualisation, ou lorsqu’il faut faire un double tap pour actionner quelque chose, ou encore faire un drag d’une barre pour développer un panel. Leur découverte arrive plus souvent par le fruit du hasard que naturellement. Il faut donc faire comprendre à l’utilisateur ces choses, via l’utilisation d’indicateurs, ou via la mise en scène de l’information. Par exemple, pour comprendre qu’il est possible de scroller une courte liste d’éléments, l’ajout de dégradés foncés en haut et en bas de cette liste afin de simuler une roue de choix (comme un cadenas à code) fait comprendre à l’utilisateur qu’il s’agit de quelque chose qui tourne.
Sencha Touch propose une multitude d’éléments qui prennent en compte ces nécessités d’affichage. Ces éléments s’inspirent beaucoup du design iOS.
L’espace d’affichage étant généralement restreint, il convient d’afficher uniquement les informations essentielles à l’écran. Mais si elles ne peuvent l’être, il faut faire en sorte qu’elles soient accessibles rapidement et facilement. Pour se faire, dans la plupart des cas un simple scroll suffira, mais suivant la situation il n’est pas forcément judicieux d’opter pour cette solution. Si le contenu à scroller est long et désorganisé, la recherche d’une information de cette manière peut devenir calamiteuse. Il peut donc être préférable de privilégier une succession de petits écrans permettant de découper par étape l’accès à une information donnée. De plus, cela peut éviter de devoir compresser, réduire ou même tronquer les informations vues à l’écran.
Dans le même genre de problématique, l’utilisation simultanée d’un scroll vertical et horizontal, en plus de n’être pas forcément intuitive, rendra la lecture d’une page beaucoup plus fastidieuse.
La meilleure solution est donc de faire en sorte que l’interface soit calée dans la largeur ou la hauteur de l’écran afin de n’avoir qu’un seul scroll. Mais pour que cela soit possible, il faut savoir répondre à la problématique de la résolution d’écran ainsi que celle du changement d’orientation.
Voyons les contraintes liées à la résolution d’écran et les autres contraintes techniques que l’ont peut rencontrer sur les terminaux mobiles. Suivant le modèle de smartphone ou de tablette, plusieurs éléments peuvent varier :
- la taille de l’écran
- la résolution de l’écran
- les performances du mobile
- les accélérations matérielles de certaines fonctions js/css dans le navigateur
C’est pour cela que Sencha Touch et jQueryMobile permettent de faire abstraction de ces résolutions. En effet, toutes leurs css sont écrites en taille relatives (contrairement à ExtJS). Du fait, pour un bouton par exemple, celui-ci aura (presque) exactement la même taille sur un écran de Wildfire, ou sur un écran d’iPhone 4. C’est donc un énorme avantage offert par ces frameworks, car en écrivant seulement quelques lignes de code, on obtient quelque chose de visible (et donc utilisable) sur la majorité des terminaux. Sencha va même pousser la chose encore plus loin, en proposant un Cloud permettant l’envoi d’image correctement adaptée à la résolution d’écran. Pour plus d’infos concernant ce Cloud : http://www.sencha.com/blog/previewing-sencha-io/
Mais il ne faudra pas oublier de prendre en compte la taille de l’écran tout de même. Un bouton prenant 90% de la largeur de l’écran sera peut être sur-dimensionné sur une tablette comme l’iPad, alors qu’il aura une taille normale sur un Wildfire… Suivant les cas, il sera peut être judicieux de réorganiser la page suivant la largeur de l’écran détectée.On peut voir aussi une autre problématique liée : celle de l’orientation de l’affichage, généralement modifiable à la volée suivant la position du smartphone au moment de la lecture. Sencha Touch propose des fonctions et événements de détection de l’orientation de l’écran, et les composants sont conçus pour pouvoir se redimensionner à la volée.
Au delà de la problématique liée aux écrans, il y a celles liées aux performances du mobile.
Les bonnes pratiques voudraient que la page soit la plus épurée possible, aussi bien au niveau des styles qu’au niveau du contenu. Il incombe donc au développeur d’éviter de créer beaucoup d’objets en même temps, et en supprimant du DOM les objets plus utilisés. Cependant, Sencha Touch ne permet pas vraiment de respecter cela, et malgré toutes les optimisations possibles, les performances peuvent être désastreuses. Cela est du en partie à la simulation du scroll. Sencha Touch génère une div prenant la taille de l’écran et génère lui même les scrolls des éléments à l’intérieur de cette div. Ce scroll est en fait une fonction CSS3 (translate3d) qui marche bien sous les terminaux Apple (car accélérée matériellement), mais très moyennement sous les terminaux Android.
De plus, l’initialisation de Sencha Touch est relativement lente. Ainsi, à chaque chargement de page, une page blanche restera affichée durant une ou quelques secondes, et ce même sur un téléphone haut de gamme. Afin d’éviter ce temps de chargement à chaque fois, il est nécessaire de concevoir l’application de telle manière que chaque enchaînement de page s’effectue uniquement en local (en JS) et non via un rechargement complet de la page, pour ne pas détériorer l’expérience utilisateur. L’utilisation en masse de l’Ajax est donc une nécessité. Mais cela a des conséquences directes : l’éloignement du fonctionnement une ressource = une url (REST) pour le coté client, ainsi que l’impossibilité d’utiliser la touche retour navigateur. ExtJS4 intègre un Ext.util.History permettant de gérer cela, mais il n’existe pas dans Sencha Touch.
Voyons maintenant les contraintes liées à l’OS et/ou navigateur.
Comme évoqué, les navigateurs proposent des solutions natives afin de rendre l’expérience utilisateur la meilleure possible. Parmi elles, le zoom dans les pages, le copier/coller, ou encore les claviers virtuels adaptés au type de l’input html : affichage d’unclavier numérique dans le cas d’un champs de type « number », clavier alphabétique avec une touche ‘@’ supplémentaire pour un champs de type mail, etc… Sencha Touch propose des éléments de saisie utilisant ces types.
Mais certains élément du navigateur peuvent devenir des contraintes, telle la barre d’adresse. Celle-ci a tendance à disparaître lorsque la page est chargée, mais le hasard (ou pas) fait que par moment celle-ci reste affichée en permanence… Avec Sencha Touch, lorsque cette barre se retire quelques temps après le chargement de la page, la page ne se redimensionne pas forcément bien, et lors d’un scroll vers le bas il se peut que ça soit le navigateur qui récupère l’événement et descende la page complète avec la barre d’adresse, au lieu que ça soit l’élément Sencha Touch de la page qui le récupère et scroll sont contenu….
Il y a aussi l’élément de sélection de texte qui parfois s’affiche sur des éléments venant d’être caché…
Attardons-nous sur un point essentiel des navigateurs : leurs connectivités.
Les terminaux mobiles étant par définition mobile, leurs connexions à internet est très aléatoire. En haut débit, bas débit, ou pas du tout connecté, les interfaces mobiles devraient pouvoir s’adapter à tout type de situation. C’est une chose désormais techniquement possible, notamment grâce à HTML5. Il offre la possibilité de stocker des données en local, grâce à une base SQLite intégrée (ou IndexedDb). Cependant, d’après le W3C, la taille de cette base ne peut excéder 5mo mais elle doit pouvoir être étendue après autorisation d’utilisateur.
Sencha Touch permet d’utiliser cette base de manière transparente pour l’utilisateur, puisqu’il propose une source de données spécifique pour les « stores » de données. Voir Ext.data.LocalStorageProxy dans la documentation :http://dev.sencha.com/deploy/touch/docs/
HTML5 offre aussi la possibilité de gérer de manière avancée le cache navigateur, grâce au Cache Manifest. Le Cache Manifest est un fichier texte permettant de dire quels fichiers doivent être stockés en cache navigateur, et quels fichiers ne doivent pas l’être, et permet accessoirement aussi de faire des switchs de fichiers si la connexion est présente ou non.
Grâce à cela, il est possible d’optimiser le chargement du site (et soulager le serveur), puisqu’on peut faire en sorte que les librairies JS ainsi que le code de l’application soient tirés du cache, tout en gardant la possibilité de lancer des requêtes Ajax afin de mettre à jour les données.
Cependant, ce cache peut poser problème : cela reste à travailler et à confirmer, mais le navigateur met en cache toute l’interface de la page, et garde une copie de ce cache en l’associant à l’url de la page.
Exemple : On met en place le cache sur la page d’accueil d’un site. Lorsqu’on va sur ce site sans être logué, celui-ci affiche non pas la page d’accueil mais le formulaire de login, tout en gardant l’url de la page d’accueil. Lors de la première connexion, le navigateur mettra en cache cette page, contenant donc ce formulaire de login. Lors de la validation du formulaire, une redirection est faite vers la page d’accueil (donc la même url, mais le contenu aura donc changé). Mais c’est là que le problème se pose : le cache associant le formulaire de login à l’url de la page d’accueil, c’est donc celui-ci qui sera affiché, et le vrai contenu de la page d’accueil ne le sera pas.
Attention, cette partie reste donc à étudier et à vérifier.
Pour plus d’infos : http://blog.xebia.fr/2010/12/02/application-hors-ligne-avec-html5-le-manifest/
et : http://www.html5-css3.fr/html5/tutoriel-application-web-offline-html5-cache-manifest
Outre ces outils, il conviendra de gérer convenablement les retours de requêtes Ajax impossibles, timeout et autres, de manière à ne pas perturber l’interface, le problème typique étant l’erreur JS qui bloque complètement la page… A noter aussi que les navigateurs fournissent une fonction relative à la connectivité, pour savoir si la connexion à internet est présente ou non.
# Le mot de la fin
On vient de voir les principales contraintes des développements web mobile. Comme détaillé tout au long de cet article, Sencha Touch répond à la majorité de ces problématiques. Mais les principaux défauts de Sencha Touch sont sa lourdeur d’exécution et le fait qu’il soit incompatible avec certains navigateurs, dont le navigateur web de Windows phone 7. Mais malgré cela, Sencha Touch est une référence pour le moment en terme de framework d’interface web pour navigateur WebKit. Ses capacités techniques, son design, sa communauté et surtout les technologies qu’il utilise, font de lui un excellent framework. Cependant, pour une application ayant des interfaces plus légères ne qui ne nécessitent pas une gestion de données poussée, il conviendra peut-être de se tourner vers jQueryMobile, qui lui, est compatible avec le navigateur web de Windows phone 7.
26 mai 2011 at 13 h 26 min
merci pour cet article riche des informations. j’ai juste une question pour ce qui la gestion de données avec JQuery et Sencha. j’ai pas bien compris ce point.
26 mai 2011 at 14 h 11 min
Bonjour ALi, merci pour votre commentaire.
Pour vous répondre rapidement, la gestion des données avec JQueryMobile devra se faire « à la main » directement en HTML et Javascript, ou via l’aide de quelques fonctions telles que celle-ci : http://api.jquery.com/jQuery.data/. A noter qu’il existe probablement des plugins qui permettent une gestion plus poussée des données.
La gestion des données avec Sencha Touch -et ExtJS en général- est beaucoup plus poussée, grâce notamment à l’utilisation de « Record ». C’est un objet représentant un tuple de donnée et ayant des fonctions de base d’édition : « getter/setter », « commit/rollback ». Depuis ExtJS 4/Sencha Touch, le fonctionnement se rapproche du schema MVC et ces records sont renommés « Model » et des fonctions viennent s’ajouter comme le « load », le « save » ou encore le « destroy ». Sur ce « Record », il suffit de brancher une source de donnée (un « Proxy ») qui ira par exemple charger les données en Ajax, ou qui aura tout simplement ses données chargée « en dur », ou qui pourra encore chercher depuis la base de donnée locale (HTML5).
Ces records peuvent être dans des « Store », qui sont tout simplement des conteneurs. Cependant, eux aussi peuvent avoir une source de donnée, et c’est même obligatoire pour ExtJs <= 3.*, car c'est eux qui vont pouvoir s'occuper de charger/enregistrer/supprimer les records.
Enfin, ces "Store" peuvent se brancher n'importe où : sur des "ComboBox", des "Grid", ou encore des "DataView" qui sont en fait des objets permettant simplement de mettre en forme les données (sous forme de tableau, ou autre, via des "Template"/"XTemplate").
Je vous invite à aller jeter un oeil sur un article du blog Sencha détaillant le fonctionnement de ces objets depuis ExtJS4 et Sencha Touch :
Ainsi que la documentation afin d’obtenir des détails de fonctionnement sur les objets dont je viens de parler :