Keolis Lille - IB Cegos

Concevoir un site ou une application pour mobile et tablette

Formation IB Cegos pour Keolis Lille

Franck

Plan (1er jour) : « dév. digital »

  1. Du dév. « traditionnel » au dév. Web/mobile : caractérisation, spécificités, enjeux économiques, technologiques et sociétaux associés
  2. Dév. Web/mobile : de quoi parle-t-on précisément ?
    • Le dév. Web/mobile comme service créateur de valeur ajoutée aux autres produits et services
    • Contexte technologique
    • Usages, du divertissement au business. : l'app. mobile/tablette dans le cœur de l'entreprise
    • Chiffrage de l'app. mobile/tablette
    • Dév. Web/mobile et agilité : caractérisation, position et attentes possibles de la MOA pour le pilotage du prestataire fonctionnant en mode agile
  3. Environnement technico-économique du dév. Web/mobile
    • Web et/ou mobile
    • Spécificité de la tablette
    • Acteurs, marché, chiffres clés, tendances
    • Côté serveur
    • Bonnes pratiques
IB

Plan (2e jour et 3e jour) : dév. mobile et tablette sous l'angle technologique

  1. Typologie des applications et leur mode de conception (natif, etc.), compatibilité/interopérabilité des approches et solutions
  2. Look&feel (ergonomie)
    • Quel look&feel ?
    • Gestion fine des écrans
    • Material Design
  3. Test
  4. Liste des démonstrations prévues
IB

Dév. digital, késako

La pénétration du numérique dans notre environnnement quotidien (objets « connectés ») a pour ossature Internet non seulement comme une plateforme de communication (son objet originel) mais également comme une plateforme de calcul. La problématique de dév. de logiciel est renouvelée : les applications collaborent par l'assemblage de services hautement distribués, mobiles, voire volatiles. Les relations aux objets connectés s'intensifient par la vue, l'ouïe, le toucher… relations instrumentées par les applications (réalité virtuelle, réalité augmentée…).

Le dév. mobile et tablette s'inscrit dans ce mouvement par le simple fait que smartphone et tablette sont des objets connectés totalement banalisés. L'Internet-des-Objets est la généralisation de ce principe par la présence d'électronique et de logiciel embarqués dans les objets du quotidien : ascenseurs, machines à laver, TVs, lunettes, voitures, cycles… Ces objets sont des nœuds de communication et de calcul sur l'Internet.

IB

Le numérique comme valeur ajoutée aux produits et services

« In the beginning, businesses considered software as a way to automate processes, contributing to productivity by speeding up what was already being done. But over time, software became recognized not just as an automation tool but more broadly as a strategy for providing products and services not yet offered. » (gras ajouté)

Un développement de cette idée… IB

Exemple

IB

Autre exemple

IB

Une évolution à la fois sociétale et technologique (1/2)

L'idée même de Personal Computer qui a vu l'ordinateur entrer dans les foyers a migré vers le smartphone (« téléphone intelligent » littéralement). Au-delà de la fonctionnalité « téléphoner », le smartphone est bien un Personal Computer. La tablette est un produit intermédiaire entre l'ordinateur de bureau et le smartphone offrant un degré médian de puissance (taille écran…) et de mobilité.
IB

Une évolution à la fois sociétale et technologique (2/2)

