Android Instant App, des applications qui se chargent comme des pages web

Vous voilà en ligne, vous surfez sur un site qui vous invite à aller consulter un service particulier. Pour enrichir l’expérience, l’éditeur se décide à vous orienter vers un lien particulier qui n’affichera non plus du web mais bel et bien une application. Du coup, vous pouvez profiter d’un autre type de code et de fonctions avancées liées au monde des applications. C’est Android Instant apps.

Evidemment cela à un côté hyper pratique, certaines applications que vous n’allez jamais utiliser plus d’une fois  et qui réclament des tonnes de droits ou d’espace de stockage pourrons être lancées une fois et une seule pour remplir leur rôle.

Quand vous voulez réserver une chambre d’hôtel en pleine nuit en Islande, l’application de 40 Mo nécessaire pour vous ouvrir la porte de l’hôtel low-cost en face de vous peut paraître un chouilla contraignante à télécharger en roaming. Avec Android Instant App, vous pourrez utiliser le service en le chargeant simplement comme une page web.

Prévu pour un peu plus tard dans l’année via une mise à jour automatique des services de Google, Android instant App concernera tous les appareils exécutant Android 4.2 ou autres versions ultérieures. Dès la mise à jour en place, en consultant un site web proposant une application de ce genre, il suffira d’un clic pour accéder à ce contenu spécifique et de fermer l’onglet pour éteindre la tâche sans qu’aucune application ne se soit installée sur votre smartphone.

Cela permettra aux éditeurs de proposer des services plus vastes, des protocoles de sécurité différents de ceux utilisés en ligne et de profiter de fonctions avancées de votre appareil que le web ne gérera pas facilement. Bref de faire en sorte de proposer plus d’interactivité sans pour autant venir installer systématiquement une application de quelques dizaines de mégaoctets.

Accéder à des contenus enrichis

Les usages seront nombreux : Des expériences narratives plus poussées, des jeux en ligne voulant profiter des capteurs de votre appareil, le paiement de services hyper ponctuels, la création d’un panier de paiement. Evidemment, si il s’agit de jeux plus lourds ou d’applications récurrentes, il sera toujours plus intéressant de télécharger et d’installer une application dédiée.

Payer le parcmètre au passage d’une ville …

Deux questions me viennent à l’esprit. Quid de la sécurité du processus? Si un QR code ou un simple lien peut envoyer vers une Android Instant App par exemple et que celle-ci se comporte malicieusement, il y aura forcément rapidement des dégâts. On peut supposer que Google n’autorisera pas de tout faire à ces applications, limitant leurs possibilités du simple fait de ne pas demander d’autorisation à l’utilisateur. Empêcher qu’elles puissent venir pomper votre carnet d’adresses ou votre localisation sans votre consentement par exemple, me parait être un minimum.

Android Instant App permet à l’éditeur de contrôler votre navigation à 100%

La seconde question qui me turlupine, c’est l’intérêt que pourra trouver un éditeur à proposer ce type d’application. On le voit très bien aujourd’hui, ces derniers n’hésitent pas à demander des dizaines de droits différents pour accéder à vos informations privées et à occuper des dizaines de mégaoctets d’espace pour exécuter des fonctions hyper basiques comme proposer une lampe de poche. Je doute que peu d’éditeurs soient enclins à proposer une application en ligne pour satisfaire les utilisateurs.

A moins que. A moins que ces derniers ne réalisent l’avantage énorme de passer par une application au lieu d’une page web pour accéder à certains services. Car il y a une grosse différence entre un navigateur et une application, la publicité. L’éditeur qui passera par une application chargée en temps réel pourra imposer de la publicité et relever les cookies qu’il souhaitera qu’il souhaite même si votre navigateur est muni d’un système de blocage de publicité et anti fouineurs. La grosse différence est là et je ne doute pas un instant que d’ici peu de temps des pans entiers de sites web passent, si un Adblock est détecté, par la fenêtre d’une Android Instant App. Le contenu ne changera pas mais vous ne passerez plus à côté de la pub.

 

