Meilleures pratiques de programmation asynchrone

• Utiliser des variables globales

Si vous ne voulez pas gâcher votre code avec de simples Intent.putExtra() et gérer ces choses pour chaque Activity unique, vous devez utiliser des variables globales dans l’application. Étendez l’ Application et stockez les données dont vous avez besoin tant que votre application est active. Pour l’implémenter, utilisez cette excellente réponse . Cela fera disparaître les dépendances entre les activités. Par exemple, supposons que vous ayez besoin d’un “nom d’utilisateur” pour votre application pendant le cycle de vie de l’application – c’est un excellent outil pour cela. Pas besoin d’appels Intent.putExtra() sales.

• Utiliser des styles

Une erreur fréquente lors de la première application Android est que l’on commence généralement par écrire les vues XML. Les fichiers XML vont (sans problème et très rapidement) atteindre de très nombreuses lignes de code. Ici vous pouvez avoir une solution où vous utilisez simplement l’atsortingbut de style pour implémenter un comportement spécifique. Par exemple, considérons ce morceau de code:

values ​​/ styles.xml :

layout / main.xml :

Maintenant, si vous avez, disons, deux TextView et que les deux devraient avoir le même comportement, faites-leur utiliser le style TitleText . Exemple de code:

Simple et vous n’avez pas besoin de dupliquer le code. Si vous souhaitez vraiment approfondir ce sujet particulier, consultez les astuces de mise en page: création de composants d’UI réutilisables .

• Utiliser des chaînes

Ce point est court mais je pense qu’il est important de le mentionner. Une autre erreur que les développeurs pourraient faire est d’ignorer le fichier ssortingngs.xml et d’écrire des messages d’interface utilisateur (et des noms d’atsortingbuts) dans le code (où il en aura besoin). Pour faciliter la maintenance de votre application; Il suffit de définir les messages et les atsortingbuts dans le fichier ssortingngs.xml .

• Créer et utiliser une classe d’outils globale

