tirer parti des périphériques mobiles dans une application web : qui a dit qu’il fallait coder...

Post on 24-May-2015

2.298 Views

Category:

Technology

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

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.

TRANSCRIPT

TIRER PARTI DES PÉRIPHÉRI-QUES MOBILES DANS UNE

APPLICATION WEBQui a dit qu’il fallait coder plusieurs versions natives ?

Christophe Porteneuve @ Paris Web 2010

LE WEB MOBILEEn passe de foutre sa claque au web desktop…

Les applis natives ?Pas besoin pour…

• L&F similaire 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)

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

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

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 ?

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

Un mot sur CSS Media Queries

• 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+ avechttp://code.google.com/p/css3-mediaqueries-js

// 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) { …}

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…

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…

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

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

95% web : les outils

• Les mêmes que pour le 100% web…

• …plus les SDK natifs ou leur enrobage « unifié » (voir approche suivante)

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

Applis natives baséesHTML+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

Hybrides : les outils

• Phonegap

• Titanium Mobile

• Unify

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.

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.

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…)

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 !

…mais patience !

• build.phonegap.com

• En ligne, gratuit

• Tu files 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…)

Hybrides : pour/contre

• Avantages

• Si on 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

• Il faut quand même installer/configurer tous les SDK et outils associés…

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.

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 !)

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).

En résumé…

100%web

95%web

Hybride 100% natif

Dév. browsers browsers + EDI/outils

browsers + EDI/outils

EDI

Tests browsers browsers + sim./périph.

browsers + sim./périph.

sim./périph.

Multi-PF universel assez facile assez facile duplication d’effort

Distrib. pas besoin ! App Stores(mais pas souvent)

App Stores App Stores

Il est plus que temps !

• La consultation 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 !

@porteneuve

tdd@tddsworld.com

@gitattitude

http://slideshare.net/tdd

Merci.

top related