Technologie web pour plate-forme mobile - Page 1

J'ai besoin d'avis et conseils à une question technique assez ouverte aux propositions, aussi plutôt la poser ici que sur le forum développement.

Pour ceux qui l'ignorent, je suis développeur web : PHP, mySQL, HTML/CSS/JS pour tout ce qui est de la racine (à quoi on ajoute du coup des frameworks divers en supplément). Tout cela pour situer mon niveau de compétence, cela fait bien longtemps que je n'ai plus touché aux langages logiciels.
Un nouveau client a défini des besoins pour un nouveau site web qui s'approche davantage de l'application mobile que de l'application web. Pour ses commerciaux en déplacement, il souhaite les équiper tous d'une tablette (à ce sujet, nous avons le libre choix du matériel qu'il commandera) sur lequel tournera une application qui pourra consulter les produits du catalogue de l'entreprise récupérés depuis le serveur de la société pour les visites chez les clients, concevoir des devis et des commandes. Jusqu'ici, rien de bien compliqué pour une appli web.
Cependant, certains détails viennent compliquer la tâche :
- Besoin d'un accès offline au catalogue en cas d'absence de connexion mobile.
- Utilisation de la caméra de l'appareil pour pouvoir prendre des photos de stocks pour d'éventuels devis.
- Possibilité éventuelle (plus dispensable) de scanner des codes barres pour obtenir une référence produit (au pire, code barre aidant, ils peuvent l'entrer à la main).
- Dans le genre "j'aime le moderne", possibilité de faire signer un devis/bon de commande au client sur l'écran de la tablette avec un stylet, comme le font certaines sociétés de livraison. Notre commercial a proposé (pas encore vendu, ouf) cela après avoir vu un captcha sur un site qui lui demandait de dessiner à la souris la forme qui apparaissait à l'écran.

Apparemment le client s'est déjà renseigné auprès d'un développement d'applications natives iOS/Android, j'ignore pourquoi cela ne s'est pas fait.
En attendant, j'ai commencé à me renseigner sur certaines technologies proposant de faire des applications dont le code web tourne sur ces machines, comme Apache Codova, Sencha... Il y a aussi des fonctions de HTML5 que je n'ai encore jamais eu à exploiter précédemment comme le WebSQL pour permettre la création/accès à une db locale (pour le mode déconnecté) ou encore WebRTC qui offre l'accès à la caméra pour prendre des photos ou vidéos encodées en base64.

Je ne suis pas encore arrêté sur la technologie à utiliser, j'en suis encore à étendre mon champ de recherche pour la création du devis client.

./1 > Tu t'es documenté sur ce qui se fait côté AngularJS, Durandal ou Backbone ?
Ce sont des frameworks qui vont te permettre de coder des applications web avec un minimum de code HTML et JS. (Perso j'ai pour l'instant une petite préférence pour Durandal qui utilise (via knockout) les attributs data-* standards du HTML5)

Sinon, de mon expérience perso, j'aurais tendance à fortement te déconseiller Ext.JS. (Je trouve que c'est une sombre blague, rapport à tout ce qui se fait ailleurs...)

Et pour le stockage, est-ce que l'API localStorage ne te suffirait pas ? (Sans SQL, donc)

J'ai aussi l'impression que ExtJS est en perte de vitesse, de façon générale. En tout cas, c'est super chiant à utiliser.

Au taf on lui préfère primefaces

Je pense que l'idéal serait une application native pour ce genre de chose, mais comme tu semble plus a l'aise avec les techno, web, je pense que c'est envisageable:

Meowcate (./1) :
- Besoin d'un accès offline au catalogue en cas d'absence de connexion mobile.

A priori c'est possible en utilisant les capacité de stockage offline de HTML5: https://developer.mozilla.org/en-US/docs/HTML/Using_the_application_cache

Meowcate (./1) :
- Utilisation de la caméra de l'appareil pour pouvoir prendre des photos de stocks pour d'éventuels devis. :

Sans aller jusqu'a WebRTC qui est encore assez expérimental, de ce que j'ai lu, il y a une API qui donne accès à l'appareil photo pour la plupart des navigateurs mobiles comme le navigateur intégré à Andoid(> 3.0), Chrome et Firefox : https://developer.mozilla.org/en-US/docs/Web/Guide/API/Camera

Meowcate (./1) :
- Possibilité éventuelle (plus dispensable) de scanner des codes barres pour obtenir une référence produit (au pire, code barre aidant, ils peuvent l'entrer à la main).

En théorie, si on peu prendre une photo on peut lire un code barre, mais c'est complexe a mettre en place. Il y a probablement des bibliothèque disponibles gratuitement qui font ça, pas contre je ne me suis jamais renseigné sur cela.

Meowcate (./1) :
- Dans le genre "j'aime le moderne", possibilité de faire signer un devis/bon de commande au client sur l'écran de la tablette avec un stylet, comme le font certaines sociétés de livraison. Notre commercial a proposé (pas encore vendu, ouf) cela après avoir vu un captcha sur un site qui lui demandait de dessiner à la souris la forme qui apparaissait à l'écran.

En théorie c'est aussi possible en pur web, en utilisant la Touch API disponible sur tous les navigateur mobiles (y compris iOS) : https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Touch_events
Il faudrait quand même équiper les tablettes de stylets capacitifs, vu que les tablettes ont toutes aujourd'hui des écrans capacitifs et que signer avec les doigts, ça fait pas super sérieux.

Meowcate (./1) :
Il y a aussi des fonctions de HTML5 que je n'ai encore jamais eu à exploiter précédemment comme le WebSQL pour permettre la création/accès à une db locale (pour le mode déconnecté)

De ce que j'ai compris, même s'il est encore supporté par webkit pour le moment, WebSQL est une expérience qui a été abandonné par le W3C au profit de la spécification de IndexedDB : https://developer.mozilla.org/en-US/docs/IndexedDB/Basic_Concepts_Behind_IndexedDB

(je retiens ce sujet : c'est très intéressant pour moi de suivre la démarche "demande client" -> "choix d'une plateforme" -> "choix d'une techno et d'un langage" -> "divers choix techniques". J'ai toujours été nul dans ce genre de choix)

(Faut dire qu'essayer de placer du M68K, c'est pas facile )

+1 pour examiner l'emploi de technos comme Underscore+Backbone et AngularJS, et pour l'UI, jQuery Mobile.

En code natif, Qt 5.2 gère officiellement Android et iOS (mais je n'ai jamais essaye), et Qt 5.3 sera censé gérer les apps Windows Store (même si la part de marché des technos Windows sur plate-formes mobiles est faible, et le restera si l'on en croit toutes les analyses). Il serait intéressant de savoir pourquoi le client a évalué et abandonné le code natif.

C'est vrai que j'aurais plutôt eu tendance à proposer du natif pour une appli comme ça (le code barre en JS je le sens pas trop ... Sur Android/iOs des librairies qui font tout le boulot en C++ existent déjà)

Mais sinon c'est peut être en effet l'occasion de s'intéresser à tout les frameworks JS qui commencent à émerger ^^

./6 Oui bah ne retiens pas trop vite, car au final on a choisi la simplicité.
Comme on choisit le parc des machines, ce seront des tablettes sous Windows 8. On aura ici des systèmes similaires aux ordis sur lesquels on peut faire tourner un serveur local qui se mettra quotidiennement à jour avec le serveur distant (ce qui n'est pas mal puisque celui-ci se met aussi à jour quotidiennement).
Les modèles Surface 2 Pro sont par ailleurs équipées de stylets dédiés.
HTML5 pour la capture de photos/vidéos, simplement l'imposition de choisir des tablettes qui ont une caméra à l'arrière.

Uther (./5) :
De ce que j'ai compris, même s'il est encore supporté par webkit pour le moment, WebSQL est une expérience qui a été abandonné par le W3C au profit de la spécification de IndexedDB

J'aurais préféré WebSQL pour connaître le SQL, mais effectivement ça aurait plutôt été IndexedDB, d'autant plus que Firefox a refusé de le supporter dans l'idée que le SQL est toujours difficilement standardisé (d'autant que WebSQL utilise SQLite, qui comme son nom l'indique est assez "Lite" sur les spécifications).

J'ai conscience sur ce choix de ne faire que contourner le problème et de ne pas exploiter ce que le web moderne propose, dans mon champ de compétences c'est ce qui sur le long terme serait le plus souple. L'ajout du serveur web local permettrait de plus la gestion des emails intégrés avec une implémentation d'un webmail type Roundcube au sein même de l'application et de ne pas avoir des recherches supplémentaires si de nouvelles demandes du client posent de nouvelles questions sur l'absence d'une connexion permanente.
Et accessoirement, l'un des soucis est que notre boîte enchaine les devis et les projets, ne laissant pas vraiment le temps à de la veille techno. C'était soit ça soit abandonner le devis pour en faire un autre plutôt que de voir ce qui se fait de nouveau.

Et comme j'ai dit, on a déjà conseillé au client un dev qu'on connaît pour du natif, on ne sait pas pourquoi il a refusé cette solution.

Meowcate (./10) :
Comme on choisit le parc des machines, ce seront des tablettes sous Windows 8. On aura ici des systèmes similaires aux ordis sur lesquels on peut faire tourner un serveur local qui se mettra quotidiennement à jour avec le serveur distant (ce qui n'est pas mal puisque celui-ci se met aussi à jour quotidiennement).

Faire tourner un serveur local sur une tablette me parais une solution plutôt violente au problème, même si je comprend bien que c'est le plus simple pour vous.

J'ai peur des conséquences à court terme, au niveau de l'autonomie par exemple, et a long terme, les modèles de tablettes avec architecture PC me semblant de moins en moins privilégiées par les constructeurs.

De mon point de vue ce n'est pas une tablette, mais un pc portable avec seulement l'écran. Asus a bien fait plusieurs modèles de bureau de ce genre. Pour les solutions que j'ai parcouru, le problème reste le temps nécessaire pour apprendre à utiliser ces technologies, et à terme de savoir si c'est l'idéal pour ce que l'on veut faire.

Mais je partage ton avis, j'ai présenté cette solution dans le genre "ou alors on fait ça, et on se base sur ce qu'on sait déjà faire". J'aimerai surtout trouver des avis ou solutions sur internet de gens déjà confrontés à ce problème, tout ce que j'obtiens c'est des "avec les nouvelles technologies, vous pouvez faire ça et ça". Les frameworks JS sont assez nombreux aujourd'hui et je n'ai pas le temps de tous les parcourir pour avoir celui qui me parait être une bonne solution. Et il faut ajouter que je suis dans une petite boite, on ne peut pas se permettre la solution-miracle-qui-fait-tout-et-même-plus pour la modique somme de gn-gn-gn euros par mois.

En revanche je ne pensais pas qu'un serveur local serait aussi énergivore, je n'ai jamais consulté cela avant. Entendons-nous bien, l'appareil n'est allumé que chez le client, il ne s'agit pas de maintenir un contact 24/7.

Je ne peux pas te garantir que ça sera très énergivore au point que ça le soit un problème pour le client. Si ça ne le dérange pas d'avoir des Surface Pro 2 qui sont en effet plus des portables sans clavier que des tablettes classiques telles qu'on les entend actuellement, ça devrait aller.
Je pense juste que, c'est une chose a prendre en considération si quand on parle tablette le client pense , iPad, Galaxy Tab, ...

Malgré tous les efforts marketing d'intel pour faire croire le contraire, les processeurs x86 même dédiés aux portables n'ont par des consommations comparables aux processeurs ARM. Et un serveur Web en tache de fond réduira probablement l'autonomie, cependant il ne m'est jamais venu à l'idée de faire ce genre de chose sur un portable, donc je n'ai pas vraiment idée de l'impact, ça serait quelque chose à mesurer.

Mais un serveur web en tâche de fond, il ne fait pas qu'attendre en écoutant des ports ?

Mais du coup je suppose que ça doit empêcher la mise en veille.

J'imagine que ce qu'Uther veut dire est qu'un système Windows 8 (et la tablette qui tourne avec dès lors) consomme plus qu'une tablette classique étudiée pour plus d'économie de ressources et d'énergie, serveur web ou pas.

Il faut savoir que sous Windows 8, tu n'as pas le droit de créer un serveur local (en mode desktop, donc) et d'y accéder depuis une application Windows "Modern UI", donc cette solution risque de requérir de n'utiliser que des applications en mode desktop, et donc un navigateur web en mode desktop, alors que ceux-ci ne soient pas vraiment adaptés à l'interface tactile…
Et la raison pour laquelle c'est interdit, c'est d'une part bien évidemment parce qu'un serveur qui tourne en arrière plan (même un serveur qui ne fait "rien"), ben c'est énergivore, et d'autre part parce que ça viole le principe de sandboxing imposé aux applications du Windows Store.
De fait, je ne sais pas si ça fonctionne sur Internet Explorer 11 (mode Modern UI) dans une configuration standard (i.e. pas un PC de développeur), et je vous suggère fortement de tester ça avant de vous lancer là dedans…

Cela étant dit, vous pourriez partir sur une appli Windows Store en mode Windows RT (AMD et pas x86 donc, ça fait d'ailleurs une réduction non négligeable sur le prix du matériel) et codée en HTML5 + JS. Dans ce cas, il n'y aurait pas besoin de serveur Web en arrière plan… (Mais cela implique de maîtriser quelques uns des API Windows RT pour JavaScript…)

(Et dans tous les cas, que vous fassiez une application "Web" en mode local avec frameworks JS, ou une appli Win RT avec framework JS Windows RT, c'est sensé réexploiter vos compétences de codage en HTML, JS et CSS, donc normalement, aucune des solutions possibles ne devrait vous poser de réels soucis une fois que vous avez la certitude que les scénarios qui vous intéressent sont supportés)

./14 > Ben attendre en écoutant les ports ça nécessite quand même de maintenir certains mécanismes actifs, mais effectivement, si c'est bien fait (faut que tu t'assures à 100% qu'il n'y ait absolument aucun thread qui fasse quelque chose pendant le temps où tu es sensé ne rien faire), ça ne consomme pas grand chose. Dans la pratique, c'est souvent mal fait.

GoldenCrystal (./17) :
c'est sensé réexploiter vos compétences de codage en HTML, JS et CSS

Mes connaissances en HTML et JS jusqu'à présent ont été limitées à un travail de frontend. En dehors de l'AJAX, ça ne m'a jamais servi que pour la présentation. J'ai encore du mal à concevoir tout ce que cette modernité peut me procurer pour concevoir une application de ce type déconnecté avec stockage local, trop fixé sur l'idée que tout traitement des données s'effectue du côté du serveur.
D'autant qu'avoir un graphiste/intégrateur dans l'équipe n'aide pas à approfondir ses connaissances quand il s'occupe généralement de tout cet aspect de la conception.

GoldenCrystal (./17) :
et donc un navigateur web en mode desktop, alors que ceux-ci ne soient pas vraiment adaptés à l'interface tactile

Il existe cependant des outils HTML et JS pour agir en tant qu'interface tactile, comme le glissement. Dans l'idée, le navigateur n'est qu'un afficheur, le placer en mode plein écran serait du pareil au même.

Bon, pour poser une nouvelle question d'avis, après quelques articles parcourus nous avons éliminé quelques frameworks JS et hésitons aujourd'hui encore Angular et Ember qui semblent au coude à coude sur plusieurs points. Y en a t-il qui sauraient donner des avis impartiaux, ou sinon défendre leur camp ?

Sans être indiscret, y'a moyen que tu liste les frameworks que vous avez éliminés et la/les raisons pour lesquelles vous les avez éliminés ?

Sinon perso, si je devais choisir entre les deux, je choisirais instinctivement AngularJS parce que du peu que j'en ai vu, il semble plus simple et plus propre que Ember.js, en plus d'avoir plus la côte et d'être développé chez Google. Après, ça demande quand-même une sérieuse analyse, et à moins de creuser dans la documentation, ça va être difficile de trouver une réponse simple.
(Honnêtement, quand j'avais regardé le fonctionnement de Ember, j'avais pas été trop séduit par le principe. En particulier, je suis pas fan de leur syntaxe pseudo-HTML barbare, même si ça a l'air puissant. Et dans l'ensemble, plus je creuse, plus j'ai l'impression que Durandal est mieux structuré que ces deux-là, donc pour mes développements perso, le choix se portera à priori là dessus ^^)

Sinon, AngularJS c'est Google, mais vu leur nature à abandonner les projets du jour au lendemain, il faut quand même s'en méfier. Malgré les moyens financiers derrière (Google oblige), AngularJS n'est à priori pas plus fiable sur le long terme qu'un framework développé ailleurs. C'est compensé par la popularité de leur framework, ce qui fait que si tu as une question, il y a de grandes chances que tu puisses trouver de l'aide dans la communauté. (Et ça mitige aussi la probabilité d'une disparition totale de support, contrairement à la concurrence… Mais on ne sait jamais de quoi demain sera fait.)

Concernant le support long terme, c'est pas un problème évident à cerner… Dans l'absolu, si le framework que tu choisis aujourd'hui marche pour toi aujourd'hui, alors il n'y a pas de gros souci. Par contre, tu prends le risque que ton code vieillisse un peu, et ne soit pas compatible avec les nouvelles technologies à la mode. Il n'est pas question d'un problème de HTML ici, mais plutôt d'évolution d'infrastructure côté JavaScript. L'arrivée de ECMAScript 6 (c'est déjà envisagé et prévu par les gars de chez AngularJS je crois) risque de bouleverser pas mal de choses par exemple… Surtout dans quelques années en fait. De fait, tu pourrais te retrouver coincé avec une vieille version de jQuery ou autre, et avoir plus de problèmes à faire évoluer le code, ou même à former les nouveaux. (La documentation des libs js, c'est une ressource plutôt éphémère)
Bref, c'est quelque chose à envisager aussi, même si ce n'est pas la peine de se prendre trop la tête dessus. (De toutes façons, soyons réalistes, si ton code atteint une durée de vie de 10 ans (5 pour le web ) sans modifications/réécritures, c'est déjà un petit exploit en soi… Ou une très mauvaise gestion, va savoir.)

Je me suis mal exprimé, en fait "d'éliminer", il serait mieux de dire "choisir".
J'ai fait une sélection des frameworks existants les plus populaires par quelques recherches sur internet et commencé une première sélection à obtenir des frameworks qui nous permettent vraiment de faire de nouvelles choses (jQuery entre dans la catégorie framework, mais on le connaît déjà et on veut aller plus loin que ce qu'il propose par exemple). On y retire des frameworks qui commencent à se faire vieux (comme tu l'as dit, il faut viser le long terme sur cet investissement, même si en techno web le "long terme" se compte en années, pas en décennies) et on obtient une première sélection :
Angular, Ember, Backbone, CanJS, Meteor, SproutCore

Comme j'en ai déjà parlé, ce n'est pas comme si on nous laissait le temps d'avoir de la formation technologique, et j'ai beau adorer coder, après une journée à faire ça j'aime bien passer à autre chose en rentrant chez moi. Faisons donc confiance à Le Internet (et des auteurs d'articles bien plus éclairés sur le JS que mon humble personne) pour me faire un tour de ce qui se fait le plus en ce moment. Il s'agit de compter sur un framework apprécié, aux nombreuses contributions, avec assez de docs sur Internet, d'exemples ou de questions sur StackOverflow (ce qui n'est pas forcément une bonne chose, mais au moins montre qu'il y a assez de gens intéressés pour y répondre). Il faut tailler, il rester quoi ?
Angular, Ember, Backbone, CanJS

Maintenant, penchons nous sur ces quatre gaillards. Mettez vous en ligne, et lançons quelques mots clés comme "comparatif". Je n'ai pas le temps d'étudier ces quatre là en profondeur, plutôt que de savoir ce que chacun fait, je veux savoir ce qu'ils font que les autres ne font pas. Et je tombe sur des concepts nouveaux pour moi qui peuvent m'intéresser. Plusieurs sites me renvoient notamment sur cet article qui, même datant d'un an, semble être une bonne base de réflexion.
Là, on entre dans le goût personnel. Par exemple, la flexibilité de Backbone me fait un peu douter, je suis un homme de convictions conventions. À contrario, la "learning curve" mauvaise d'Angular et d'Ember ne me rebutent pas telle qu'elle est affiché. "Un jeu d'enfant lors de sa prise en main, puis devient difficile pour des tâches plus précises" ? je code en CakePHP*, j'ai vu pire.
Je doute de Backbone, le rapport final de l'article finit de me convaincre (mais je l'aurais sans doute retiré même sans ça). Je retire CanJS pour... une question de popularité, afin de garder deux finalistes. Il semble aller au fond des choses, mais là encore je préfère penser à long terme, et pas seulement pour l'appli : je suis en CDD actuellement, qu'est ce qui fera le mieux sur mon CV après ça entre Angular|Ember et CanJS ?

Reste donc deux frameworks proposés. Je fais de nouvelles recherches plus précises, et pour couper court à tout suspense, Angular en ressort vainqueur. J'aime bien le html déclaratif, ça change que d'utiliser les data-items pour tout et pour rien (et surtout en dehors de leur champ d'application). De plus Angular semble plus proche d'un travail de dev frontend, comme on le fait déjà par ex en ajoutant jQuery à son application.
Je suis après tombé sur des articles où les utilisateurs d'Ember lui reprochent d'être difficile à utiliser, trop rigide, moins adapté à leurs habitudes. Les devs en semblent conscients et veulent travailler sur cet aspect, tout en rappelant que Ember n'est pas adapté sur on veut un framework JS qui fonctionne sans avoir à changer sa manière de penser. Et l'extension du html au lieu d'ajouter un langage de template me séduit : d'accord, je ne suis pas un dev frontend, mais je ne comprends pas qu'on puisse aimer Smarty. Ça me parait aussi moche que ceux qui écrivent<?php echo '<td>'.$var.'</td>'; ?>
Plutôt que :<td><?php echo $var; ?></td>

Pour ces raisons, quelques comparatifs Angular/Ember (modulo mes goûts personnels), et ton avis détaillé qui finit de me convaincre, on part sur AngularJS épicétouhallonzyalonzo.

Meowcate (./21) :
De plus Angular semble plus proche d'un travail de dev frontend, comme on le fait déjà par ex en ajoutant jQuery à son application.

Ben ouais, c'est pour ça que je ne comprenais pas trop tes réticences au début. Ce sont plutôt des technologies faites pour te simplifier la vie (moins de code, meilleure séparation des fonctions) que l'inverse ^^
Le seul défaut dans tout ça c'est que ça fait plus de code javascript et que le javascript c'est un langage à la con. (Avis perso inside )

Et l'extension du html au lieu d'ajouter un langage de template me séduit

Ben, c'est juste du data-binding comme on le fait en XAML du côté de chez Microsoft, quoi

d'accord, je ne suis pas un dev frontend, mais je ne comprends pas qu'on puisse aimer Smarty.

Ça partait quand même d'une bonne intention… Mais pratiquement tous les langages de template ont ce même défaut, malheureusement. (La seule exception qui me vient à l'esprit là c'est le XSLT, mais c'est même pas un langage à part entière ^^)

ton avis détaillé qui finit de me convaincre, on part sur AngularJS épicétouhallonzyalonzo.

Ouais heu, détaillé, bof bof
M'enfin, je pense de toutes façons que si tu vises à te spécialiser dans le dev web, dans les années qui viennent, AngularJS sera en effet un incontournable. (Et tu peux le vendre comme tel sur ton CV)


(Après, même si ça se comprend, je suis quand même déçu que tu n'aies même pas considéré Durandal (En gros Knockout + RequireJS + jQuery))