Le web mobile est en train d’exploser, d’autant que les principaux périphériques proposent désormais de « vrais » navigateurs, de l’iPhone à Androïd, de Mimo à PalmOS, et même les nouveaux Blackberry. S’il est déjà bien d’exploiter des feuilles de style mobiles pour adapter l’expérience utilisateur, on souhaite souvent accéder aux capacités du périphérique (géolocalisation, vibreur, accéléromètre…) et offrir une expérience globale aussi « native » que possible. Il n’est pas pour autant nécessaire de développer des versions natives distinctes ! Des frameworks existent pour un déploiement universel, et cerise sur le gâteau : ça se passe en JavaScript ! Cet atelier vous fera faire un tour d’horizon des principaux frameworks actifs, exemples et démonstrations à l’appui.

1. TIRER PARTI DES PÉRIPHÉRI-
QUES MOBILES DANS UNE
APPLICATION WEB
Qui a dit qu’il fallait coder plusieurs versions natives ?
Christophe Porteneuve @ Paris Web 2010

2. LE WEB MOBILE
En passe de foutre sa claque au web desktop…

3. Les applis natives ?
Pas besoin pour…
• L&Fsimilaire au natif (CSS + JS, les gars ! Et iUI, Jo, Sencha
Touch…)
• Géolocalisation (fournie par le navigateur)
• Sons (HTML5 <audio> pawa)
• Stockage
persistent côté client (localStorage, Web Storage,
Web SQL Database, Lawnchair, PersistJS…)
• Notifications « push » avec l’appli ouverte (Web Sockets)

4. En revanche, besoin des applis
natives pour…
• Contacts
• Envoi de SMS/MMS
• Enregistrement de son/vidéo
• Photos (prise, modification et accès bibliothèque)
• Accéléromètre / Magnétomètre / Vibreur…
• Notifications « push » avec l’appli fermée
• D’une manière générale, les capacités du périphérique

5. 4 Approches
• Appli 100% web
• Appli « 95% web »
• Appli native basée HTML+CSS+JS : « hybride »
• Appli native basée SDK plate-forme : 100% native

6. Applis 100% web
• HTML permet la structure qu’on veut
• CSS permet l’aspect qu’on veut
• JS permet le comportement qu’on veut
• On a la géolocalisation
• On a le son
• Pourquoi changer ?

7. 100% web : les outils
• HTML5, CSS3 (dont Transforms, Animations, Transitions), JS
• CSS Media Queries
• XUI, ZeptoJS
• Jo, Wink, Sencha Touch
• Web Storage, Web SQL Database, Lawnchair, PersistJS
• Web Sockets, Socket.IO

8. Un mot sur CSS Media Queries
// http://www.w3.org/TR/css3-mediaqueries/
// La CSS entière :
<link rel="stylesheet" type="text/css" href="…"
media="screen and (min-device-width: 800px)" />
// Fragment dans une CSS :
@media screen and (min-device-width: 800px) {
…
}
• Une vraie démo concrète qu’elle est bien
• En natif sur Saf3+, FF3.5+, Chrome, Opera 7+, IE9+
• Utilisable
sur Saf2+, FF, Chrome, Opera 7+, IE5+ avec
http://code.google.com/p/css3-mediaqueries-js

9. Web mobile : souvenez-vous…
• JS va moins vite (voire beaucoup moins vite !)
• La bande passante est plus petite
• Le cache est très sélectif (limites de taille, etc.)
Y’a pas de mouseover / mouseout / :hover
• Mais on a (en général) HTML5, CSS3, DOM2, SVG…

10. Frameworks JS pour le mobile
• On oublie Prototype, jQuery, Dojo, YUI, MooTools, ExtJS…
• XUI
• ZeptoJS
• iUI
• Jo, Wink, Sencha Touch
• Et en complément, Lawnchair, PersistJS, Socket.IO…

11. 100% web : pour/contre
• Avantages
• Que des choses qu’on aime déjà
• Développement dans ton navigateur !
• Pas d’App Stores, de validations, de déploiement…
• Inconvénients
• Pas d’accès à la majorité des capacités des périphériques

12. Applis « 95% web »
• Lorsque
les technos web suffisent à l’aspect, mais que le
comportement requiert 1+ fonctions du périphérique
• Cas les plus fréquents :
• Notifications « push »
• Vibreur
• Accéléromètre

13. 95% web : les outils
• Les mêmes que pour le 100% web…
• …plusles SDK natifs ou leur enrobage « unifié » (voir
approche suivante)

