Comment déclarer des variables globales dans Android?

j'ai écrit cette réponse en '09 quand Android était relativement nouveau, et il y avait beaucoup de domaines pas bien établis dans le développement Android. J'ai ajouté un long addendum au bas de ce post, abordant certaines critiques, et détaillant un désaccord philosophique que j'ai avec l'utilisation de Singletons plutôt que l'application de sous-classification. Lire à vos risques et périls.

RÉPONSE ORIGINALE:

Le problème plus général vous rencontrez est de savoir comment sauvegarder l'État à travers plusieurs activités et toutes les parties de votre application. Une variable statique (par exemple, une singleton) est une méthode Java courante pour y parvenir. J'ai trouvé cependant, qu'une façon plus élégante dans Android est d'associer votre état avec le contexte de l'Application.

comme vous le savez, chaque activité est aussi un contexte, c'est-à-dire une information sur son environnement d'exécution au sens le plus large. Votre demande a également un contexte, et Android garantit qu'il existera en tant qu'instance unique à travers votre application.

la façon de faire ceci est de créer votre propre sous-classe de android.App.Application , puis préciser cette classe dans l'étiquette d'application de votre manifeste. Maintenant Android va automatiquement créer une instance de cette classe et la rendre disponible pour l'ensemble de votre application. Vous pouvez y accéder à partir de n'importe quel context en utilisant la méthode Context.getApplicationContext() ( Activity aussi fournit une méthode getApplication() qui a exactement le même effet). Voici un exemple extrêmement simplifié, avec les mises en garde suivantes:

class MyApp extends Application {

  private String myState;

  public String getState(){
    return myState;
  }
  public void setState(String s){
    myState = s;
  }
}

class Blah extends Activity {

  @Override
  public void onCreate(Bundle b){
    ...
    MyApp appState = ((MyApp)getApplicationContext());
    String state = appState.getState();
    ...
  }
}

cela a essentiellement le même effet que l'utilisation d'une variable statique ou singleton, mais s'intègre assez bien dans le cadre Android existant. Notez que cela ne fonctionnera pas entre les processus (si votre application est l'un des rares à avoir plusieurs processus).

quelque chose à noter de l'exemple supposons que nous ayons fait quelque chose du genre:

class MyApp extends Application {

  private String myState = /* complicated and slow initialization */;

  public String getState(){
    return myState;
  }
}

maintenant cette initialisation lente (comme frapper le disque, frapper le réseau, tout ce qui bloque, etc) sera effectuée chaque fois que L'Application est instanciée! Vous pensez peut-être que ce n'est qu'une fois pour toutes et que je devrai payer de toute façon, non? Par exemple, comme Dianne Hackborn le mentionne ci-dessous, il est tout à fait possible que votre processus soit instancié-juste-pour traiter une émission de fond événement. Si votre traitement de diffusion n'a pas besoin de cet état, vous venez potentiellement de faire toute une série d'opérations compliquées et lentes pour rien. Paresseux instanciation est le nom du jeu ici. Ce qui suit est une façon un peu plus compliquée d'utiliser L'Application qui a plus de sens pour tout sauf le plus simple des utilisations:

class MyApp extends Application {

  private MyStateManager myStateManager = new MyStateManager();

  public MyStateManager getStateManager(){
    return myStateManager ;
  }
}

class MyStateManager {

  MyStateManager() {
    /* this should be fast */
  }

  String getState() {
    /* if necessary, perform blocking calls here */
    /* make sure to deal with any multithreading/synchronicity issues */

    ...

    return state;
  }
}

class Blah extends Activity {

  @Override
  public void onCreate(Bundle b){
    ...
    MyStateManager stateManager = ((MyApp)getApplicationContext()).getStateManager();
    String state = stateManager.getState();
    ...
  }
}

bien que je préfère application subclassing à l'utilisation de singletons ici comme solution plus élégante, je préférerais les développeurs utilisent des singletons si vraiment nécessaire sur ne pas penser du tout à travers la performance et les implications de multithreading d'associer l'état avec la sous-classe D'Application.

NOTE 1: aussi comme anticafe a commenté, afin de lier correctement votre application override à votre application une étiquette est nécessaire dans le fichier de manifeste. Encore une fois, voir les docs Android pour plus d'informations. Un exemple:

<application
     android:name="my.application.MyApp" 
     android:icon="..."
     android:label="...">
</application>

NOTE 2: user608578 demande ci-dessous comment cela fonctionne avec la gestion des cycles de vie des objets natifs. Je ne suis pas à la hauteur sur l'utilisation du code natif avec Android dans le moindre, et je ne suis pas qualifié pour répondre à la façon dont cela interagirait avec ma solution. Si quelqu'un a une réponse à cela, je suis prêt à leur accorder un crédit et à mettre l'information dans ce post pour une visibilité maximale.

ADDENDUM:

comme certains l'ont noté, c'est pas une solution pour persistant état, quelque chose que j'aurais peut-être dû souligner plus dans la réponse originale. C'est-à-dire: ce n'est pas censé être une solution pour sauver l'utilisateur ou d'autres informations qui est censé persister tout au long de la durée de vie de l'application. Par conséquent, je considère que la plupart des critiques ci-dessous ont trait à des Applications qui sont tuées à tout moment, etc..., moot, que tout ce qui a jamais eu besoin d'être persisté sur le disque ne devrait pas être stocké à travers un Sous-classe d'Application. Il est destiné à être une solution pour stocker l'état d'application temporaire, facilement recréable (si un utilisateur est connecté par exemple) et les composants qui sont une seule instance (application network manager par exemple) ( NOT singleton!) dans la nature.