Les acteurs économiques ont compris que la conception des OSs (Operating Systems) devait impérativement être pensée sur la base du « plus petit » device, i.e., le smartphone. L'ordinateur de bureau s'équipe alors du même OS avec des services techniques étendus (capacité d'être « serveur » par exemple). Toutefois, cet écart s'atténue avec l'avènement de l'Internet-des-Objets (ex. serveur Web Node.js embarqué dans System-on-Chip). IB

App. mobile et tablette : une mutation de -1- à -2-

  1. Initialement, app. « grand public » pour le divertissement ainsi que, par exemple, le marketing, le commercial ou encore la publicité.
  2. Plus récemment, app. qui s'articule avec le Système d'Information (SI). Intégration de l'application dans les business processes  (i.e., « processus internes »)  pour la rationalisation et l'amélioration des flux d'information ; la maîtrise d'ouvrage (MOA) devient la DSI (Direction Système d'Information).

Bémol : l'intégrabilité et donc l'intégration (jusqu'à un certain niveau de criticité en particulier : app. = maillon des chaînes de traitement) reste toutefois un problème épineux.

IB

Cas particulier de Keolis Lille

IB

Usages

IB

Durabilité

La durabilité est un élément essentiel de réflexion en conception d'app. mobile/tablette. D'une durée de vie de quelques jours pour une application marketing, une app. mobile/tablette rouage du SI va sûrement durer quelques années avec les contraintes de maintenance associées.
Cette gestion de la durée de la vie est extrêmement perturbée par deux facteurs (« moindres » en dév. traditionnel) :

  1. L'évolution technologique non seulement rapide mais violente (e.g., iOS9 ⇝ iOS10* : App Transport Security)
  2. L'évolution des habitudes : old fashion ⇒ rubbish

*Le cas évoqué est l'abandon d'HTTP à l'unique profit d'HTTPS. La mentalité des fans Apple fait que les bascules s'opèrent sous 10 jours en moyenne. l'App Store refuse alors des applications n'allant qu'à iOS9 pour forcer les fournisseurs à achalander rapidement le catalogue iOS10.

IB

Durabilité, quelques chiffres

Remarque : l'écart-type est toutefois considérable !

IB

App. mobile et tablette : exemple métier (« gestion des déchets »)

IB

Mobile Backend as a Service (MBaaS)

L'offre de dév. mobile et tablette se diversifie par la possibilité d'adosser l'app. à un existant métier comme un Enterprise Resource Planning (ERP) plus ou moins monolithique ou encore un middleware (e.g., serveur d'applications Java EE) par lequel les applications métier s'articulent et communiquent dans une logique Service-Oriented Architecture (SOA).
IBM, SAP, Oracle, RedHat, Microsoft (Azure App Service), Amazon et de manière plus générale tous les intégrateurs proposent à ce titre des offres liées ou non à leurs propres « plateformes mobiles ». Celles-ci sont dotées de composants sur étagère pour accéder aux services en backend.
Cela favorise évidemment des chaînes de traitement plus sécures, plus performantes (load balancing), plus directes (type, format, volume… des données véhiculées) si les maillons des chaînes proviennent du même fournisseur.

IB

App. mobile/tablette et SI

Une app. mobile/tablette est par définition désynchronisée dans le temps et dans l'espace avec le SI : c'est sa force pour créer de la valeur ajoutée là où l'informatique traditionnelle ne peut pas opérer. Toutefois, elle ingère, digère et produit des données dans un cycle propre qu'il faut articuler avec les chaînes de traitement du SI. On estime à 6 mois les sauts fonctionnels d'app. mobile/tablette « métier » pour 18 mois pour le SI. Les sauts technologiques pour une app. mobile/tablette « classique » sont eux à 3 mois ! Le cycle d'une app. mobile/tablette peut donc être la source de nouvelles données « intraitables » par le SI sinon passer par des adaptations significatives de celui-ci irréalistes en termes de coût et/ou de maintenance évolutive dans des temps « courts ».

Leçon : pas de branchement direct dans les chaînes de traitement du SI à cause des cycles de vie non naturellement compatibles. Il y a donc un vrai savoir-faire en termes de conception d'app. mobile/tablette qui émerge à l'aune de cette remarque : développer mobile/tablette est loin d'être qu'un problème technique.

IB

Release

Un dév. mobile se doit d'être caler sur des projets courts grâce à leur portée fonctionnelle limitée. En d'autres termes, un projet de plus d'un an est problématique en soi.

Note : cas « gestion des déchets » préalablement évoqué, 500 jours facturés : 100 cadrage, 400 dév.

IB

Chiffrage

Un dév. mobile est-il plus cher qu'un dév. « traditionnel » ? Le point de vue d'un PDG de société informatique experte dans le dév. mobile : « oui c'est plus cher ». Le dév. est à prix équivalent mais le cadrage est plus cher… cahier des charges initial (profilage utilisateurs, étude d'impact des changements, pratiques, adoptions…) puis cahier des charges et spéc. (écrans et arborescences, règles par écran (e.g., formats des données), use cases…) puis cahier des charges et spéc. détaillées (scénarios des use cases, architecture dont interopération (entrées et sorties) avec le SI, contrats d'interface avec le SI) sur base go ➰ no go à chaque étape. Approchons toutefois les choses plus pragmatiquement, chiffrons
Plus généralement, des facteurs d'accroissement des coûts (« vraie » app. !) sont plus marquants que d'autres :

IB

Agilité, grand principe

En d'autres termes :

  1. Croire que les besoins peuvent être pré-établis est un leurre…
  2. Le donneur d'ordre (MOA) peut donc a priori faire fluctuer les besoins mais en assume l'impact, notamment quant à d'éventuelles déstabilisations du processus de développement et de ses outputs.
  3. L'agilité est une sorte de non-méthodologie au regard des méthodes telles que Rational Unified Process (RUP). Toutefois, comme la nature a horreur du vide, des « méthodes » agiles comme Scrum se sont imposées… En Scrum, le Product Owner (MOA typiquement) est membre à part entière de « l'équipe de dév. ».
  4. Dév. hautement collaboratif (e.g., daily meeting de 15 min.) et décentralisé (Scrum Master = coordinateur plutôt que chef de projet), rétrospections, mesures (Burn Down Chart)…
IB

Le dév. en mode agile, késako ?

IB

Le dév. en mode agile, éléments techniques

IB

Le dév. en mode agile et dév. mobile

IB

Vision technico-économique

IB

Développement Web côté client

Le développement d'un site Web côté client consiste, pour faire simple, à utiliser de concert le trio HTML (contenu) - CSS (look&feel) - JavaScript (interaction).

L'adaptation du site à une tablette et un smartphone est l'approche la plus naturelle et immédiate. L'utilisateur interagit avec le site via le browser (navigateur), e.g., Safari, Opera, Internet Explorer, Firefox, Chrome ou Microsoft Edge pour les plus connus et utilisés.

Il n'y a plus à proprement parler de différence (en termes de programme) entre un browser sur un ordinateur de bureau et celui offert en standard sur une tablette et un smartphone. Par exemple, Chrome sous Android (comparé au produit « bureau ») perd peu de fonctionnalités mais l'essentiel est là : requestAnimationFrame, WebSockets, Web Workers ou d'autres !

IB

Site Web responsive

L'idée même de responsiveness est la faculté pour un site Web de s'adapter aux contraintes posées par une tablette et un smartphone. L'agencement des composants graphiques (widgets) à l'écran est caricatural de ce problème.

C'est une démarche à moindre coût car il existe des frameworks dédiés pour mener à bien et gérer cette adaptation. Bootstrap créé par Twitter est l'archétype de support technologique pour le responsive.

Toutefois, les résultats peuvent être décevants pour des utilisateurs souvent exigeants et habitués à des ergonomies données. C'est la notion de User Experience qu'il est souvent essentiel de préserver : un utilisateur d'iPhone veut du look&feel iPhone (c'est le critère différenciant à l'impulsion de l'achat !). Evidemment, certains frameworks tentent de s'approcher voire d'imiter un look&feel, une User ExperienceMaterial-UI ou Material Design Lite par exemple, proposent la conception en mode hybride pour coller à l'approche Material Design de Google préconisé en mode natif sous Android.

IB

Exemple de site Web
responsive

IB

Mise en pratique du responsive

C'est pour l'essentiel à l'aide de la méta-balise viewport que l'on gère l'adaptation du contenu affiché à la taille du dispositif d'affichage, la définition de l'écran en particulier :

<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">

La largeur d'affichage est adaptée au dispositif comme suit : width=device-width. Cette configuration engendre alors le fait qu'il n'est pas nécessaire de zoomer « plus » (pincement de doigts s'écartant) car le contenu exploite toute la place offerte par le dispositif. En l'occurrence, initial-scale=1 signifie que l'échelle d'affichage est à 100%. Tout zoom d'agrandissement est donc vain… Mieux, on peut bloquer l'agrandissement maximum-scale=1, voire le rapetissement minimum-scale=1.

