• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Tirer parti des périphériques mobiles dans une application web : qui a dit qu’il fallait coder plusieurs versions natives ?

on

  • 2,582 views

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

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.

Statistics

Views

Total Views
2,582
Views on SlideShare
2,582
Embed Views
0

Actions

Likes
0
Downloads
31
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Tirer parti des périphériques mobiles dans une application web : qui a dit qu’il fallait coder plusieurs versions natives ? Tirer parti des périphériques mobiles dans une application web : qui a dit qu’il fallait coder plusieurs versions natives ? Presentation Transcript

    • 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
    • LE WEB MOBILE En passe de foutre sa claque au web desktop…
    • 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)
    • 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 // 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
    • 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… • …plusles 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é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
    • 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 • 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…)
    • 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…
    • 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% 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)
    • 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 !
    • Merci. @porteneuve @gitattitude tdd@tddsworld.com http://slideshare.net/tdd