Quels sont les équivalents Android de l’application iOS  » Life Cycle  » pour le suivi automatique du temps passé dans les activités quotidiennes (sommeil, exercice, travail/étude, déplacements, socialisation, navigation, etc.), à partir des seules données et de la localisation de votre téléphone portable et non d’un wearable ? Artboard


Version courte : Parce que développer pour Android, ça craint. Je viens récemment d'implémenter une fonctionnalité dans une application à la fois pour iOS et Android. Sur iOS, cela m'a pris 23 lignes de code et quelques minutes. Sur Android, cela m'a pris 567 lignes de code et 3 jours.

Version longue : Tout d'abord, permettez-moi de dire que les autres réponses qui parlent du peu d'argent qu'il y a dans Android sont au moins partiellement vraies, mais (pour moi personnellement) ce n'est pas aussi désastreux qu'elles le laissent entendre. Je fais une quantité non triviale d'argent avec mes applications Android, mais je fais plus du double de ce montant sur mes applications iOS.


Mais pour en venir au point principal... Android est nul. Je sais que cela ressemble à un argument religieux, mais soyez indulgent avec moi.

Pour être clair, en tant qu'utilisateur d'Android, vous ne vivrez probablement jamais quelque chose qui vous fera penser qu'Android est nul. Cependant, être un développeur Android est misérable parce que l'AndroidOS sous-jacent est des générations derrière iOS.


Apple travaille diligemment pour qu'iOS fonctionne très bien ET soit beau en même temps. Beaucoup des morceaux de bonbons visuels qu'Apple inclut dans iOS aident réellement à l'utilisabilité, ils ne sont pas juste pour le spectacle. Ils communiquent subtilement des informations à l'utilisateur pour qu'il comprenne ce qui se passe et pourquoi les choses se passent.

Cependant, Google s'est principalement concentré sur le simple fait de faire fonctionner les bases d'Android parce qu'ils valorisaient l'idée d'une expression individuelle des développeurs, par opposition à Apple qui voulait que les apps aient un look et une sensation cohérents. (Le problème est que la grande majorité des développeurs n'ont pas été formés à l'ergonomie ou à la conception graphique et que, par conséquent, leurs applications étaient grossières et ne fonctionnaient pas correctement. À l'époque d'Android 4.x, Google s'est rendu compte qu'il y avait un réel problème car chaque application Android fonctionnait de la même manière, chaque développeur ayant une approche différente. Ils ont commencé à essayer de standardiser l'interface utilisateur et ils ont demandé à certains de leurs graphistes d'essayer de rendre les éléments visuels plus jolis. Ce n'était toujours pas génial.

Voici un exemple précis de la différence d'effort du point de vue du développeur. J'ai une fonctionnalité dans l'une de mes applications iOS et je voulais m'assurer que cette fonctionnalité se trouvait également dans la version Android.

La fonctionnalité consiste à tapoter + maintenir un élément dans une liste/tableau, puis à le faire glisser vers le haut ou vers le bas pour réorganiser les éléments du tableau (drag and drop). Dans iOS, cela ne m'a pris que 23 lignes de code car essentiellement tout est déjà intégré au système iOS sous-jacent. L'objet UITableView (les listes déroulantes que l'on voit partout dans iOS) sait déjà comment répondre au tapotement et au maintien et sait déjà comment animer le déplacement de la ligne lorsque vous faites glisser votre doigt... et applique déjà une belle ombre portée lorsque vous faites glisser la ligne... et sait déjà comment animer les autres lignes du tableau pour qu'elles s'écartent lorsque vous faites glisser cette ligne, etc. Il a aussi déjà des crochets intégrés pour que le système puisse demander à mon code : L'utilisateur doit-il être autorisé à faire glisser cette ligne ? L'utilisateur peut-il déposer cette rangée entre x et y ? " et il me dira L'utilisateur vient de faire glisser et de déposer cette rangée à ce nouvel emplacement, ce qui permet à mon code de répondre à cet événement.

C'est pourquoi mon code iOS ne fait que 23 lignes. Tout ce que j'ai à faire, c'est d'écrire du code qui dit quelles rangées sont glissables, puis de répondre à leur dépôt de la rangée afin que je puisse mettre à jour les données sous-jacentes. J'ai implémenté cette fonctionnalité en quelques minutes sur iOS.

Mais Android ne fait RIEN de tout cela, ce qui explique pourquoi mon code Android fait 567 lignes et qu'il m'a fallu 3 jours pour que tout fonctionne. Heureusement, dans ce cas particulier, je n'ai pas eu à écrire tout ce code moi-même parce que TELLEMENT d'autres développeurs Android s'étaient plaints de manquer cette fonctionnalité incroyablement basique. En réponse, Google avait publié un "exemple de code" qui montrait comment créer manuellement une forme rudimentaire de glisser/déposer. Bien sûr, ce code était obsolète car il avait été écrit pour Android 4 et ne fonctionnait pas pour Android 5, 6 ou 7 (7.x est la version actuelle au moment où nous écrivons ces lignes).

Et leur exemple de code n'impliquait aucune fonctionnalité pour vérifier si certaines lignes de la liste/table devaient être autorisées à être glissées. Il n'incluait pas de vérification si une rangée devrait être autorisée à être déposée à un certain endroit. Il ne permettait pas de définir une fonction de rappel pour que votre code puisse réagir à la réorganisation. J'ai dû prendre tout leur code rudimentaire et bogué et essayer de l'améliorer pour qu'il fasse plus que la version maternelle de la fonctionnalité.

Cela signifie que j'ai passé plusieurs jours pour produire une fonctionnalité qui ne fonctionne même pas aussi bien ou n'a pas l'air aussi bien que la fonctionnalité qui existe déjà dans iOS et qui ne m'a pris que quelques minutes. J'ai pris une capture d'écran du code des deux et les ai placés côte à côte afin de pouvoir l'utiliser pour expliquer la différence. (voir ci-dessous. La capture d'écran inclut les commentaires dans le code, mais je n'ai pas compté les commentaires dans mon décompte de lignes.)

Chaque fois que j'ai un client qui veut son application à la fois sur iOS et sur Android, je lui dis que la version Android prendra 4 fois plus de temps à produire et ne sera qu'environ 80 % aussi bonne. Lorsque je leur donne le devis, je détermine combien l'application iOS prendra à produire, puis je multiplie ce nombre par 2,5 pour couvrir la version Android... ce qui ne paie pas -vraiment- tout le temps que j'ai passé sur la version Android, mais facturer 4 fois le montant leur semble ridicule parce qu'ils ne savent pas ce que c'est.

main-qimg-12ad56552025675895206aaa93641f54.webp