Dayerman a eu la gentillesse de souligner une intéressante conversation avec Reto Meier et Dianne Hackborn dans laquelle l'utilisation des sous-classes D'Application est découragé en faveur de Singleton patterns. Somatik a également souligné quelque chose de cette nature plus tôt, bien que je ne l'ai pas vu à l'époque. En raison des rôles de Reto et Dianne dans le maintien de la plateforme Android, Je ne peux pas recommander en toute bonne foi d'ignorer leurs conseils. Ce qu'ils disent, va. Je ne suis pas d'accord avec les opinions exprimées au sujet de la préférence accordée à Singleton par rapport aux sous-classes D'Application. Dans mon désaccord, je vais faire usage de concepts mieux expliqués dans ce StackExchange explication du modèle de conception Singleton , de sorte que je n'ai pas à définir les termes de cette réponse. J'encourage vivement à parcourir le lien avant de continuer. Point par point:

Dianne déclare, " Il n'y a aucune raison à la sous-classe de L'Application. Ce n'est pas différent de faire un singleton..."Cette première allégation est incorrecte. Il y a deux raisons principales à cela. 1) la classe Application offre une meilleure garantie à vie pour un développeur d'application; c'est la garantie d'avoir la durée de vie de l'application. Un singleton n'est pas explicitement lié à la durée de vie de l'application (bien qu'il le soit effectivement). Cela peut ne pas être un problème pour votre développeur d'application moyen, mais je dirais que c'est exactement le type de contrat que L'API Android devrait offrir, et il fournit beaucoup plus de flexibilité au système Android ainsi, en minimisant la durée de vie des données associées. 2) La classe Application fournit au développeur d'application un titulaire d'instance unique pour l'état, ce qui est très différent d'un titulaire D'état unique. Pour une liste des différences, voir le lien explication de Singleton ci-dessus.

Dianne continue,"...juste susceptible d'être quelque chose que vous regrettez dans le futur que vous trouvez votre objet D'Application devenant ce grand désordre enchevêtré de ce qui devrait être la logique d'application indépendante."Ce n'est certainement pas incorrect, mais ce n'est pas une raison pour choisir Singleton plutôt que la sous-classe D'Application. Aucun des arguments de Diane fournissent une raison que l'utilisation D'un Singleton est mieux qu'une sous-classe D'Application, tout ce qu'elle tente d'établir est que l'utilisation d'un Singleton n'est pas pire qu'une sous-classe d'Application, qui je crois est faux.

continue - t-elle, "et cela mène plus naturellement à la façon dont vous devriez gérer ces choses-les initialiser sur demande."Cela ne tient pas compte du fait qu'il n'y a aucune raison que vous ne puissiez pas initialiser sur demande en utilisant également une sous-classe D'Application. Encore il n'y a pas de différence.

Dianne conclut avec "le cadre lui-même a des tonnes et des tonnes de singleton pour toutes les petites données partagées qu'il maintient pour l'application, telles que des caches de ressources chargées, des pools d'objets, etc. Il fonctionne très bien."Je ne prétends pas que l'utilisation de Singletons ne peut pas fonctionner correctement ou ne sont pas une alternative légitime. Je soutiens que les Singletons ne fournissent pas un contrat aussi fort avec le système Android que l'utilisation d'une sous-classe D'Application, et en outre que l'utilisation Les Singletons pointent généralement vers un design rigide, qui n'est pas facilement modifiable, et conduit à de nombreux problèmes sur la route. IMHO, le contrat fort de L'API Android offre aux applications de développeur est l'un des aspects les plus attrayants et agréables de la programmation avec Android, et a contribué à l'adoption rapide de développeur qui a conduit la plate-forme Android au succès qu'elle a aujourd'hui. Suggérer l'utilisation de Singletons s'éloigne implicitement d'un contrat API fort, et à mon avis, affaiblit le Cadre Android.

Dianne a également commenté ci-dessous, mentionnant un inconvénient supplémentaire à l'utilisation des sous-classes D'Application, ils peuvent encourager ou faciliter l'écriture de moins de code de performance. C'est très vrai, et j'ai modifié cette réponse pour souligner l'importance de tenir compte de perf ici, et d'adopter la bonne approche si vous utilisez le sous-classement D'Application. Comme le dit Dianne, il est important de se rappeler que votre classe D'Application sera instanciée à chaque fois que temps de chargement de votre processus (peut être plusieurs fois à la fois si votre application s'exécute en plusieurs processus!) même si le processus n'est chargé que pour un événement de diffusion en arrière-plan. Il est donc important d'utiliser la classe d'Application plus comme un référentiel pour les pointeurs partagés composants de votre application plutôt que comme un lieu pour faire le traitement!

je vous laisse avec la liste suivante des inconvénients à Singleton, comme volé du lien StackExchange plus tôt:

• incapacité d'utiliser les classes d'abrégé ou d'interface;
• incapacité à la sous-classe;
• Haut de couplage à travers l'application (difficile de les modifier);
• Difficile à tester (pas de faux/fantaisie dans les tests unitaires);
• difficile à mettre en parallèle dans le cas d'une mutation (nécessite un verrouillage important);

et ajouter le mien:

• manque de clarté et ingérable durée de vie du contrat inadapté pour Android (ou la plupart des autres) de développement;