Lorsque j’ai écrit ma première application, j’ai simplement écrit (et dupliqué) les méthodes là où j’en avais besoin. Le résultat? Beaucoup de méthodes ayant le même comportement entre différentes activités. Ce que j’ai appris est de créer une classe d’outils. Par exemple, supposons que vous deviez faire des requêtes Web dans toutes vos activités. Dans ce cas, ignorez leur définition dans l’ Activity réelle et créez une méthode statique pour celle-ci. Exemple de code:

 public final class Tools { private Tools() { } public static final void sendData(Ssortingng url, Ssortingng user, Ssortingng pass) { // URLConnections, HttpClients, etc... } } 

Maintenant, vous pouvez simplement utiliser ce code ci-dessous dans votre Activity qui doit envoyer des données vers un serveur:

 Tools.sendData("www.www.www", "user", "pass"); 

Cependant, vous obtenez le point. Utilisez ce “pattern” là où vous en avez besoin , cela vous évitera de rater votre code.

• Laissez les classes personnalisées définir le comportement dans lequel l’utilisateur doit interagir avec votre application

C’est probablement le point le plus utile. Pour définir simplement ” où l’utilisateur doit interagir avec votre application “, supposons que vous ayez un Menu dont le comportement est très long en termes de lignes, pourquoi conserve-t-on les calculs du Menu dans la même classe? Chaque petit article fera de votre classe d’ Activity un morceau de code douloureux – votre code ressemble à un “spaghetti”. Par exemple, au lieu d’avoir quelque chose comme ça:

 @Override public boolean onPrepareOptionsMenu(Menu menu) { MenuItem item; item = menu.findItem(R.id.menu_id_one); if (aBooleanVariable) { item.setEnabled(true); } else { item.setEnabled(false); } // More code... return super.onPrepareOptionsMenu(menu); } @Override public boolean onOptionsItemSelected(MenuItem i) { // Code, calculations... // ... // ... return super.onOptionsItemSelected(i); } 

redesignez-le à quelque chose comme ça:

 private MyCustomMenuInstance mMenuInstance; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); mMenuInstance = new MyCustomMenuInstance(); } @Override public boolean onPrepareOptionsMenu(Menu menu) { mMenuInstance.onPrepareOptionsMenu(menu); return super.onPrepareOptionsMenu(menu); } @Override public boolean onOptionsItemSelected(MenuItem i) { mMenuInstance.onOptionsItemSelected(i); return super.onOptionsItemSelected(i); } 

Par exemple, MyCustomMenuInstance :

 public class MyCustomMenuInstance { // Member fields.. public MyCustomMenuInstance() { // Init stuff. } public void onPrepareOptionsMenu(Menu menu) { // Do things.. // Maybe you want to modify a variable in the Activity // class? Well, pass an instance as an argument and create // a method for it in your Activity class. } public void onOptionsItemSelected(MenuItem i) { // Do things.. // Maybe you want to modify a variable in the Activity // class? Well, pass an instance as an argument and create // a method for it in your Activity class. } } 

Vous voyez où cela se passe. Vous pouvez appliquer cela à beaucoup de choses, par exemple onClick , onClickListener , onCreateOptionsMenu , la liste est longue. Pour en savoir plus sur les “meilleures pratiques”, vous pouvez voir des exemples d’applications de Google ici . Cherchez comment ils ont mis en œuvre les choses de manière correcte et correcte.

Dernier mot; gardez votre code propre, nommez vos variables et méthodes de manière logique et surtout correcte. Toujours, toujours comprendre où vous êtes dans votre code – c’est très important.

D’un sharepoint vue amateur, je ne m’attends pas à ce que ma première tentative soit une application propre et prête pour la production. Je me retrouve parfois avec des spaghettis, des fettucinis et même des codes raviolis. À ce stade, j’essaie de repenser à ce que je déteste le plus du code et à rechercher une meilleure alternative:

• Repensez vos classes pour mieux décrire vos objects,
• garder le code dans chaque méthode au minimum,
• éviter les dépendances aux variables statiques partout où vous le pouvez,
• utiliser des threads pour des tâches coûteuses, ne les utilisez pas pour des procédures rapides,
• séparer l’interface utilisateur de la logique d’application (conservez-la dans vos classes à la place),
• conserver des champs privés partout où vous le pouvez: cela vous sera utile lorsque vous souhaitez changer de classe,
• itérer à travers ces jusqu’à ce que vous aimez le code

L’une des erreurs les plus courantes que j’ai vues dans les méthodes asynchrones est d’utiliser une variable statique dans une boucle qui crée un ou plusieurs threads, sans considérer que la valeur peut changer dans un autre thread. Évitez la statique!

Comme le souligne OceanBlue, il n’est pas évident que final static variables final static ne créent aucun danger, mais les variables statiques publiques peuvent changer. Ce n’est pas un problème avec les statiques elles-mêmes, mais avec l’idée qu’elles auront une valeur et ensuite découvriront que la valeur a changé. Il peut être difficile de repérer le problème. Des exemples typiques seraient un compteur de clics ou une valeur de timer, lorsqu’il pourrait y avoir plusieurs clics cliqués ou plus d’un minuteur.

J’espère que vous recevrez des suggestions de personnes avec beaucoup plus d’expérience que moi. Bonne chance!

Si la manipulation de l’interface utilisateur est votre principale préoccupation, vous souhaiterez maîsortingser le codage piloté par les événements. Les idées derrière le codage piloté par les événements sont derrière tous les systèmes d’interface utilisateur modernes et sont utiles dans toutes sortes de choses (pas seulement l’interface utilisateur).

Le moyen le plus simple pour moi d’y penser lors de l’apprentissage était simplement de traiter chaque composant et chaque événement comme s’il était autonome. Tout ce dont vous avez besoin est l’object d’événement transmis dans votre méthode d’événement. Si vous avez l’habitude d’écrire des applications qui s’exécutent essentiellement du début à la fin, c’est un peu un changement de mentalité, mais la pratique vous y conduira assez rapidement.

Qu’en est-il de l’utilisation du modèle Controller View?

Au moins vous devez isoler dans le “modèle” (object ou ensemble d’objects) tout l’état et sa gestion logique, et avoir dans une classe distincte (peut-être la classe d’activité) tous les éléments liés aux vues, aux écouteurs, aux rappels, …)