9 raisons pour lesquelles j’ai renoncé à être développeur mobile

À l’époque où j’étais à l’université, Android et iOS étaient encore de nouvelles plateformes et tout le monde était excité à leur sujet. Quand il y avait une sorte d’atelier de codage, vous avez presque certainement fini par créer une petite application Android. C’est ainsi que j’ai fait mes premiers pas dans l’écosystème Android et probablement aussi la raison pour laquelle je suis devenu développeur mobile juste après.

Dans cet article, je veux partager les expériences frustrantes que j’ai vécues avec le SDK Android et Flutter. Certains des points que j’aborde s’appliquent également au SDK iOS. J’ai cessé de travailler en tant que développeur mobile il y a quelques années et j’espère que beaucoup de choses ont changé pour le mieux. Mais même à l’époque, j’ai trouvé l’écosystème mobile si mal orienté que j’ai dû chercher un cheminement de carrière alternatif.

Fragmentation

Le plus gros problème pour chaque développeur Android est la grande variété de configurations d’appareils. Je n’ai jamais tout à fait compris pourquoi la meilleure partie du SDK (en particulier la partie interface utilisateur) n’était pas une dépendance de mon application mais intégrée dans l’appareil. Cela m’a essentiellement obligé à travailler avec les bibliothèques de support et à déboguer mon application pour chaque niveau d’API ciblé. En plus de cela, j’ai constamment vu des appareils Samsung ou Huawei tomber en panne sur du code qui fonctionnait très bien sur l’émulateur ou mes appareils de test.

Conception matérielle

Lorsque je lis des commentaires sur HackerNews ou Reddit sur la conception matérielle de Google, j’ai parfois l’impression d’être la seule personne qui aime ça. Je le trouve visuellement attrayant et apprécie généralement l’expérience utilisateur. le site officiel de documentation a parcouru un long chemin et je le considère comme un excellent exemple pour une excellente documentation. J’étais super excité quand il a été annoncé pour Android! Cela étant dit, la transition de Holo à Material Design sur la plate-forme Android n’a pas été du tout fluide. C’était comme si la libération avait été précipitée. Des widgets très basiques manquaient dans la bibliothèque de support officielle Material Design pour les années à venir. Même si vous pouvez parfois les admirer dans les propres applications de Google, ils n’ont pas trouvé leur chemin dans la bibliothèque d’assistance. Les développeurs ont été contraints de créer leur propre ou de saisir une implémentation alternative sur GitHub de qualité douteuse. Avec une bonne quantité d’incohérences visuelles et de bogues d’implémentation, l’expérience de la bibliothèque de support Material Design était probablement la première fois que je m’arrêtais pour vraiment réfléchir à l’écosystème et le questionner.

Meilleures pratiques que personne ne se soucie de suivre

C’est une tâche difficile de créer une application Android solide comme le roc. C’est principalement parce que le SDK est hostile aux développeurs. Il est étonnant qu’en théorie, une application Android puisse rester inactive en arrière-plan indéfiniment, sans consommer de ressources système et revenir à son état précédent lorsque l’utilisateur le souhaite. C’est du moins le cas si le développeur a réussi à implémenter la gestion de l’état et du cycle de vie.

Développeur Bonjour Internet, mon application se bloque lors du changement d’orientation, comment puis-je résoudre ce problème?
l’Internet C’est simple, juste désactiver les changements d’orientation

Aie. Mais c’est malheureusement assez courant.

Avez-vous déjà travaillé avec Threads en Java? Ce truc est super dur dans une base de code impérative avec des variables mutables partout. Eh bien, devinez quoi: c’est encore plus difficile avec le SDK Android. Si vous souhaitez gérer un Thread d’un Activity, vous êtes fondamentalement demander un mauvais moment. Heureusement, nous avons été retenus Fragments finalement cela a rendu cela un peu plus facile. Mais seulement au prix de Fragments en premier lieu.

Au cours de ma carrière en tant que développeur mobile, j’ai interviewé pas mal de développeurs Android seniors qui, à de très rares exceptions près, ont eu du mal à obtenir ces bons sujets.

J’ai toujours souhaité que Google fasse davantage pour reconnaître ces problèmes et travaille avec la communauté pour les résoudre. La situation s’est probablement améliorée avec Kotlin, mais les fondements douteux de l’écosystème Android se cachent toujours en dessous.

Concevez des modèles et des annotations pour les abstractions qui ne fonctionnent pas

Les développeurs ont rapidement compris qu’il était impossible de créer une application réelle en plus des abstractions fournies par le SDK Android. La solution était de nouveaux modèles de conception qui apparaissent probablement toujours sur une base hebdomadaire: MVC, MVP, MVVM et MVI sont ceux dont je me souviens. Et comme nous ne pouvions pas utiliser d’appels de constructeur ordinaires pour gérer les dépendances, nous avons dû disperser les annotations sur toute la base de code. Rien de tout cela n’aurait dû être nécessaire. Java, et plus encore Kotlin, sont suffisamment expressifs pour modéliser toutes ces choses de manière transparente et directe. Mais Android préfère les énormes définitions XML et l’instanciation réfléchissante, les développeurs doivent donc obscurcir leur code avec des annotations et des modèles de conception douteux. Honnêtement, je n’ai pas les mots pour exprimer à quel point c’est grave.

Avantage inutilisé de posséder la plateforme