IB

Site Web mobile-friendly

A contrario, le site Web peut être prioritairement designé pour une tablette et un smartphone. A ce titre, il peut aussi poser des problèmes d'adaptation inverse (de la tablette et du smartphone vers l'ordinateur de bureau). Des frameworks comme jQuery Mobile qui prétendent AUSSI répondre aux ordinateurs de bureau ont des schémas ergonomiques fortement basés sur les touch events des écrans tactiles. Il est alors difficile par exemple de mimer du multi-touch sur un ordinateur de bureau classique.

On peut tester ici le rendu d'un site Web sur mobile :

IB

Multi-touch et site Web

Le World Wide Web Consortium (W3C) qui régente la partie Web d'Internet propose une approche du multi-touch sur un site Web standard.

Multi-touch et site Web IB

Spécificité de la tablette, vision économique

Le marché des tablettes est en fort tassement comparé à celui du smartphone. Plus de données ici

IB

Spécificité de la tablette, vision technique

Un site Web mobile-friendly reste ergonomique avec une tablette mais laisse entrevoir des améliorations possibles en termes d'esthétique (grossissement parfois malheureux des widgets). Techniquement parlant, la tablette offre un système multi-frame/multi-pane plus puissant qu'un smartphone.

L'archétype est l'app. destinée à un touriste dont la version smartphone peut vite s'avérer rédhibitoire à utiliser :

Remarque : il est hasardeux voire suicidaire de développer deux bases de code différentes pour la « même » app. sous tablette et smartphone.

IB

Du site Web à l'app. dans le store

L'app., malgré le principe de son paiement éventuel, téléchargement et installation est devenue un réflexe, réflexe d'autant plus marqué que la génération d'utilisateurs de la tablette et du smartphone est jeune.

Comme le prouve ce petit benchmark (prêter attention à la première question posée !), l'app. est avant tout… un problème d'argent. A moindres frais, il est donc tentant de se limiter au site Web.

L'app. n'est donc jamais qu'une application métier (un logiciel) capable d'exploiter les équipements particuliers du device sur lequel elle tourne. Le principe d'adaptation est organique à l'app. compte tenu de l'éclectisme plus ou moins avéré des devices ciblés (équipements, OSs…).

IB

Site Web ou app. ?

Encore plus d'arguments pour l'un ou l'autre… IB

Contexte de l'offre mobile

IB

Plateformes (par ordre de leadership)

  1. Google Android (86% - 2016)
  2. Apple iOS (12% - 2016)
  3. Microsoft Windows Phone (2% - 2016)
  4. Les (très) mal en point : BlackBerry OS, Firefox OS
  5. Les tentatives d'entrée : Fire OS (Amazon) sur base Google Android, LuneOS sur base Open webOS (LG), Tizen (Samsung)…

Le problème est le degré de polyvalence de l'OS imposé par les autres cibles que les smartphones et tablettes (TVs, autos et Internet-des-Objets en général).

IB

Les prévisions de Gartner et IDC vers 2011/2012 pour fin 2015

  1. Google Android (46%)
  2. Microsoft Windows Phone (20%)
  3. Apple iOS (17%)
  4. BlackBerry OS (12%)

Commentaire : ça laisse rêveur !

IB

Répartition du marché

Source : IDC

IB

L'orientation technologique

L'orientation technologique est au plus haut point stratégique : quelles technologies (plateforme, langage de programmation) retenir pour ses besoins mais aussi ses spécificités, ses ambitions ?

L'offre technologique est instable et volatile. Suivre les « gros » est confortable mais ces derniers « cassent » la possibilité de pousser nos produits/services chez le voisin. Les « petits » rivalisent d'innovation en nous promettant le Graal (cross-platform, native…) mais nous font courir le risque d'investir à perte (arrêt de la technologie et/ou de son support) à moins que le gros mange le petit ?

IB

Répartition du marché Android

Source : Google

IB

Côté serveur

Comme tout logiciel Web, une app. se nourrit de données extérieures. Au-delà, Internet est une plateforme de calcul. Une app. se distingue en particulier d'une autre par sa propension à externaliser tout un ensemble de calculs qui vus de l'intérieur sont des services. Pour cela, la technologie Web Services est une technologie normalisée incluant l'approche RESTful (REpresentational State Transfer, plus de 70% des services dispo.) mieux adaptée. Le principe stateless de RESTful se marie en effet assez bien avec une connectivité plus aléatoire sur mobile et tablette.

L'archétype de Web service est le recours à un service d'authentification offert « gratuitement » 😇 par un réseau social tel que Google+, LinkedIn ou encore Facebook. Google Places est un autre ensemble de services bien connu, pour la géolocalisation quant à lui.

