Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Dropbox explique pourquoi son appli pour Android et iOS passe du multiplateforme via C++
Au natif en Kotlin et Swift

Le , par Patrick Ruiz

93PARTAGES

7  0 
Le développement mobile multiplateforme offre à minima un avantage évident à entrevoir : l’équipe monte une base de code une seule fois, ce, pour diverses cibles ou plateformes. L’approche peut s’avérer utile pour les petites équipes aux compétences peu variées, mais que la nécessité d’aller en production le plus vite possible s’impose. Depuis 2013, l’équipe Dropbox s’appuie sur cette stratégie. Elle cible les plateformes Android et iOS via un unique base de code mise sur pied en langage C++. Dans une publication parue il y a peu, un ingénieur explique pourquoi l’entreprise préfère désormais le développement natif en Swift et en Kotlin.

« En montant notre base de code d'une manière non standard, nous avons hérité de coûts dont nous n'aurions pas eu à nous soucier si nous nous étions alignés sur les canons par défaut dont des tiers font usage à grande échelle. Au finish, cela est revenu plus cher que d'écrire du code deux fois », a-t-il indiqué. De façon brossée, le retour d’expérience de l’ingénieur de Dropbox laisse filtrer que le choix de l’approche de développement multiplateforme introduit des coûts de développement additionnels liés à la mise sur pied de frameworks et bibliothèques personnalisés. Ça, c’est sans compter ceux relatifs à la mise sur pied d’outils de travail custom ou la nécessité de former ou recruter des tiers capables de s’adapter à une pile logicielle très personnalisée.

En effet, Eyal Guthmann souligne que le choix de C++ pour le développement multiplateforme Android et iOS peut mener les développeurs à faire face à des difficultés qu’ils n’auraient pas eues en natif. Par exemple, indique-t-il, la mise sur pied d’un framework pour la gestion des tâches qui s’exécutent en arrière-plan peut s’imposer dans la filière développement multiplateforme en C++. À contrario, explique l’ingénieur de Dropbox, il ne s’agit pas d’un problème en natif. Eyal Guthmann relève même que l’équipe Dropbox a, dans le process, dû mettre sur pied une bibliothèque JSON pour C++11 ainsi qu’une autre pour la gestion des pointeurs NULL. L’ingénieur de la firme est même allé plus loin en mettant en exergue que c’est verser dans la théorie que de penser qu’on peut monter une unique base de code pour diverses plateformes. En effet, insiste-t-il, les spécificités de chaque plateforme constituent des facteurs auxquels on ne peut échapper. « La façon dont une application exécute une tâche en arrière-plan est spécifique à chaque plateforme et il faut en tenir compte dès le départ », précise-t-il.

En plus des considérations qui touchent au code, il y a celles qui concernent les outils de travail. À ce propos, l’ingénieur de la firme développe sur deux axes : le débogage et la mise sur pied d’outils personnalisés. « L’expérience de débogage en natif est de façon générale supérieure à celle en C++ via l’IDE par défaut de la plateforme cible », écrit-il avant d’ajouter qu’ « en plus de devoir se détourner des outils disponibles, nous avons dû mobiliser des efforts de développement pour la mise sur pied d’autres à même de supporter l’approche multiplateforme en C++. »

Enfin, pour ce qui est des aspects liés à la formation et au recrutement, Eyal Guthmann indique que l’aventure multiplateforme s’est construite autour d’un noyau d’ingénieurs avec une forte expérience en C++. Avec les départs de ces derniers vers d’autres équipes ou entreprises, l’entreprise a eu de plus en plus de mal à combler le gap technique pour maintenir la base de code C++. En interne comme en externe, la firme a eu du mal à former et à recruter sur cet axe, car il semble que très peu de développeurs mobiles portent un intérêt au C++.


Le passage de l’équipe Dropbox au natif via Kotlin et Swift pour Android et iOS vient avec des avantages. De façon classique, on attribue à cette approche de générer des applications capables de tirer un excellent parti des ressources du système d’exploitation et du matériel à disposition. Au-delà du besoin d’écrire du code une seule fois pour plusieurs plateformes, l’on peut arguer que le choix de C++ dès le départ permet de rester sur ledit axe. En effet, le langage C++ fait, à côté du C qu’on ne cite plus, office de dénominateur commun pour la gestion de telles problématiques. Il n’est pas difficile d’imaginer que le groupe initial d’ingénieurs l’avait intégré pour la gestion de certains aspects critiques du backend. Seulement, des questions sur la qualité de l’interfaçage du langage C++ avec les plateformes cibles peuvent être mises sur la table. À ce propos, il faut noter que l’équipe Dropbox s’est appuyée sur Djinni – un framework qui permet d’interfacer du code multiplateforme C++ à du code Java ou Objective-C. D’après les retours de développeurs tiers, ce dernier opacifie l’interface avec la plateforme cible, ce qui finit par transformer le flux d’exécution en un chaos d’appels incontrôlables.

Source : billet de blog

Et vous ?

Qu’en pensez-vous ?

Est-il mieux d’écrire tout le code pour chaque plateforme comme l’a décidée l’équipe Dropbox ?