12 commentaires sur ce sujet.
  • 24 mai 2016 - 18 h 10 min

    Si les gens ne cliquaient pas sur les pubs, ils en colleraient moins !!!

    Répondre
  • 24 mai 2016 - 18 h 30 min

    les applets java: le retour :-)

    et sinon pour ceux qui n’ont pas android il se passe quoi?

    Répondre
  • 24 mai 2016 - 20 h 23 min

    @r2d2: Google a un outil AR (Android Runtime for Chrome, c’est ce qui faisait la compatibilité Android de ChromeOS l’année dernière, cette année ils on changé) qui permet d’exécuter la plupart des apps Android dans Chrome. Je ne sais pas si ils ont prévu d’utiliser ça pour ça.

    Répondre
  • 24 mai 2016 - 22 h 58 min

    Visiblement ils essayent de parvenir à la convergence de leurs systèmes et probablement à l’unification transparente de ceux-ci. Techniquement ca va pas être simple car si leur modèle (Microsoft) y parvient c’est grace à des applications dites universelles qui vont marcher sur pc et téléphone, x86et arm… Faire tourner le parc android actuel sous différents processeurs ce n’est possible qu’avec certaine applications.

    On voit bien que google crée différents stores selon la machine qui y accède et qui ne pourra dl que les applis avec lesquelles elle est compatible. C’est bien différent et pas tellement optimisé. Très limitant en tout cas et source de frustration pour l’utilisateur.

    En apparté : Quant à apple avec ses deux systèmes incompatibles, y a du retard à combler.

    Répondre
  • 25 mai 2016 - 2 h 03 min

    @Dadoo: gné ? Les apps Android sont typiquement en pur java, compilé a l’installation. Ca tourne sur de l’ARM, du MIPS, de l’Intel… C’est le contraire de ce que tu dis en fait: quasi toutes les applis Android tournent sur n’importe quoi (et en natif !), sauf les applications qui ont du code spécifique a un CPU/une architecture (typiquement, les jeux rapides).
    Google ne crée pas différents stores suivant la machine qui y accede, les editeurs ont la possibilité de whitelister ou blacklister les machines suivant une foultitude de criteres (version android, taille, marque, modele, pays, langue…)

    Répondre
  • 25 mai 2016 - 3 h 16 min

    @Dadoo: Tu peux argumenter sur l’approche Appel, ou c’est du pur troll?

    Je trouve que ce que propose Google est a la fois existant et un peu con.
    Un peu con car il y a le web pour faire ca, et il le fait très bien depuis des années (mais en moins bien intégré !). Et la Google rajoute une nouvelle techno qui ne sera compatible qu’avec Android.

    Excitant car ca laisse entrevoir un système ou les applications (certaines) deviendraient des services, qui se chargent dynamiquement selon les besoins et qui viendraient enrichir le système au fur et à mesure de son utilisation.
    Plus besoin de se prendre la tête à aller chercher la bonne application sur un Store pour réaliser tel ou tel service (comme réserver un hotel ou ouvrir sa chambre pour reprendre ton exemple). Là le module se charge automatiquement au moment ou l’utilisateur va en avoir besoin.
    Charge a l’OS de virer les services qui ne sont plus nécessaire.
    Un sorte de COM, OpenDOC, et al. généralisé.
    Et en tant que développeur, mon service référencera d’autres services, et l’utilisateur final ni vera que du feu, et aura une interaction continue.
    Bref le concept d’Intent et d’Activity poussés jusqu’au bout.

    A voir si les éditeurs/développeurs jouent le jeux. Mais pour DOC, OpenDOC et al. cela n’a pas été le cas !!!

    Répondre
  • chp
    25 mai 2016 - 10 h 26 min

    @Dadoo:

    Oulala… y’en a qui connaissent vraiment mal Android et son système.

    Comme l’a dit obarthelemy quasi la totalité des apps Android sont ecrites en Java et compilées sur la machine lors de l’installation.
    D’un côté c’est génial pour la compatibilité mais de l’autre côté c’est pas top coté perfs d’où l’escalade à la puissance des cpus (et gpus).

    Microsoft utilise une biblitheque (.NET) non normalisée alors que Java de son coté est normalisé (mais pas celui de Google) ce qui peut sous-entendre une portabilité facile des apps sur tout type d’OS et de CPUs.

    Répondre
  • 25 mai 2016 - 14 h 45 min

    De la merde, HERMIT (android) fait la meme chose mais en etant plus respectueux !

    Répondre
  • 25 mai 2016 - 20 h 35 min

    ” sauf les applications qui ont du code spécifique a un CPU/une architecture (typiquement, les jeux rapides).”

    Je pensais aux appli qui nécessitent un gpu puissant biensur. D’une façon générale quel est l’intérêt d’une application pas optimisée en fonction du hardware ? Tout depend des librairies disponibles pour le compilateur : justement oui, c’est ça.

    Bref si vous n’êtes pas d’accord, so be it, mais je pense vraiment ce que j’ai écrit.

    Pour apple j’essaie voir la big picture d’où ce que j’en dit.

    Répondre
  • 25 mai 2016 - 23 h 20 min

    @r2d2: Mais c’est tellement ca… Les Applets, ont vient de revenir à un concept qui a + de 20 ans.
    Comme quoi, tout est cyclique.
    On veut du centralisé, du client léger, puis non, du lourd, puis du léger, puis du pseudo léger, et puis la on retourne sur du lourd distribué sur du léger…
    En vrai, on ne sait pas ce qu’on veut ;-)

    Répondre
  • 26 mai 2016 - 1 h 08 min

    @Dadoo: [ D’une façon générale quel est l’intérêt d’une application pas optimisée en fonction du hardware]
    Justement tu ne sembles pas savoir comment fonctionne Android.
    Le pb n’est pas l’optimisation. “Toutes” les application sont optimisées et justement le JIT (ou la compilation à l’installation) s’occupe de faire tourner le code de manière optimale sur chaque CPU, quelque soit son architecture.

    Et concernant Apple, le big picture dont tu parles, tu le vois avec tes œillères, donc pas sur que tu le vois vraiment !?.

    Répondre
  • 26 mai 2016 - 2 h 07 min

    @izaref: Je ne pense pas que l’on ne sache pas ce que l’on veut.
    Je crois qu’avant tout, le software s’adapte aux contraintes Hardware et de cout.
    En prenant par exemple le temps des TX; A ce moment un ordinateur coutait un bras (plusieurs 10000€ pour un serveur Sun). Donc on avait des terminaux légers connectés au serveur.
    Puis un jour l’ordinateur de type IBM-PC est devenu moins cher qu’un TX. Donc tout a changer.

    Au début du smartphone, il y avait le GPRS voir la 3G. C’était pas très rapide et coutait cher. Donc tout était sur le smartphone, et les pbs de sync et d’install d’application, se résolvaient avec un cable connecté à son PC.
    Maintenant avec le LTE, ca bourre et ca coute presque rien. Le pb de sync existe toujours, et il est résolu avec le cloud. De loin ca ressemble aux systèmes Serveur+TX, mais dans les détails ca reste assez différents. Et en informatique le proverbe “le diable se cache dans les détails” est particulièrement vrai.

    Répondre
  • LAISSER UN COMMENTAIRE

    *

    *