14. 95% web : pour/contre
• Avantages
• Presque tous ceux du 100% web
• Accès à toutes les capacités des périphériques
• Inconvénients
• App Stores, soumission + acceptation, déploiement, etc.
• Il faut se farcir les différentes plates-formes ciblées

15. Applis natives basées
HTML+CSS+JS : « hybrides »
• Le périphérique est censé faire partie intégrante de
l’expérience utilisateur qu’on recherche
• Mais côté UI, les technos web suffisent toujours à nos besoins.
• Besoins typiques :
• Manipulation d’images (prise de photo, accès albums…)
• Prise de son (chat audio, identification de musique…)
• Accès au carnet d’adresses

16. Hybrides : les outils
• Phonegap
• Titanium Mobile
• Unify

17. Phonegap
• API JavaScript unifiée, accessible direct dans tes pages
• Fournit un accès aux capacités locales du périphérique
• Camera / Contact / Device / Network / Notification / …
• iPhone, Android, webOS, Symbian, Blackberry, WP7 (bientôt)
• Fait par Nitobi. Open-source. Sur Github.

18. Titanium Mobile
• API JavaScript unifiée, mais pas dans les pages directement…
• Fournit un accès aux capacités locales du périphérique
• Camera / Contact / Device / Network / Notification / …
• iPhone, Android
• Fait par Appcelerator. Mix OSS/commercial.

19. Unify
• En gros, Phonegap + qooxdoo + SASS
• Maintenu par Deutsche Telekom.
• Open-source depuis JSConf.eu 2010. Sur Github.
• http://unify.github.com/unify/ (pas bien référencé encore…)

20. Un mot sur les SDK…
• Mais comme c’est trop super chiant !
• Le simulateur Android met 3 plombes à démarrer
• Le SDK Blackberry ne tourne que sur Windows (?!)
• Le SDK webOS nécessite une VM VirtualBox (bon…)
• Et puis simulateur ≠ périphérique !

21. …mais patience !
• build.phonegap.com
• En ligne, gratuit
• Tufiles ton www/, ils te sortent ton appli packagée pour
chaque plate-forme prise en charge !
• Sortie prévue fin novembre 2010
• apparat.io
• Même principe, sortie théorique octobre 2010 (ahem…)

22. Hybrides : pour/contre
• Avantages
• Sion se débrouille bien, on code son appli une seule fois, et
on la déploie sur l’ensemble des plates-formes prises en
charge !
• Inconvénients
• Ilfaut quand même installer/configurer tous les SDK et outils
associés…

23. Applis 100% natives
• On utilise le SDK natif de la plate-forme, son langage, son API
• On a accès à l’intégralité des API de la plate-forme, donc on
peut proposer une expérience aussi riche et « native » qu’on
le souhaite.

24. 100% natives : les outils
• Bin, les SDKs, quoi (tous gratuits) :
• iOS= Xcode (excellentes docs) + iPhone Developer
Program pour pouvoir déployer sur périph./store ($99/an)
• Android = Eclipse + Android SDK
• webOS = SDK/PDK (basé Java + JS)
• Symbian = Aptana + SDK
• Blackberry = Eclipse + SDK (mais que Windows !)

25. 100% natives : pour/contre
• Avantages
• On peut utiliser la totale des fonctions du SDK et du
périphérique
• On garantit (si on veut) un L&F natif
• Inconvénients
• On doit apprendre l’API (voire un langage), et parfois payer
pour avoir le droit de déployer (Apple/iOS, $99/an).

26. En résumé…
100% 95% 100%
Hybride
web web natif
browsers + browsers +
Dév. browsers EDI
EDI/outils EDI/outils
browsers + browsers +
Tests browsers sim./périph.
sim./périph. sim./périph.
duplication
Multi-PF universel assez facile assez facile
d’effort
Distrib. App Stores App Stores App Stores
pas besoin ! (mais pas souvent)

27. Il est plus que temps !
• Laconsultation web sur les mobiles / tablettes / etc. est en
train d’exploser celle sur desktop.
• Utiliser
intelligemment les capacités du périphériques permet
des passerelles sympa (réalité augmentée, media blogging, geo
blogging… jusqu’où s’arrêteront-ils ?)
• Toutes
les technos sont là, utilisables pour la grosse majorité
du marché des smartphones ! Allez-y, bordel !

28. Merci.
@porteneuve @gitattitude
tdd@tddsworld.com http://slideshare.net/tdd