Quand est-ce que le développement multiplateforme est-il plus bénéfique ? Quelles sont alors les solutions les plus rapides ?

Ces approches ne présentent-t-elles pas trop d’avantages en commun de nos jours ? Surtout avec l’avènement de frameworks comme Flutter ?

Voir aussi :

Google publie la Preview finale de Flutter, son SDK mobile Android et iOS, la dernière étape majeure avant la publication de la version stable 1.0
Quels sont vos environnements de développement intégrés (EDI) préférés en 2018 ? Et pourquoi ? Partagez vos avis
Le mode sombre d'Android permet-il d'économiser l'énergie de la batterie des smartphones ? Oui, confirme Google
Kotlin 1.3 est disponible : coroutines désormais stables, Kotlin/Native Beta, bibliothèques multiplateformes et bien plus encore

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de onilink_
Membre expérimenté https://www.developpez.com
Le 15/08/2019 à 13:03
Donc en gros C++ c'est pas natif (???) car faut implémenter soit même une lib json et une gestion des pointeurs null?

Je comprend qu'avec leur équipe qui perd ses membres compétents en C++ il fallait passer à quelque chose d'autre (à défaut de trouver de nouveau ingénieurs) mais de la à rationaliser comme il le font...
Je comprend pas en quoi du C++ pourrait être moins natif sur Android et iOS que Kotlin et Swift.
J'imagine qu'ils veulent parler des accès à l'API de l'OS, mais bon ça c'est pas vraiment la faute d'un langage si l'API de la plateforme est mauvaise... et surtout tu t'en rends compte pendant le choix de la techno, pas après avoir codé le logiciel en entier.

Leur façon de présenter les choses est très mal tournée... et ça me conforte dans l'idée à jamais aller faire du dev pour smartphone, s'il est plus efficace de réécrire 2x un logiciel plutôt que faire une basecode cross-platform, quelle horreur.
7  2 
Avatar de SimonDecoline
Membre expert https://www.developpez.com
Le 15/08/2019 à 14:52
Citation Envoyé par onilink_ Voir le message
faut implémenter soit même une lib json et une gestion des pointeurs null?
C'est à partir de là que j'ai commencé à avoir des doutes... Des lib C++ pour gérer du JSON ou des null, ça existe depuis des années. S'ils veulent tout coder eux-mêmes, faut pas s'étonner que ça demande du travail...

Citation Envoyé par onilink_ Voir le message
tu t'en rends compte pendant le choix de la techno, pas après avoir codé le logiciel en entier
C'est surtout, qu'ils devaient déjà avoir une base de code avec les applis desktop, qu'ils devront continuer à maintenir d'ailleurs.

Citation Envoyé par onilink_ Voir le message
ça me conforte dans l'idée à jamais aller faire du dev pour smartphone, s'il est plus efficace de réécrire 2x un logiciel plutôt que faire une basecode cross-platform, quelle horreur.
Oui, au lieu de perdre du temps à rendre leur base multiplateforme ils vont perdre du temps à la développer 2 fois en parallèle. Pas sûr que ce soit beaucoup plus efficace. Et dans quelques années, ils vont peut-être nous sortir un article expliquant pourquoi ils ont migré vers un framework déjà multiplateforme, comme Qt mobile.
2  0 
Avatar de der§en
Membre actif https://www.developpez.com
Le 15/08/2019 à 16:59
Tu as oubliés dans ta liste Delphi et son framework multiplateforme FIREMONKEY.
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 16/08/2019 à 8:50
Citation Envoyé par onilink_ Voir le message
Donc en gros C++ c'est pas natif (???) car faut implémenter soit même une lib json et une gestion des pointeurs null?

Je comprend qu'avec leur équipe qui perd ses membres compétents en C++ il fallait passer à quelque chose d'autre (à défaut de trouver de nouveau ingénieurs) mais de la à rationaliser comme il le font...
Je comprend pas en quoi du C++ pourrait être moins natif sur Android et iOS que Kotlin et Swift.
J'imagine qu'ils veulent parler des accès à l'API de l'OS, mais bon ça c'est pas vraiment la faute d'un langage si l'API de la plateforme est mauvaise... et surtout tu t'en rends compte pendant le choix de la techno, pas après avoir codé le logiciel en entier.
Disons que tout dépend de la définition de natif que l'on se donne. Si ta définition c'est ce qui se compile directement en code machine alors oui C++ est on ne peut plus natif.

Mais la définition de natif dans ce cas là c'est ce qui s'intègre le mieux avec les environnement de développement standard avec notamment, en effet, une API adaptée. Et là, force est de constater que Android et iOS, n'ont pas du tout été prévus avec le C++ comme langage principal, particulièrement en ce qui concerne l'interface graphique, qui n'est pas du tout facile a utiliser dans ce cas là. Mozilla a fait la même constatation, l'IHM de Firefox mobile a été refaite en Java sous Android, car le C++ n'est pas adapté à un fonctionnement optimal dans ce domaine.

