Comment préparer votre code d'application Android pour la publication sur le Google Play Store

À ce stade, vous êtes probablement fatigué de regarder votre propre application. Vous avez écrit l'application Android de base, testé l'application, corrigé les bugs, testé à nouveau, ajouté des fonctionnalités, fait plus de tests, resté éveillé tard dans la nuit, et fait encore plus de tests. Mais si vous envisagez de publier votre application, voici un conseil: Après avoir terminé vos tests, en tester d'autres.

Demandez-vous quelles séquences de boutons vous avez évitées de cliquer lorsque vous avez effectué vos tests «approfondis». Puis rassembler le courage de cliquer sur les boutons et utiliser les widgets dans ces séquences étranges. Et pendant que vous y êtes, inclinez l'appareil sur le côté, retournez l'appareil, tenez l'appareil au-dessus de votre tête et essayez d'utiliser l'application. Si votre appareil est un téléphone, interrompez l'application avec un appel entrant.

Avez-vous terminé les tests? Pas encore. Demandez à vos amis de tester l'application sur leurs appareils. Quoi que vous fassiez, ne leur donnez pas d'instructions autres que les instructions que vous avez l'intention de publier. Mieux encore, ne leur donnez même pas les instructions que vous avez l'intention de publier. (Certains utilisateurs ne liront pas ces instructions de toute façon.) Demandez à vos amis s'ils ont déjà utilisé votre application. Si vous sentez que vos amis sont trop polis, appuyez dessus pour plus de détails.

Dé-test de l'application

Lorsque vous testez une application, vous trouvez des fonctionnalités qui ne fonctionnent pas vraiment. Vous vérifiez les journaux et vous ajoutez probablement du code pour vous aider à diagnostiquer les problèmes. Lorsque vous vous préparez à publier votre application, supprimez tout code de diagnostic inutile, supprimez les instructions de journalisation supplémentaires et supprimez tout autre code dont l'objectif est de bénéficier au développeur plutôt qu'à l'utilisateur.

Lors du développement de votre application, vous avez peut-être créé des données de test. (Y a-t-il un canard nommé "Donald" dans la liste de contacts de votre application?) Si vous avez créé des données de test, supprimez les données de votre application.

Vérifiez le AndroidManifest de votre projet. fichier xml. Si l'élément possède un attribut android: debuggable = "true", supprimez cet attribut. (La valeur par défaut de l'attribut est false.)

Choix des versions Android

Lorsque vous créez un nouveau projet, Android Studio vous demande une version minimale du SDK. La construction de votre projet. Le fichier gradle garde un enregistrement de votre choix dans son champ minSdkVersion. Vous pouvez changer ce nombre en éditant la construction. fichier gradle.

Ce numéro minSdkVersion est important car il ne doit pas être trop bas ou trop élevé.

• Si le numéro minSdkVersion est trop bas, votre application n'utilise pas les fonctionnalités des versions Android récentes.

  Si votre application est très simple, c'est bon. Mais si votre application fait quoi que ce soit de différent dans les nouvelles versions d'Android, le look vintage de votre application peut désactiver les utilisateurs.

• Si le numéro minSdkVersion est trop élevé, le Play Store n'offre pas votre application aux utilisateurs disposant d'appareils plus anciens.

  En fait, si la version minSdkVersion de votre application est 21, un utilisateur qui visite le Play Store sur un appareil KitKat ne voit même pas votre application. (Vous avez peut-être déjà rencontré le message d'erreur INSTALL_FAILED_OLDER_SDK: Android Studio ne peut pas installer une application sur l'émulateur que vous avez sélectionné car la version du SDK de l'émulateur est inférieure à minSdkVersion de l'application.)

  Vous ne souhaitez pas supprimer les utilisateurs parce qu'ils n'ont pas les derniers et les meilleurs appareils Android. Donc, pour atteindre plus d'utilisateurs, gardez minSdkVersion d'être trop haut. Si votre application n'utilise aucune fonctionnalité introduite après API Niveau 11, définissez votre minSdkLevel sur 11.

Essayez d'exécuter votre application sur des émulateurs disposant de nombreux niveaux d'API. Lorsque vous rencontrez des problèmes (par exemple, sur un émulateur avec le niveau d'API 10), définissez minSdkLevel de votre projet sur quelque chose de plus élevé que ce niveau gênant.

Lorsque vous créez un nouveau projet, la boîte de dialogue Target Android Devices contient un lien Help Me Choose. Lorsque vous cliquez sur ce lien, vous voyez un graphique indiquant le pourcentage de périphériques exécutant Lollipop, KitKat, Jelly Bean et d'autres versions d'Android. Ce tableau cliquable décrit les fonctionnalités de chaque version Android et (plus important encore) montre le pourcentage de périphériques qui exécutent chaque version. Avec les informations de ce graphique, vous pouvez choisir le meilleur compromis entre les dernières fonctionnalités et le plus large public d'utilisateurs.

Les bibliothèques de support d'Android permettent aux appareils dotés de versions Android plus anciennes de tirer parti des nouvelles fonctionnalités Android.

Définition du code de version et du nom de version de votre application

Lorsque vous créez un nouveau projet, Android Studio met des attributs par défaut dans votre build. fichier gradle. Ces attributs incluent les champs versionCode et versionName:

defaultConfig {… versionCode 1 versionName "1. 0 "}

Le code de version doit être un entier, et les numéros de code de votre application doivent augmenter au fil du temps. Par exemple, si votre première version publiée a le code de version 42, votre deuxième version publiée doit avoir un code de version supérieur à 42.

Les utilisateurs ne voient jamais le code de version. Au lieu de cela, les utilisateurs voient le nom de la version de votre application. Vous pouvez utiliser n'importe quelle chaîne pour le nom de version de votre application. De nombreux développeurs utilisent la version majeure. mineur-libération. système de points. Par exemple, un nom de version typique peut être 1. 2. 2. Mais il n'y a pas de restrictions. Android a tous les noms de dessert, et Apple utilisait des noms de chat jungle, donc vous pouvez ajouter quelque chose comme

versionNom "jet d'eau"

à ma construction. fichier gradle. (Regardez-le!)

Si vous avez l'intention de publier sur l'Amazon Appstore, n'utilisez pas de phrases comme «sea squirt» pour votre versionName. L'Amazon Appstore insiste sur un nom de version comprenant jusqu'à cinq entiers séparés les uns des autres par des points.Par exemple, les valeurs versionName telles que 2. 30 et 1. 2. 0. 325. 0 fonctionnent très bien.

Choisir un nom de paquet

Chaque application Android a son propre nom de paquet. Donc, si votre première application publiée est dans le com. Exemple. package winmeamillion, mettez votre deuxième application dans un com. Exemple. paquet secondtimeisacharm.

Votre nom de package devrait vous aider à vous identifier ou identifier votre entreprise. Si vous avez un nom de domaine, démarrez le nom du paquet avec les pièces du nom de domaine inversées!