Au-delà de services banalisés comme l'authentification, l'accès à des services plus métier (au sein de business processes) suppose une infrastructure backend idoine. C'est là qu'interviennent les grands intégrateurs capables de mettre en place le principe de MBaaS avec nombre de considérations importantes dont la sécurité, la résilience, le passage à l'échelle, etc.

IB

Services « métier » : « tout-venant »

  1. Exemple : conversion de devises
  2. Exemple : géolocalisation
  3. Exemple : qualité de l'air
  4. Et des millions d'autres !
IB

Les services « propriétaire » ou « maison », valeur ajoutée qui peut faire la différence…

IB

Un premier bilan…

L'écosystème mobile et tablette dans la perspective de concevoir un site ou une app. est à la fois dynamique et foisonnant mais sujet à fluctuations voire instabilités. S'engager dans d'un dév. mobile en interne ou via une prestation extérieure est donc une odyssée dont on n'est jamais sûr de sortir indemne.

Cette première journée a exposé cet écosystème dans son ensemble avant d'aborder vers une vision technologique qui présente, analyse et évalue les éléments et spécificités techniques du dév. mobile comme les outils, les interfaces utilisateur, les langages de programmation, le test, etc.

IB

Les bonnes pratiques, éléments stratégiques

Les bonnes pratiques d'un dév. mobile. De quelle manière le donneur d'ordre s'engage dans ces bonnes pratiques avec son prestataire.

IB

Les bonnes pratiques, éléments techniques

Les bonnes pratiques d'un dév. mobile. De quelle manière le donneur d'ordre s'engage dans ces bonnes pratiques avec son prestataire.

IB

Vision technologique

IB

L'outil de développement

Côté « informaticien », l'outil de développement est évidemment l'élément critique qui va permettre de concevoir l'app.

IB

Outils de développement (liste non exhaustive)

  1. Android Studio (natif Android - Java, voire C/C++)
  2. Xcode (natif iOS - Objective-C, Swift)
  3. Visual Studio (natif Windows Phone - C# ou Apache Cordova - JavaScript)
  4. Intel XDK (Apache Cordova - JavaScript)
  5. Adobe PhoneGap (Apache Cordova - JavaScript)
  6. NetBeans (Apache Cordova - JavaScript avec éventuellement Oracle JET - JavaScript comme sur-ensemble)
  7. Eclipse (natif Android - Java ou Apache Cordova - JavaScript)
  8. Xamarin (cross-platform - C#, voir aussi 3.)

Remarque : les poids lourds préfèrent offrir leur propre environnement de développement pour mieux contrôler « les développeurs » en les guidant parfois vers des approches « plus propriétaires ».

IB

Approches un peu spéciales…

IB

Typologie
générale

IB

Cordova, ou « natif » versus « hybride »

Cordova a vocation de « casser » les monopoles des chaînes de dév. imposées par iOS et Android. Sans entrer dans les détails techniques (voir plus loin), Cordova s'appuie sur le support Web qu'iOS et Android sont obligés d'offrir. Fondamentalement, Cordova s'appuie sur le langage de programmation JavaScript dont l'interpréteur est nativement présent dans les plateformes iOS et Android.

La diffusion de Cordova est à ce jour immense. Son statut de de facto standard pour l'« hybride » est indiscuté. Cordova est supporté et poussé par les plus grands (Microsoft, Intel, Adobe…). Malgré cet état de fait, le risque d'une intégration bancale des app. Cordova dans les plateformes à l'exécution reste : problème de performance, problème de rupture de User Experience, etc.

Comme vu dans l'offre d'outils de dév., certains offrent le native-like mais ce créneau reste à ce jour obscur par le faible retour d'expérience des outils associés. A suivre…

Dans le reste de ce tutoriel, pour simplifier, Cordova = « hybride ».

IB

Natif (Android, iOS, Windows Phone) : POUR !

Développer de façon native garantit la conformité de l'app. aux automatismes de présentation et d'interaction (socle de la User Experience) acquis et cultivés par la communauté des utilisateurs.

Bémol à ce « POUR » : en hybride, nombreux sont les frameworks capables d'imiter les automatismes de présentation et d'interaction : Ionic Material

IB

Natif (Android, iOS, Windows Phone) : POUR !

Développer de façon native permet a priori de passer simplement le barrage du store. A ce jour, l'App Store est connu pour ses règles pointilleuses alors que Google Play est plus laxiste (jusqu'à quand ?).

Bémol à ce « POUR » : certains outils de développement promouvant l'hybride (e.g., Intel XDK offrent un support pour la publication automatique depuis l'outil de développement).

IB

Natif (Android, iOS, Windows Phone) : POUR !

Développer de façon native peut être motivé par la qualité d'un composant et de son API (Application Programming Interface) associée, ex. de la reconnaissance de parole.

Bémol à ce « POUR » : le plugin Cordova SpeechRecognitionPlugin est parfaitement aligné sur le standard Web Speech API Specification du W3C.

IB

Natif (Android, iOS, Windows Phone) : POUR !

L'écosystème des applications installées sur un device permet, au lieu d'écrire du code natif pour accéder par exemple à un service d'identification sur FaceBook, Twitter, Google+ ou autre, de sous-traiter le job à l'application idoine.

Bémol à ce « POUR » : le plugin Cordova SocialSharing fait cela !

IB

Natif (Android, iOS, Windows Phone) : POUR et CONTRE !

Evidemment, la portabilité « par construction » est le critère poussant à éviter un développement natif. Ainsi, la spécificité d'un code iOS pénalise de facto son portage vers Android et vice-versa. Deux nuances toutefois :

Commentaire : la traduction est un problème technique qui peut devenir épineux dû entre autres au portage des librairies tiers, à la gestion des versions, à l'imitation du look&feel, de la User Experience

IB

