juste curieux quant à la pratique standard pour écrire une nouvelle application.
Écrivez-vous votre code pour en prendre en charge tout le chemin de l'API 15 (Android 4) et essayez de prendre en charge essentiellement toutes les plateformes Android là-bas? Ou est-ce surtout "code pour la plus récente et si quelqu'un se plaint, additionnelle de soutien"?
J'utilise le Java.Time Lib et je trouve que ce n'est disponible que dans Java API 26 (Android 8). Devrais-je simplement utiliser cela directement? Ou inclure le code pour vérifier la version des téléphones et ajouter un code pour ces anciennes versions?
merci!
3 Réponses :
Si vous allez créer une application pour les versions Android 8 et les plus récentes, vous ne couvrez que 30% d'appareils Android pour le moment.
Vous pouvez vérifier le tableau de bord du développeur pour la distribution des périphériques: Dessin de développement
Au début, vous pouvez vous concentrer sur le développement de l'application pour les périphériques plus récents et écrire un code de défilement pour les appareils plus anciens plus tard.
Cela dépend également de qui sont vos utilisateurs cibles.
Bon! Ce tableau de bord est ajouté à ma barre de favoris maintenant. Merci.
Si je peux supporter une version antérieure en évitant l'utilisation d'une commodité mineure ajoutée dans les versions ultérieures, je supporterai généralement les anciennes versions sans une seconde pensée. Un moyen pratique d'approcher ceci est de définir votre version SDK minimale sur quelque chose même plus bas que vous ne le pensez peut-être que vous pourriez vouloir prendre en charge et augmenter progressivement lorsque vous rencontrez des raisons de le faire. J'ai besoin d'une raison impérieuse pour soutenir des versions plus anciennes si cela nécessite une quantité importante de travail supplémentaire.
connais votre public cible.
Le tableau de bord du développeur est utile, mais ce n'est pas tout. Je travaille sur une application maintenant que je m'attends à être utilisée sur de vieux téléphones à la retraite que les gens se sont dédiés à un passe-temps spécifique. C'est un exemple de raison impérieuse de soutenir les anciennes versions Android. J'ai également travaillé sur une application qui devait prendre en charge Android 2.1 (lorsque 6.0 était en cours) parce que les clients qui l'utilisent avaient un investissement important dans l'ancien matériel.
Merci pour votre contribution. Je me penchais vers ces pensées aussi. La réponse peut être extrêmement dépendante sur le public de l'application particulière à coup sûr.
Je pense que Android 4 soutient déjà beaucoup. Je travaille actuellement sur une demande de lanceur et j'ai eu 0 numéros de tout l'appui de l'API Version 14 et de la version.
Lorsque vous avez vraiment besoin d'une version d'API supérieure pour une fonction / une bibliothèque spécifique, je vous recommanderais de choisir 5 ou 6, ils supportent également un pourcentage assez élevé d'appareils (voir le lien pour la source).
Mais je pense que le plus grand nombre de développeurs que possible devraient supporter des appareils plus anciens. À la plupart des fins Les anciens téléphones Android sont déjà assez rapides. Si plus de développeurs soutiendraient des téléphones (et des appareils plus anciens), ils ne seraient pas largués dans des tiroirs si rapides (c'est juste un gaspillage). Dans mon expérience, rien de plus que le logiciel est responsable de ce comportement (Windows Phone est-il un bon exemple de ce qui manque de logiciel peut faire à A - à mon avis - très bon système d'exploitation?).
Android 4.0 est mon minimum cependant, aller plus bas me demanderait beaucoup plus de temps.
Pour Java.Time, jetez un coup d'œil à github.com/jakewharton/threetenabp
Voir développeur.android.com/about/drashboards . En règle générale, je recommanderais d'écrire pour API 21+ en ce moment, car il est le premier à prendre en charge de manière native vectorielle.