Bien rater sa startup #6: Les applis Android rêvent-elles de moutons hybrides ?
Une incroyable plongée dans l’univers merveilleux d’une Start-up qui a tout raté, aimablement racontée par son fondateur désespéré mais qui fait sa V2 et lâchera pas l’affaire, t’entends.
Coucou les caribous. Aujourd’hui je titre avec un jeu de mot tout juste au dessus de la moyenne pour, enfin, toucher à l’intouchable, sonder l’insondable : parler de technique.
Alors, comme je vous le disais la semaine dernière, les problématiques techniques sont multiples quand on monte une startup sur les internets, et j’aimerais en parler assez extensivement dans ces petits posts de la loose, mais il me faut vous découper ça avec la précision d’un boucher de quartier sinon vous allez vous retrouver avec un cochon entier pour le petit dej.
On va donc commencer par les choix de techno du dev mobile, et tâcher de ne pas digresser dans trop de directions. C’est parti.
C’est de l’exploitation mec
Voilà comment ça marche. Quand on veut développer une application mobile, il faut se frotter à ce que l’on appelle des systèmes d’exploitation (OS) — oui, vous le savez déjà, je pose les bases. En 2014, il y en a 4 notables :
Et pour faire marcher un programme sur les téléphones qui tournent sous ces OS, il faut le coder avec le ou les langages prévus par le système. En l’occurrence :
Vous commencez peut-être à sentir poindre le problème. Si je veux sortir une appli pour ‘tout le monde’, soit sur les 4 principaux OS, je dois en réalité travailler sur, et maintenir, 4 applications complètement différentes. Elles se connecteront aux mêmes serveurs via la même API, mais leur code n’aura pas grand chose de similaire.
Enfin, faut tout faire quatre fois, quoi. Est-ce qu’il y a une solution ?
Souvent, sur le marché, on fait ça :
Ouais, pas con. On commence par le haut du panier, et puis on redescendra progressivement sur les autres OS par la suite. La suite étant généralement ça :
Bon, mais moi je suis plus intelligent que tout le monde, alors je me suis dit « nan mais attends il doit bien y avoir un moyen de contourner le problème ? » Bingo, il y a l’hybride.
Du Toyota Prius dans ton appli
C’est assez futé. Dans le principe, une plate-forme hybride s’intercale entre l’OS mobile et mon appli. Elle est développée dans chaque langage, mais de mon côté elle me permet de coder une seule fois en HTML5, à l’aide de ce que l’on appelle une ‘webview’. Les mecs cools appellent ça un Framework.
Il y en a pas mal mais citons Ionic, Mobile Angular UI, PhoneGap ou Sencha Touch.
Je vous passe nos échanges sur les mérites comparés de chacun, nous avons fini par nous décider sur Ionic après une haletante partie de chamboule-tout dans la cave de l’immeuble.
Malgré mes simplifications outrancières, vous aurez compris que le choix de l’hybride permettait de nous épargner pas mal de boulot, et il y avait même un bonus ! Ionic, en effet, est basé sur une librairie nommée AngularJS, courtesy Google, et qui permet de créer de puissantes applications web (car oui, même si Ionic permet de faire des applis, en fait derrière ce qui tourne c’est une sorte de site web).
Donc en bossant sur l’appli, on pouvait récupérer une partie substantielle du code et avoir le site web pour le même prix.
Mark Zuckerberg à dit en 2012 au sujet de l’application mobile Facebook que « Our biggest mistake was betting too much on HTML5 ». Comprendre : l’hybride, ça pue. Pour ma part, j’ai jugé que la technologie avait pas mal évolué entre 2012 et 2015, et que de toute façon ce type s’habillait comme un plouc.
Bingo, ai-je donc dit.
Vous l’aurez compris, le mec est meilleur que moi et j’aurais mieux fait de l’écouter.
Oh Mark you were so right, please forgive me
J’ai connu un crétin qui s’était tatoué « le diable est dans les détails » pour ne pas oublier de réfléchir aux petits riens qui font souvent capoter les plans les mieux conçus, mais comme l’œuvre était derrière son mollet, il ne la voyait jamais et tombait tout le temps dans les mêmes panneaux.
Car oui, en matière d’hybride, il y a quelques conséquences bien miteuses a considérer.
La première et principale tient à la nature même du concept. Finalement, ce qu’on a c’est une appli qui tourne sur un téléphone, et dans cet appli tourne une page web. Un écran dans un écran. Le code web est interprété par le framework pour être compris par l’OS. Imaginez cette interprétation comme un type qui traduit ce que dit un autre, ça prend du temps et il a parfois des morceaux qui se perdent dans le processus > Référence grossière :
Notez que tout code, d’une matière ou d’une autre, est interprété, et même en natif le système d’exploitation va faire son taf pour transcrire le code en un langage que la machine peut comprendre, mais je complique le débat pour rien.
Du coup, Castr, dès le début, c’était lent. Il fallait 4–5 secondes pour charger le premier écran, et quand on est arrivé au terme du développement, ça avait grimpé à 10 secondes. 10 secondes devant un splashscreen, c’est l’équivalent de 8h chez ma grand-mère, on a largement le temps de repenser toute sa vie et de se dire 50 000 fois qu’on a envie de se tirer. Rappelez vous les Hateful Three de la semaine dernière :
Le deuxième problème, c’est qu’une fois que c’est lancé, c’est statique. Aujourd’hui lorsque vous bidouillez sur vos Snapchat, Twitter & co, ça bouge dans tous les sens, il y a des transitions entre chaque écran, des animations sur chaque bouton, du Material Design, tout ça. Ce genre de mouvement arrive pratiquement out of the box en natif. Mais sur une webview, quedalle. Il faut tout rajouter soi-même (c’est pas tout à fait vrai je re-simplifie-au-max), c’est coûteux en temps de travail et en rapidité générale de l’appli.
Troisième galère: en théorie le code source est unique et le framework permet de exécuter correctement sur tous les OS mobiles. Mais dans la réalité il y aura forcément des variations à prendre en compte. D’abord parce que ces derniers ne sont pas tous nés égaux. Certaines choses possibles sur Android ne le sont pas forcément sur iOS, et vice-versa.
Les usages diffèrent aussi. Il n’y a pas de bouton retour sur les terminaux Apple, il y a un clavier physique complet sur les Blackberry, les accès a la galerie de photo ou à l’appareil ne sont pas les mêmes sur chacun, etc.
Quoi qu’il arrive, il faudra donc à un moment prévoir plusieurs cas particulier pour chaque support. Notre joli schéma de l’hybride ressemble donc plutôt à ça:
Et enfin, le framework a parfois ses limitations. On a notamment eu le cas de la géolocalisation qui s’est avéré problématique : en gros si je travaille en natif — sur Android dans cet exemple — et que j’ai besoin de récupérer la position de l’utilisateur, hé ben je fais la même chose que quand j’ai besoin d’une recette de Crozets, je demande à Google, et Google répond.
Car Google a des routines qui tournent en permanence sur Android — des ‘services’. L’un d’entre eux stocke en permanence une position, basée sur la position GPS de mon utilisateur, mais aussi sur sa position par rapport aux relais de data et réseaux wifi (c’est pour ça, entre autres, qu’il cartographie les réseaux wifi dans nos belles contrées, ce qui ennuie beaucoup les Allemands). Je peux lui demander quand je veux, et lui de son côté il fait sa sauce et me donne une réponse correcte à chaque fois, précise, sans être coûteux en batterie ni en data.
Donc nous on avait un plug-in pour faire ça, mais, allez comprendre, ça marchait pas. Pour récupérer notre position, il fallait donc interroger directement le GPS de l’utilisateur, ce qui est long, beaucoup moins précis et dévore de la batterie à toute vitesse. Pour un réseau basé sur la géoloc, c’est ballot. Il a donc fallu nous-même créer nos plug-ins natifs pour pallier au problème.
Voila, on fait de l’hybride, et finalement on fait du natif. Plus long, plus chiant, moins beau, fail.
Ca avait l’air pas trop mal quand même ? Ben non, j’ai coupé les temps de chargement au montage, Denis la malice.
Ouais mais tout de même
Bon, attention, je ne suis pas là pour cracher dans la soupe. Ionic est un super framework et la technologie évolue relativement vite. AngularJS, sur lequel repose une partie de son infrastructure, est passé en version 2.0 et beaucoup plus orienté mobile, ce qui supprime de fait une bonne partie des problèmes techniques que nous avons eu. Il y a aussi de plus en plus de librairies et de plug-ins à rajouter par dessus pour les cas plus spécifiques.
En fait je pense que l’hybride reste dans tous les cas très approprié au prototypage d’appli, et plus généralement à tout ce qui est simple, une calculette, un chrono, ce genre de trucs. Mais si vous faites un réseau social géolocalisé avec 4 feeds en parallèle, du temps réel et des appels à l’API dans tous les sens, bof.
Par ailleurs, de nouveaux paradigmes sont apparus depuis qui vont probablement finir par changer définitivement la donne, notamment la librairie React -courtesy Facebook ce coup-ci- et son pendant React Native qui permet de coder à l’aide de langages web mais sans passer par un interpréteur qui ralentit le tout. A mon avis c’est pas encore prêt, mais c’est prometteur.
La morale de cette histoire ? On est perdus là.
Alors voilà, de retour en 1985 (au 23ème étage de la tour Biff), nous sommes revenus au point de départ.
On a donné dans l’hybride la première fois, et ce coup-ci on voulait une appli rapide, stable, avec les petites animations kikoo. Il a donc fallu repartir sur du natif, et avec, faire le choix de l’OS de prédilection. En 2016 la situation est donc la suivante :
On sait tous, bien sur, que :
Donc iPhone, ouais ? La plupart des startups se lancent d’abord sur iPhone, tous les business angels de la planète en ont un, et probablement la majorité d’entre vous, mes chers lecteurs égarés sur internet. Malgré tout, quand on regarde la part de marché de chacun, ça donne ça :
Et moi, à choisir, je préfère produire Castr pour 81 % des gens que pour 16. Alors ouais, à chaque fois que l’on n’en a fait qu’à notre tête, on s’est plantés.
Qui sait, peut-être que ce coup-ci on aura raison ? — Un audacieux Startuper
Il ne s’agit pas de refaire l’éternelle baston Apple-Google, mais ma conviction est que l’avenir est plus du coté d’Android qu’iOS. On part donc là dessus, et la version iPhone viendra plus tard.
Bonus quand même, Castr 2 est développé dans un langage qui s’appelle Kotlin et qui est très proche de Swift — pour iOS, rappelez vous — dans ses logiques et son implémentation. Ce qui devrait faire de la version Apple un simple portage plutôt qu’une reconstruction complète.
Allez c’est chiant, on passe à la culture. Sous-culture même cette semaine.
♩ ♫ L’instant sous-cultuuure ♫ ♪
OUAIS, une pub pour une carte graphique. Mais alors quelle merveille, quel bijou. Regardez, la vache, il y a TOUT là dedans:
- Un nom génial, dès la première seconde. La carte graphique s’appelle Mystique. Pourquoi? Mystère.
- Boum un PUTAIN DE CLOWN. #marketinggenius
- C’est parti, de l’euro-dance dégueulasse pendant deux minutes, accroche-toi.
- La caméra qui filme l’ensemble parce que visiblement à l’époque c’était trop compliqué de capturer directement l’écran. Et qui filme l’ensemble EN DIAGONALE POUR ETRE PLUS COOL
- Du glitch ! Du glitch avant que ce soit cool.
- Un mec qui fait du saut en parachute en surf alpin en combinaison blanche avec un bruitage de malade tout est si cool
- J’en suis qu’a 19 secondes, il reste 1 minute 40 et mes yeux saignent déjà
- Les bruitages continuent ils ont tout sorti les mecs c’est complètement fou
- Les mots Destruction Derby 2 / Mech Warrior 2 / Scorched Planet qui défilent. Je pense fugacement à mon enfance avant d’être violé par une nouvelle image du clown qui me surveillait depuis le début
- Gonzesses sur la plage, 3D gaming big screen suivi d’un écran 15 pouces absolument titanesque
- “Multi source frame capture”, je sais pas ce que ça veut dire mais je le veux.
- Visioconférence avec Papou, multiplication des bruitages, tout devient fou, je fais une pause.
Je ne veux pas vous spoiler la deuxième minute mais jetez un oeil avant d’aller gober vos cachets anti-epilepsie, ça vaut le détour.
BREF, pourquoi cet instant culture? Parce que c’est ça, la culture visuelle des années 90.
Parce que cette horreur, cette gerbe de couleurs et de formes, qui crache sur deux mille années de règles de composition pour me balancer ses mots clés incompréhensibles à la gueule, cette horreur à sa place dans un musée.
C’est un compte rendu vibrant et flamboyant de la joie des k-ways verts et violets et des luminous phosphorescents qui ont bercé la jeunesse de millions de trentenaires d’aujourd’hui.
C’est un porte drapeau de l’absence totale de bon goût qui caractérisait le marketing de produit technologique pour adolescent durant cette décennie magique et minable à la fois.
C’est un témoin silencieux qui rappellera éternellement à nos générations futures que non, nous n’avons pas été plus fins et sophistiqués que les millenials et leurs selfies à la con, et que pour nous le top du cool c’était d’avoir une combi blanche et de sauter d’un avion avec son surf alpin.
Quelle merveille.
Cheers
Barth Picq