D’une certaine manière, le développement natif iOS et Android est en concurrence avec le Web en tant que plate-forme. Cependant, ils ont l’énorme avantage d’appartenir à une seule entreprise, alors que le web a de nombreux acteurs qui souhaitent influencer son développement en fonction de leurs besoins. Pourtant, le Web est un écosystème plus vivant et innovant. Jetez un coup d’œil à la réussite de React: il est indéniable que l’approche basée sur les composants des interfaces utilisateur est l’abstraction la plus saine que nous ayons trouvée jusqu’à présent. Android a réussi à traverser cette tendance pendant des années jusqu’à annoncer enfin « Jetpack Compose », qui n’est toujours disponible qu’en avant-première développeur. À peu près la même chose s’est produite dans le monde iOS. Nous voici donc, héritant toujours d’un LOC 15k android.view.View classe avec des dizaines de méthodes de cycle de vie tout en essayant en quelque sorte d’injecter notre merge Fichier XML. iOS et Android pourraient être les vrais pionniers et les moteurs de la bataille ici, mais la concurrence les a complètement abandonnés.

Dans cet esprit, félicitations Android!

Développement de l’interface utilisateur: veuillez laisser vos attentes en dehors

La clé d’une application magnifiquement conçue est l’interface utilisateur. Maintenant, je me suis déjà beaucoup plaint du fait que les composants ne sont toujours pas une chose dans la section ci-dessus, mais il y a plus à ce sujet. Avez-vous déjà débogué un problème sur un site Web? Ouvrez les outils de développement de votre navigateur, cliquez sur l’élément affecté et jouez avec les propriétés CSS et HTML jusqu’à ce que tout semble correct. Par rapport à cela, Android est une boîte noire inaccessible. Pour être honnête, je n’ai jamais complètement maîtrisé les mécanismes de thème et de style Android et l’outillage autour de celui-ci semblait toujours totalement inutile par rapport à l’accessibilité du Web.

Vous voulez une ombre portée autour de cette boîte? Bien sûr, utilisez ce farfelu .9.png fichier ou compter sur l’API niveau 21 où vous pouvez rendre les ombres correctement (formes convexes uniquement si 😀).

Désolé, vous avez oublié d’implémenter l’un des quatre constructeurs dans votre vue personnalisée. Mais je ne vous arrête pas avec une erreur de compilation, je préfère de loin planter à l’exécution!

Il existe maintenant des téléphones avec cette super haute densité. Pourriez-vous ajouter les éléments xxxhpi respectifs à votre application, s’il vous plaît? Non, les graphiques vectoriels ne sont pas pris en charge, nous ne le faisons pas ici.

– Monologues avec le SDK Android tard dans la nuit

Graphiques vectoriels

Avant Android 21 (5.0), les graphiques vectoriels appropriés n’étaient tout simplement pas pris en charge. Le raisonnement derrière cela était que la diversité des appareils Android nécessite des graphiques soigneusement ajustés aux besoins de chaque niveau de densité. Naturellement, les développeurs pragmatiques ont créé des outils qui ont transformé mon logo.svg dans un ldpi/logo.png, mdpi/logo.png, hdpi/logo.png, xhdpi/logo.png, xxhdpi/logo.png et bien sûr xxxhdpi/logo.png. Heureusement, Goolge a finalement changé d’avis et nous a bénis VectorDrawable qui prend en charge un sous-ensemble de SVG et a une mauvaise compatibilité descendante. Certes, c’était assez bon pour soulager la douleur à l’époque. Cependant, cela m’empêche de penser qu’un environnement de développement qui se targue de fonctionner sur des configurations de périphériques arbitraires pourrait même exister sans prise en charge des vecteurs pendant si longtemps.

Impasse

Au fil des ans, j’ai commencé à craindre de plus en plus que mes connaissances ne deviennent obsolètes dans un avenir prévisible. La plupart des choses que j’ai apprises étaient très spécifiques à Android et ne sont que rarement applicables dans le domaine plus large du développement logiciel. Compte tenu de ses caprices, je ne crois pas que le développement mobile natif soit là pour durer et j’ai donc commencé à m’inquiéter de l’utilité des compétences que j’avais acquises.

Battement

Lorsque Flutter a été annoncé, je me suis immédiatement excité. Il a promis de résoudre certains des principaux défauts du SDK Android tout en me offrant un support multiplateforme gratuit. Nous avons donc commencé à migrer notre application Android native lors de mon précédent travail vers Flutter. Et je dois dire: Flutter tient sa promesse.

• Les problèmes de fragmentation Android sont complètement éliminés par le pipeline de rendu intégré de Flutter
• Dès le début, il avait une bibliothèque exhaustive de widgets Material Design de haute qualité
• La vivacité de la fonction de rechargement à chaud m’a époustouflé
• Vous bénéficiez d’une expérience multiplateforme sans précédent de haute qualité

Mais malheureusement, tout n’était pas génial. Et c’est dommage car les problèmes dont Flutter souffre auraient pu être facilement évités par un projet entièrement nouveau.

• Dart est terrible: c’est une langue relativement jeune mais elle répète beaucoup d’erreurs de ses prédécesseurs âgés (mauvais système de type, null, des déclarations au lieu d’expressions,…)
• Décisions de conception douteuses dans le SDK Flutter: au lieu de créer un meilleur React, ils ont aggravé la situation. Ce qui aurait pu être un simple appel de fonction a tendance à être résolu par des machines OOP avec état (je rappelle que le routage et la gestion des widgets de dialogue sont particulièrement douloureux ici).

À un moment donné, il était évident pour moi que ce n’est pas le genre de technologie avec laquelle je veux passer mon temps. J’ai juré de ne plus jamais programmer pour les plateformes mobiles. Un site Web bien conçu et réactif vous mène assez loin de nos jours et c’est donc mon option par défaut. Il s’agit d’une seule base de code et fonctionne uniquement sur chaque client. Si je devais absolument créer une application mobile I, je choisirais toujours Flutter, même si je ne visais que Android. Travailler avec le SDK Android est hors de question pour moi.