Natif (Android, iOS, Windows Phone) : CONTRE !

Le développement natif tire toujours vers du « non-standard » pour gêner la concurrence dans la reproduction des technologies, services et produits offerts. L'arrivée du langage de programmation Swift en 2014 pour iOS est caricatural ; c'est en partie une tentative de déstabilisation de la concurrence dans l'imitation des technologies, services et produits Apple.
Dans un autre style, le Web fait l'objet d'une standardisation via le W3C parfois mal « suivie ». A titre illustratif, une API WebSockets native sous Android peine à voir le jour. Toutefois, le nombre de librairies tiers s'attachant à cela est élevé :

IB

Hybride (HTML5 + CSS + JavaScript) : POUR !

Il y a des arguments manifestes et immédiats :

IB

Hybride (HTML5 + CSS + JavaScript) : CONTRE !

Il y a des arguments manifestes et immédiats :

IB

Caractérisation technique du mode hybride

Le principe (et plus généralement l'astuce) consiste à utiliser l'API native d'Android (WebView) ou d'iOS (WKWebView) qui permet d'intégrer une page Web dans une app. On parle aussi et alors de in-app browser c'est-à-dire de navigateur embarqué (et piloté) par l'app.

Android et iOS offrent évidemment sur leur plateforme l'interpréteur JavaScript (V8, respectivement Nitro) de leur navigateur (Chrome, respectivement Safari).

Cordova est la technologie leader de l'hybride par le fait qu'elle est le cœur de l'offre d'Intel, Adobe, Microsoft et beaucoup d'autres grands. Fondamentalement, Cordova cache les API natives par un accès basé sur le trio HTML5 - CSS3 - JavaScript.

Commentaire : il est important de garder à l'esprit que les technologies Web sur machines desktop, tablettes et smartphones doivent être les mêmes et non des variantes et/ou sous/sur-ensembles. C'est vrai et raisonnable de se reposer sur cette propriété « depuis peu ». Aujourd'hui, prenant le cas d'Apple par exemple, la visibilité sur les technologies Web intégrant les produits Apple est grande grâce à WebKit particulièrement.

IB

« L'hybride natif », il fallait l'inventer !

On peut aussi et opportunément se passer de Cordova en construisant massivement le fonctionnel de l'app. en mode Web puis intégrer l'ensemble dans le container chargé de le piloter en natif. Par exemple, avec iOS, Swift et WKWebView, on a :

class ViewController: /* hérite de -> */ UIViewController, /* implémente -> */ WKUIDelegate {
    var webView: WKWebView!
    …
    override func viewDidLoad() { // It is called after the controller's view is loaded into memory
        super.viewDidLoad()
        let mon_site_Web_en_local : URL! = URL(fileURLWithPath: "/Users/Franck/NetBeansProjects/Keolis_Cordova/www", isDirectory: true)
        let ma_page_unique : URL! = URL(fileURLWithPath: "index.html", relativeTo: mon_site_Web_en_local)
        let mon_app = URLRequest(url: ma_page_unique!)
        webView.load(mon_app)
    }
    …
}
IB

Cordova at a glance

Cordova est une plateforme ouverte de développement d'applications mobiles dont le cœur est sous contrôle de la fondation Apache, voir ici ou .
Dans les faits, Cordova s'appuie sur Node.js et s'installe au dessus de ce produit comme un package particulier. L'utilitaire npm (node package manager) de Node.js installe Cordova comme suit : npm install -g cordova.
Intel fournit ici une analyse rationnelle concise de ce qu'est et n'est pas une application Cordova. IB

Cordova en pratique

Peu sont ceux qui utilisent Cordova en ligne de commande dans sa version primitive (plateforme Apache). Au contraire, Cordova est masqué par les environnements de développement dont les plus fameux sont : IB

Cordova, cibles technologiques

En ligne de commande, la mise en œuvre de Cordova consiste à configurer différentes options dont les cibles technologiques : iOS, Android, etc. Par exemple, la commande cordova requirements (activée dans le répertoire de l'app.à construire) est une commande fort utile permettant de vérifier que les composants Android et iOS sont là et bien installés. Exemple de configuration d'une cible iOS (il n'y a pas nécessité d'avoir Xcode installé) :

cordova platform add ios --save
sudo npm install --global --unsafe-perm ios-deploy /* Eh oui, y fallait les droits super utilisateur ! */
cordova platform ls
cordova requirements
IB

Cordova, principe du plugin

Simplement, la difficulté avec Cordova est de « remonter » les capabilités offertes par les smartphones. D'abord physiques/électroniques, elles s'incarnent dans le système d'exploitation puis l'API native via des classes et leurs fonctions/méthodes. Il faut donc que l'API Cordova/JavaScript offre au développeur ce qu'il aurait trouvé nativement dans l'API Java pour Android, Swift pour iOS ou encore C# pour Windows Phone.

Par exemple, cordova-plugin-device est le plugin qui détermine les caractéristiques techniques du smartphone comme la version du système d'exploitation par exemple, version que le programmeur peut vouloir gérer dans son app.

Installation du plugin en ligne de commande : cordova plugin add cordova-plugin-device.

Programmation :
function l_objet_device_est_disponible_et_accessible() {
    var systeme_d_exploitation = device.platform;
};
document.addEventListener("deviceready", l_objet_device_est_disponible_et_accessible, false);
IB

Illustration

IB

Installation de librairie tiers via Bower (Intel XDK)

IB

Réutilisation de librairie tiers via Bower

<link rel="stylesheet" type="text/css"
href="bower_components/sweetalert/dist/sweetalert.css">
<script src="bower_components/sweetalert/dist/sweetalert.min.js">
</script>
IB

Cordova et Android ⇝ Crosswalk

A l'origine, Crosswalk est un container amélioré de WebView d'Android car ce dernier avait une mauvaise réputation. Intel par exemple préconise et supporte nativement Crosswalk. IB

Exemple d'accès à Google Maps avec Cordova

IB

Best practices Cordova

https://cordova.apache.org/docs/en/latest/guide/next/index.html

Multiitouch

Donner ici l'API des touch event 3D touch plus loin ?

Développement hybride et sécurité

https://www.raymondcamden.com/2015/05/25/important-information-about-cordova-5/

Vision implémentation

IB

Programmation

IB

Langages

Il est clair que le langage de programmation joue un rôle central côté conception. La culture de l'équipe de développement (goûts, préférences, savoir-faire…) en termes de langage de dév. (et plus généralement d'outils) est difficilement contournable. En d'autres termes, dans une approche « prestataire », il est plus que hasardeux voire impossible d'imposer une obligation de moyens, le langage et l'environnement de dév. en l'occurrence. Ou alors, l'alternative est de changer de prestataire !

Sans être exhaustif, la bataille se situe autour de trois leaders, un(des) outsider(s) certain(s) et des je-fais-ce-que-je-peux-pour-ce-que-j'ai-à-faire :

Langage Nature Diffusion Librairies tiers (Web/mobile/tablette)
Java Typé Très haute (compétences, expertise… ⇝ maintenance) Bon
Swift (Objective-C) Typé iOS uniquement pour l'instant Correct
JavaScript Non typé mais correctifs possibles Très haute Très bon
C# Typé Haute Médiocre
Python (e.g., Kivy) Non typé mais mieux que JavaScript Haute Bon
Autres dont langages « propriétaire » N/A Basse Mauvais

Style de programmation

La programmation mobile et tablette est plus exigeante que la programmation d'applications sur machines desktop ou serveurs. A minima, le développeur doit être excellent en programmation objet (e.g., Java : annotations, lambda expressions). Au-delà, il doit être compétent et formé quant aux exigences suivantes :

Application Frameworks

La programmation mobile et tablette a ses propres « canvenas d'applications ». Par exemple, Android Studio propose des templates qui donnent les grandes classes d'app. L'uniformisation de la User Experience est à la fois un avantage et un inconvénient d'une telle démarche.

Un canevas d'application particulier est le cas Single-Page Application (SPA). où les composants graphiques sont chargées dynamiquement, échangés, cachés, etc.

IB

Design Patterns

Les librairies coeur d'une plateforme ont leurs propres « patrons de conception » (archétypes) pour cadrer et favoriser la réutilisation. Par exemple, la plateforme Android supporte le patron XXX. IB

Archétype de gestion
de la batterie sous
Android (spécification)

IB

Archétype de gestion de la batterie sous Android (branchement à notification)

class EventSniffer extends android.content.BroadcastReceiver {
    @Override
    public void onReceive(android.content.Context arg0, android.content.Intent arg1) {
        if (arg1 != null && arg1.getAction() != null) {
            android.content.Intent intent = new android.content.Intent(arg0, Android_energy_management_example.class);
            intent.setAction(arg1.getAction());
            arg0.startService(intent);
        }
    }
}
IB

Archétype de gestion de la batterie sous Android (réaction à notification)

public class Android_energy_management_example extends android.app.Service {
    EventSniffer _event_sniffer;
    AbstractStatechart _Nominal_Energy_Level;
    AbstractStatechart _Critical_Energy_Level;
    … // Other states here…
    AbstractStatechart_monitor _Android_energy_management_example_state_machine;
    …
    public void start() throws Statechart_exception {
        _Android_example_state_machine.fires(android.content.Intent.ACTION_BATTERY_LOW, _Nominal_Energy_Level, _Critical_Energy_Level);
        _Android_example_state_machine.fires(android.content.Intent.ACTION_POWER_CONNECTED, _Critical_Energy_Level, _Critical_Energy_Level);
        …
IB

Qualités

Qualités perçues par l'utilisateur

  1. Facilité d'utilisation
  2. Fiabilité dont résilience
  3. Performance dont scalability (aptitude au passage à l'échelle)
  4. Sécurité…

Qualités économiques

  1. Réutilisabilité
  2. Maintenabilité
  3. Autres qualités : compatibilité et respect des normes et standards, propriété intellectuelle, etc.

Qualité du code

L'analyse statique de code (voir aussi la notion de « test structurel » ci-après) a vocation à signaler, et le cas échéant corriger, des lacunes voire des failles (cf. « Qualité du code (« failles ») ») dans le code écrit. Cela va de l'identification de mauvais nommages (lisibilité et donc maintenanbilité ⤵) à celle de code déprécié ou encore celle d'organisations de code objet non optimales (réutilisabilité ⤵ ⇝ refactoring). Les environnements de dév. fournissent souvent cela en standard mais on peut mettre en place ses propres règles grâce à des outils comme JavaParser par exemple. IB

Inspection de
code (Android
Studio
)

IB

Qualité du code (« failles »)

L'analyse de code après la possibilité d'accroître réutilisabilité et maintenabilité, peut s'attacher à d'autres facteurs de qualité comme la fiabilité, la performance ou encore la sécurité. Par exemple, un objet utilisé sans être passé par une initialisation ou affectation a une forte chance d'être source de bogue. Dans beaucoup de cas, on peut détecter une telle faille sans passer par une exécution. A titre d'illustration, Android Studio s'appuie sur l'outil Lint pour procéder à des analyses fines de la qualité du code, exemple :

// Récupération 
    
        _Android_example_state_machine.fires(android.content.Intent.ACTION_POWER_CONNECTED, _Critical_Energy_Level, _Critical_Energy_Level);
        …
IB

Obfuscation de code

L'obfuscation de code permet, outre la protection de la propriété intellectuelle, le compactage du source (JavaScript) ou du bytecode (Java) autorisant des gains parfois significatifs en vitesse d'exécution, encombrement mémoire, etc.

A titre d'illustration, Android Studio s'appuie sur l'outil ProGuard pour traiter ce sujet alors que le monde JavaScript offre pléthore d'outils d'obfuscation… et donc de désobfuscation, exemple d'obfuscateur JavaScript ici.

Reprenant le code JavaScript de la page X, voici une forme d'obfuscation :

eval(function(p,a,c,k,e,r){e=String;if(!''.replace(/^/,String)){while(c--)r[c]=k[c]||c;k=[function(e){return r[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p}('1 0(){2 3=4.5};6.7("8",0,9);',10,10,'l_objet_device_est_disponible_et_accessible|function|var|a|device|platform|document|addEventListener|deviceready|false'.split('|'),0,{}))
IB

Exemple de code Java Android

void
...
IB

Look&feel (ergonomie)

IB

La
préhistoire

IB

A
minima

IB

Vers le
kitsch ?

IB

Look&feel, les best practices selon Android

Source : Google

IB

Density-Independent Pixel (DIP, DP ou encore DPS) selon Android

Android a mis au point une unité de mesure de la définition graphique des écrans « indépendante » de la définition physique. Ce système de mesure est fortement conseillé aux développeurs pour adapter leurs IHMs aux variétés d'écran ( guide Android sur Density-Independent Pixel). Exemple :

IB

Pixellisation et iOS

Il n'y a de différence notoire entre Android et iOS pour la gestion de la pixellisation sachant que le facteur de densité est liée à la technologie des écrans équipant les appareils : 1x (non-retina), 2x (retina) et 3x (iPhone 6 Plus par exemple). Voir ici, ou encore .
Comme pour Android, la question du travail artistique (icônes, images notamment mais aussi qualité du son…) équipant les applications peut demander des ajustements dans le cas où l'on souhaite conserver une certaine esthétique. Evidemment, cela peut-être un facteur de coût non négligeable.
Un autre point est de se demander si plusieurs releases sont envisagées en fonction des caractéristiques des appareils notamment (gestion plus complexe = coût accru encore). Dans le cas contraire, privilégiant toujours une meilleure esthétique, le programmeur doit charger les bonnes ressources (variants d'icônes, d'images…) en fonction des caractéristiques des appareils qu'il peut quoi qu'il en soit déterminer programmatiquement.

IB

De la vue au toucher…

Sans exclusion and sans généralisation possible, on peut caractériser smartphones et tablettes par leurs écrans tactiles qui vont fortement guidés l'interaction de l'utilisateur. En programmation, cette interaction est discrétisée comme un flux d'événements qui sont typés et achalandés d'information. Le style de programmation est dit événementiel ou réactif par le fait que le programmeur abonne son app. aux événements transmis de l'appareil à l'OS puis de l'OS à l'app. Il écrit du code (des fonctions) qui est appelé « en retour » (idée de callback).

IB

3D touch

Les possibilités d'interaction sont un différentiel concurrentiel de l'offre même si ce différentiel ne dure jamais longtemps
Dans cet esprit, le 3D touch d'Apple (iPhone 6S et + ou iPad Pro - iOS ≥ 9) ouvre de nouvelles perspectives d'interaction. Plugins Cordova https://github.com/xonoxitron/cordova-plugin-forcetouch https://github.com/EddyVerbruggen/cordova-plugin-3dtouch https://github.com/nickplesha/ng-cordova-3dtouch

IB

Material Design

Ensemble de principes et règles ergonomiques pour, de manière générale, favoriser la facilité d'utilisation (User Experience). Approche métaphorique qui capitalise les acquis, les tropismes, les intuitions, les désires…

IB

Material Design : ressources

Material Design structure un marché de la création artistique, des icônes en passant par les polices, les sons, les fonds… jusqu'aux thèmes complets.

IB

Material Design : exemple d'archétype ergonomique (spécification)

Un Navigation drawer est un écran proposant un menu contextualisé à un sujet. A des fins d'illustration, on considère une personne qui a un nom, un email et une photo d'identité mais on peut ajouter d'autres attributs comme un son distinctif ou toute autre ressource multimédia.

Material Design est donc avant tout une spécification ergonomique dont les contraintes (si elles sont respectées) font rentrer dans le moule Pure Android. Par exemple, l'élévation au repos (au sens 3D) d'un Navigation drawer est de 16 DIP.

Pour garantir la navigation au sens large, un Navigation drawer ne doit pas rentrer en conflit avec les principes de navigation communs et transverses aux app. qui forgent la User Experience. La programmation du Back button notamment cher à Android, est ici, comme partout souvent, critique.

IB

Material Design : exemple d'archétype ergonomique (implémentation)

La programmation d'un Navigation drawer est d'autant plus inutile que son format et son comportement sont totalement standardisés. La question est donc comment cet archétype est outillé et au-delà personnalisable de l'API jusqu'à l'environnement de dév., Android Studio typiquement ?

Entre, initialement, des implémentations « maison » comme celle-ci et des standardisations comme celle disponible depuis peu dans Android Studio, on doit s'interroger sur le niveau de réutilisation souhaité et la facilité d'utilisation induite du fait de partir de zéro ou à l'inverse se caler dans le cadre strict fourni par l'environnement de dév.

IB

Material Design :
exemple
d'archétype
ergonomique
(outillage via
template)

IB

Material Design :
Navigation drawer
« maison » (1/3)

IB

Material Design :
Navigation drawer
« maison » (2/3)

IB

Material Design :
Navigation drawer
« maison » (3/3)

IB

Material Design : exemple d'archétype ergonomique (code)

reprendre le code Navigation Drawer fragment
IB

Test

IB

Test, vocabulaire

Le test systématique sur appareils « réels » par l'effort qu'il suppose (au-delà du coût de possession des appareils) est souvent sous-traité. Au-delà du test purement technique du développeur, le test utilisateur a une place prépondérante dans le développement mobile via par exemple le crowd testing. L'environnement de gestion des tests et de leurs résultats à mettre en place (base de données de tests) est critique en vue de piloter l'évolution (évolution des besoins ou réparation des bogues) de l'app. à construire.

Types de test :

Selon la qualité envisagée et/ou la criticité de l'app. à livrer, chaque phase peut correspondre de 1 à 30 passes.

IB

Test, vision (en 2010) d'un expert de la « validation logicielle » chez les constructeurs de téléphones

« Il n'y a pas grande différence avec un developpeur de site Web qui doit vérifier que son site fonctionne sous IE7, 8 ou 9, Opera 10 ou Firefox 3 ou 4, avec Windows XP, 7 ou sous MacOS et Linux dans des résolutions d'écran variées et sur un netbook. Le monde du mobile se rapproche énormément du monde PC. La partie hardware et même la connection au réseau sont très loins vis à vis des applications. L'aspect informatique "temps réel" ou "embarqué" est complètement masqué pour ces applis. Toutes les interactions de ces applis avec les périphériques se font via les API blindées de l'OS. Les constructeurs ont pour mission de blinder ces APIs et n'ont probablement pas beaucoup de temps à passer sur la validation des applications proprement dites, mais je peux me tromper. »

IB

Test, émulation

L'émulation d'appareil consiste, à partir d'une image virtuelle du hardware, à « mimer » le comportement de l'app. dans cet environnement identique aux conditions réelles, i.e., électroniques. Toutefois, les équipements physiques du smartphone (e.g., réglage du volume, appareil(s) photo, puce BlueTooth, puce GSM…) doivent être « incarnés » par l'émulateur (exemple avec Android). Par exemple, on imite un SMS entrant géré par la puce GSM mais l'émulation n'est pas par définition l'appareil physique en fonctionnement avec la puce associée. La simulation elle est une version appauvrie de l'émulation au sens où le hardware est abstrait.

L'émulation a beaucoup de limites dont la principale est la lenteur. Le bon sens montre que le test technique du développeur gagne à s'opérer directement sur un smartphone dédié à cette activité. Malheureusement, l'OS peut être plus ou moins bien mal supporté par l'appareil (e.g., Huawei) rendant les tests pas complètement généralisables.

La clef semble donc l'aptitude à séparer un ensemble de tests assez indépendants de l'appareil (le test structurel est par définition attaché à cet ensemble) d'un ensemble plus spécifique. Par exemple, la 3D suppose des capacités spéciales de l'appareil dont le test appartient au second ensemble.

IB

Test, émulation et virtualisation

Android Studio par exemple s'appuie sur la technologie de virtualisation d'Intel et son outil Hardware Accelerated Execution Manager (HAXM). Simplement, l'ordinateur du développeur a un processeur de la famille X alors que le set d'instructions d'Android s'appuie sur la famille de processeurs Y. Y est virtualisé dans X ce qui doit accélérer l'émulation. En l'absence de virtualisation, la traduction des instructions à l'exécution (hardware « abstrait ») pendant le test est pénalisante en temps. IB

Test, banc de test

Un banc de test est une infrastructure de test proche des conditions réelles de fonctionnement et d'utilisation. L'idée de s'équiper de tous les appareils du moment plus les anciens si l'on veut que son app. ait une couverture large et une utilisabilité jamais démentie, est souvent vite freinée par des contraintes budgétaires. L'appel à des sociétés offrant par leur métier ces bancs de test est souvent incontournable :

IB

Test et dév. hybride

Le fait d'asseoir une app. sur HTML5, CSS3 et JavaScript a des avantages discriminants : IB

Test
basé
cloud
(Intel
XDK
)

IB

Test, quelques éléments techniques

Une forte expertise de programmation par objets avec des notions de programmation par contrats, des principes de forte cohésion/faible couplage et d'autres mécanismes fournissent des logiciels (plus) fiables par construction et test-enabled pour les failles résiduelles. Même JavaScript par nature permissif peut être écrit de façon disciplinée jusqu'à des possibilités de vérification avancées (e.g., TypeScript).

En test, le concept d'oracle peut être instrumenté via des contrats qui décorent le code mais qui ont pour finalité de disparaître dans la version de production. Ces oracles/contrats ont de grandes vertus pour le test unitaire et d'intégration surtout.

IB

Test et dév. hybride : exemple de la librairie chai.js

Time_management.prototype._create_3D_object = function (name) {
// Pre-condition:
    chai.assert.isTrue(typeof name !== 'undefined' && name !== null && typeof name === 'string' && name !== '');
// Invariant:
    chai.assert.isTrue(this._image !== undefined && this._image !== null && this._image instanceof Image && this._image.complete, 'Contract violation: \'this._image\'');
…
// Versus defensive programming:
    if (!(this._image !== undefined && this._image !== null && this._image instanceof Image && this._image.complete))
        throw('Contract violation: \'this._image\'');
…
            
IB

Test et dév. hybride : exemple d'outillage

IB

Test et dév. natif (Android) : exemple de la librairie JUnit

IB

All nicely aligned to grid

IB

La fin… Merci de votre confiance et attention.

IB

Bibliographie

  1. Cross-Platform Development Tools for Smartphone Applications (2012)
  2. Yet Another DSL for Cross-platforms Mobile Development (2013)
IB

© Franck Barbier