Alors oui ce n'est pas la faute du langage en soi, si les OS mobile avaient été concu avec des API standards adaptées au C++, la situation serait probablement inverse, mais c'est le constat que l'on fait aujourd'hui dans la pratique.
2  0 
Avatar de onilink_
Membre expérimenté https://www.developpez.com
Le 16/08/2019 à 11:43
Oui, j'avais cru comprendre mais je ne suis pas sur que du coup natif soit le terme le plus adapté étant donné qu'il à déjà un autre sens.
Triste pour le C++ en tout cas de ne pas bénéficier de bonnes APIs... ça simplifierais quand même énormément les choses pour du vrai dev crossplatform.

Citation Envoyé par Neckara Voir le message
Je dois avouer que je ne comprend pas pourquoi ont ils besoin d une bibliotheque pour gerer les pointeurs nuls ?
J'imagine que c'est pour le fameux not_null<T>, mais y a déjà une implé: gsl::not_null, du coup je ne comprend pas trop l'idée de le réimplémenter... si c'est bien ça.
2  0 
Avatar de Neckara
Expert éminent sénior https://www.developpez.com
Le 15/08/2019 à 22:12
Je dois avouer que je ne comprend pas pourquoi ont ils besoin d une bibliotheque pour gerer les pointeurs nuls ?
1  0 
Avatar de Matthieu76
Membre éclairé https://www.developpez.com
Le 16/08/2019 à 15:17
Citation Envoyé par Neckara Voir le message
Je dois avouer que je ne comprend pas pourquoi ont ils besoin d une bibliotheque pour gerer les pointeurs nuls ?
Ce n'est pas une bibliothèque pour gérer les pointeurs nuls, c'est une bibliothèque pour gérer les développeurs nuls
1  0 
Avatar de redcurve
Membre confirmé https://www.developpez.com
Le 15/08/2019 à 14:38
Citation Envoyé par onilink_ Voir le message
Donc en gros C++ c'est pas natif (???) car faut implémenter soit même une lib json et une gestion des pointeurs null?

Je comprend qu'avec leur équipe qui perd ses membres compétents en C++ il fallait passer à quelque chose d'autre (à défaut de trouver de nouveau ingénieurs) mais de la à rationaliser comme il le font...
Je comprend pas en quoi du C++ pourrait être moins natif sur Android et iOS que Kotlin et Swift.
J'imagine qu'ils veulent parler des accès à l'API de l'OS, mais bon ça c'est pas vraiment la faute d'un langage si l'API de la plateforme est mauvaise... et surtout tu t'en rends compte pendant le choix de la techno, pas après avoir codé le logiciel en entier.

Leur façon de présenter les choses est très mal tournée... et ça me conforte dans l'idée à jamais aller faire du dev pour smartphone, s'il est plus efficace de réécrire 2x un logiciel plutôt que faire une basecode cross-platform, quelle horreur.
Perso je n'utilise que Xamarin/Xamarin Forms suivant le besoin ça permet de ne pas avoir à me taper deux fois la même appli. Et oui je confirme les apis androids sont vraiment mal foutu, sur iOS Apple adore les bonnes grosses variables globale .
0  0 
Avatar de wistiti1234
Membre régulier https://www.developpez.com
Le 15/08/2019 à 16:27
Bah c'est sûr, si ils supportaient à bout de bras leur appli + leur propre framework, développé ad-hoc pour leur appli....

Mais qu'en est-il de la comparaison d'un appli développé deux fois de zéro pour deux plateformes différente, ou d'une appli développé une seule fois, mais reposant sur un vrai framework multiplateforme, fais par d'autres, dont c'est l'unique objectif (Qt, React Native, Flutter, Xamarin, ...) (je n'ai pas l'impression qu'on peut considérer Djinni de ce calibre là).
0  0 
Avatar de Madmac
Membre éprouvé https://www.developpez.com
Le 16/08/2019 à 6:13
Citation Envoyé par onilink_ Voir le message
Donc en gros C++ c'est pas natif (???) car faut implémenter soit même une lib json et une gestion des pointeurs null?

Je comprend qu'avec leur équipe qui perd ses membres compétents en C++ il fallait passer à quelque chose d'autre (à défaut de trouver de nouveau ingénieurs) mais de la à rationaliser comme il le font...
Je comprend pas en quoi du C++ pourrait être moins natif sur Android et iOS que Kotlin et Swift.
J'imagine qu'ils veulent parler des accès à l'API de l'OS, mais bon ça c'est pas vraiment la faute d'un langage si l'API de la plateforme est mauvaise... et surtout tu t'en rends compte pendant le choix de la techno, pas après avoir codé le logiciel en entier.

Leur façon de présenter les choses est très mal tournée... et ça me conforte dans l'idée à jamais aller faire du dev pour smartphone, s'il est plus efficace de réécrire 2x un logiciel plutôt que faire une basecode cross-platform, quelle horreur.
Je pense que le choix de C++ étaient basé sur l’existence de GUI multi-plateforme. Elles existent, mais leur problèmes est qu'elles ont uniquement des composantes communes aux trois plateformes (Microsoft, Apple, Linux). Avec résultat que l'on doit faire des interface sans certains éléments d'interface spécifique à chaque OS.
1  1