«To Do» liste avant de publier l’application Android sur le marché

Je suis sur le sharepoint publier ma première application sur le marché Android, et bien que je sois déjà passé par un tas de discussions sur la publication d’applications, j’aimerais savoir si certains d’entre vous ont des conseils sur vos expériences. ont rencontré en ce qui concerne la publication d’une application allant au-delà de l’évidence et déjà documentée.

Toute réserve cachée et / ou toute idée sur ce qu’il faut faire avant de publier une application sur le marché serait grandement appréciée. Par exemple, un de mes amis a recommandé que je supprime tous les commentaires dans mon code au cas où quelqu’un accèderait au code source, ce qui rendrait plus difficile le déchiffrage du code par le prétendu “gestionnaire de code”. Je pensais que c’était une suggestion sensée.

Ce thread ne doit pas être limité aux suggestions de code source. TOUTES les suggestions concernant la publication d’une application sur le marché Android seraient appréciées non seulement par moi, mais par tous les autres utilisateurs qui pourraient publier leur première application sur le marché et faire des recherches sur ce sujet.

Je n’aurais jamais été aussi loin en si peu de temps sans l’aide de cette communauté. Je serai toujours reconnaissant pour toute l’aide que j’ai reçue de votre part.

    J’espère que ce n’est pas trop tard, voici quelques conseils:

    • Lancez votre application à la fin de la semaine (le jeudi après-midi est généralement un bon moment). Pourquoi donc Eh bien, aucune entreprise ne souhaite publier une application seulement 1,5 jour avant le week-end -> trop dangereux (en cas de problème nécessitant une réaction rapide).

    • Utilisez proguard sur votre application (il suffit généralement d’append cette ligne: proguard.config=proguard.cfg dans le fichier default.properties ). Cela optimisera, réduira et obscurcira votre code, très utile pour empêcher les voleurs de code. Vous n’êtes pas obligé de supprimer des commentaires, ils sont automatiquement supprimés au moment de la compilation.

    • Optimisez vos images (en utilisant Paint.NET , PNGCrush ou OptiPNG ).

    • Optimisez vos dispositions pour la plupart des tailles d’écran. Vous pouvez le faire simplement en modifiant la taille de l’écran lors de l’édition d’une mise en page dans AndroidStudio ou Eclipse.

    • Essayez / attrapez toutes les exceptions sur l’interface utilisateur et affichez un simple toast qui indique à l’utilisateur que quelque chose ne s’est pas passé. En attendant, récupérez l’erreur avec Crashlytics ou quelque chose de similaire.

    • N’utilisez pas trop de bibliothèques .jar, préférez les projets de bibliothèque (optimisez la taille du code) et ajoutez-les à l’aide de gradle.

    • Préférez utiliser des images vectorielles, car cela réduira la taille de l’APK et s’adaptera correctement sur tous les appareils.

    • N’utilisez pas les fenêtres de préférences Android -> ce n’est pas vraiment beau, même si c’est dans les directives Android, préférez faire votre propre page de parameters. Mais si vous gardez les préférences Android: pensez à append des icons et des couleurs.

    • Ne pas afficher le titre de votre application sur l’écran principal ( this.requestWindowFeature(Window.FEATURE_NO_TITLE); ): les bonnes marques n’ont pas besoin de prendre autant de place sur un écran pour afficher une icône ou un titre. menu ou quelque part qui n’est pas toujours visible), et envisagez d’utiliser le mode plein écran ( this.getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN); ) lorsqu’il s’agit de jeux et de contenu très immersif.

    • Utilisez Google Analytics , Fabric Answers ou Flurry pour des parsings ultérieures -> essayez d’obtenir autant d’informations que possible, mais ne saisissez rien qui porte atteinte à l’identité anonyme du client. N’oubliez pas de récupérer les exceptions (erreurs et traces de stack) qui se produisent du côté utilisateur.

    • Demandez à vos amis de faire des tests sur les singes, apprendre des utilisateurs apporte généralement beaucoup de bonnes choses (comme des priorités et de nouvelles idées).

    • Pensez à publier votre application avant d’avoir terminé toutes les fonctionnalités (fonctionnalité la plus importante uniquement), vous ne savez pas encore ce que vos utilisateurs voudront ou auront besoin en plus de votre fonctionnalité principale.

    • Ajoutez une section “Plus d’applications” ou “Plus du développeur” dans votre application, c’est-à-dire des annonces gratuites.

    • Ajoutez une section “Envoyer des commentaires” pour donner à l’utilisateur la possibilité de demander une nouvelle fonctionnalité ou de signaler un bogue.

    • Demandez à vos utilisateurs de traduire votre application en fournissant le fichier ssortingngs.xml quelque part sur le Web comme Crowdin .

    • Essayez votre application sur chaque version Android avec l’émulateur -> de nombreux bogues ou problèmes de conception seront détectés de cette manière. Pour cela, vous pouvez utiliser l’émulateur fourni ou utiliser Genymotion à la place (Genymotion possède de nombreuses fonctionnalités très utiles).

    • Pensez au nom de l’application -> quels mots clés utiliseriez-vous pour rechercher votre application? Ces mots-clés doivent être le nom de votre application (Google vous aidera à être découvert de cette façon).

    • Envisagez d’inclure des mots-clés dans la description de l’application, mais de manière descriptive (créez des phrases compréhensibles à l’aide de vos mots-clés). N’ajoutez jamais une liste de mots clés comme dans la description.

    • Soyez le premier à évaluer votre application avec 5 écanvass et demandez à votre famille et à vos amis de faire de même -> cela influera probablement sur les évaluations des futurs utilisateurs.

    • Pensez à utiliser Google pour traduire votre application soit pour la description, soit pour le fichier ssortingngs.xml ou les deux.

    • Pensez à afficher des annonces dans vos applications et à utiliser la médiation pour améliorer vos revenus AdMob .

    • Au lieu de fournir une version payante, envisagez de faire la facturation intégrée aux applications -> les utilisateurs sont plus enclins à payer dans l’application plutôt que de payer pour une version payante.

    • Ajouter un journal des modifications dans l’application -> les utilisateurs aiment généralement savoir ce qui a changé depuis la dernière version.

    • Ajoutez une section “Merci” pour les utilisateurs qui vous ont aidé -> cela impliquera les utilisateurs dans votre produit.

    • Ajouter un lien “Si vous aimez cette application, veuillez le noter” (à votre description Google Play) dans votre application -> vous obtiendrez plus de 5 écanvass (généralement une fenêtre contextuelle au démarrage ou après une action de fonctionnalité).

    • Pensez à expliquer votre produit via une section “Conseils” ou “Instructions” dans votre application.

    • Enregistrez vos informations de magasin de clés et d’informations d’identification dans un endroit sûr. Vous ne pourrez pas publier une mise à jour pour votre application si vous perdez votre fichier de clés.

    • Rendez votre icône vraiment simple et claire. L’icône est la première et surtout la dernière chose qui incitera l’utilisateur à télécharger votre application.

    • À moins que ce ne soit pas possible, préférez l’installation externe ( android:installLocation="preferExternal" dans le fichier AndroidManifest.xml).

    • Lisez les conseils AppAnnie et les billets de blog, il vous donnera des conseils sur la façon d’améliorer ASO et vous aidera à mieux comprendre vos utilisateurs.

    Vraiment, ne vous souciez pas de supprimer les commentaires de code. Votre code source ne parvient pas au téléphone de l’utilisateur – seul le code compilé y parvient, et cela ne contient aucune référence à vos commentaires.

    Les utilisateurs d’Android ont tendance à apprécier les applications aussi petites que possible. Vérifiez donc que vous n’incluez que les ressources (images, etc.) encore utilisées dans votre application. Utilisez OptiPNG / PNGCrush sur toutes les images .png de votre application – ce qui peut réduire la taille des fichiers image d’environ 10%, ce qui peut représenter une partie importante de la taille globale de votre application.

    Utilisez également un éditeur audio tel que Audacity pour réduire autant que possible la taille de l’audio. Choisir les fichiers mono OGG Vorbis est souvent la meilleure solution et sonne suffisamment bien sur un téléphone.

    Ne vous inquiétez pas des commentaires. Si vous êtes préoccupé par la dissection malveillante de votre application, exécutez-la via un obfuscateur tel que ProGuard.

    Autres conseils que je proposerais:

    • Ayez tous vos graphiques et votre matériel promotionnel prêts à l’avance.
    • Réglez votre libération de manière stratégique pour ne pas avoir beaucoup de choses à faire dans votre vie (comme juste avant un week-end) afin que vous ayez le temps de répondre RAPIDEMENT si les premiers utilisateurs commencent à avoir des problèmes. Des notes faibles dès le départ peuvent vous tuer, mais une réponse et des corrections rapides par courrier électronique peuvent totalement utiliser l’opinion d’un client sur votre application.
    • Je suis d’accord avec les commentaires précédents sur la réduction de la taille des images autant que possible.
    • Obtenez votre code dans le contrôle de source si ce n’est pas déjà fait. Vous devez être sûr de devoir publier des mises à jour et des correctifs à un moment donné, et le contrôle des sources peut y jouer un rôle important.

    Vous ne savez pas si vous avez déjà vu cela, mais vous devriez exercer votre interface utilisateur avec le singe – mon application n’a subi qu’un seul plantage, mais elle n’aurait eu aucun problème si je l’avais d’abord testé avec Monkey.

    J’appendai une évidence, mais importante: enregistrez votre clé de signature dans un endroit sûr et effectuez une sauvegarde. Si vous laissez Eclipse gérer cela pour vous, faites attention à l’endroit où il crée votre fichier de clés et enregistrez une copie de sauvegarde. Et n’oubliez pas les mots de passe pour le fichier de clés ou les clés de signature individuelles.

    Pourquoi: vous devez signer les mises à jour de votre application avec le même certificate que celui que vous avez utilisé pour signer l’original. Si vous perdez ce certificate (ou y perdez l’access), vous ne pouvez pas mettre à jour votre application. Vous devrez créer une nouvelle liste sur le marché Android.

    Quelques points que j’ai tendance à oublier:

    • vérifiez votre minSdkVersion dans le manifeste
    • testez votre application sur un émulateur avec votre minSdkVersion
    • laissez vos amis tester votre application pour voir si elle est explicite

    Si vous envisagez de fournir des mises à jour dans votre application:

    • vous pourriez vouloir append une sorte de ‘Quoi de neuf dans cette boîte de dialog’
    • sauvegarder votre ancienne version!
    • N’oubliez pas d’augmenter versionCode et versionName dans votre manifeste

    N’oubliez pas de rendre debuggable = false dans votre manifeste. Cela m’a attiré plusieurs fois.

    Je ne suis pas tout à fait sûr mais je pense que cela inclurait alors beaucoup d’informations rendant la vie des pirates de code un peu plus facile.

    Je me rappelle il y a des années j’ai accidentellement supprimé la source d’un projet java, dans l’horreur j’ai réalisé que je n’avais aucune sauvegarde! J’ai utilisé un utilitaire appelé jad pour décomstackr le fichier jar sur le serveur de production, il contenait toutes les variables et était presque parfait. Je ne me souviens plus si les commentaires étaient là ou non, mais je n’ai pas mis beaucoup de commentaires de toute façon 🙂 C’est parce que j’avais inclus des symboles lors de la compilation.

    En plus des excellentes suggestions ci-dessus, pensez à utiliser Flurry pour les parsings mobiles. Je ne savais pas à ce sujet quand j’ai commencé à sortir mes applications, mais maintenant que je les ai mises à jour pour les inclure, j’adore voir ce que les utilisateurs font réellement avec l’application. Cela peut fournir des informations et des conseils précieux sur les éléments que les utilisateurs pourraient trouver difficiles à trouver ou non intéressants pour l’utilisateur.

    Autant que je sache, les commentaires ne sont pas inclus dans l’application sous aucune forme.

    Le seul “gotcha” pour un développeur que j’ai trouvé lors de la soumission de l’application était les différents graphiques que vous pouvez fournir au marché. Préparez-vous à prendre plusieurs captures d’écran et à créer plusieurs tailles d’icons d’application ainsi que des graphiques promotionnels.

    Sur le plan positif, préparez-vous à ce que votre application apparaisse instantanément dans le magasin – il n’y a pas de processus d’approbation pour les applications Android Market.

    Je m’assurerais également que vous disposiez d’une sorte de rapport d’erreur afin de savoir combien d’utilisateurs rencontrent des erreurs. Vous souhaiterez peut-être conserver une copie de votre ancienne version lors de la mise à jour de votre application si vous devez la restaurer. Il est également intéressant de comstackr une liste de contrôle spécifique à votre application que vous pouvez consulter à chaque fois.

    Pour append à cela, vous pouvez utiliser un taille-bordure pour retirer des morceaux de code inutilisés afin de réduire la taille globale du fichier (car l’espace téléphonique est assez limité). Vous pouvez également vouloir masquer votre code pour une protection supplémentaire.

    Pour avoir une idée claire .. aller à travers .. http://bewithandroid.blogspot.in/2012/05/publishing-android-application-on.html

    Déclarez un atsortingbut android:process et android:sharedUserId !

    Voir sharedUserId: sûr à changer lorsque l’application est déjà sur le marché? pour quoi.