Pourquoi étendre la classe Android Application ?

Question

Une extension Application peut déclarer des variables globales. Y a-t-il d'autres raisons ?

Answer 1

Je vois qu'il manque une réponse à cette question. Je prolonge Application parce que j'utilise Bill Pugh Singleton mise en œuvre ( voir la référence ) et certains de mes singletons ont besoin de contexte. Le site Application ressemble à ceci :

public class MyApplication extends Application {

    private static final String TAG = MyApplication.class.getSimpleName();

    private static MyApplication sInstance;

    @Contract(pure = true)
    @Nullable
    public static Context getAppContext() {
        return sInstance;
    }

    @Override
    public void onCreate() {
        super.onCreate();
        Log.d(TAG, "onCreate() called");
        sInstance = this;
    }
}

Et les singletons ressemblent à ça :

public class DataManager {

    private static final String TAG = DataManager.class.getSimpleName();

    @Contract(pure = true)
    public static DataManager getInstance() {
        return InstanceHolder.INSTANCE;
    }

    private DataManager() {
        doStuffRequiringContext(MyApplication.getAppContext());
    }

    private static final class InstanceHolder {
        @SuppressLint("StaticFieldLeak")
        private static final DataManager INSTANCE = new DataManager();
    }
}

De cette façon, je n'ai pas besoin d'avoir un contexte à chaque fois que j'utilise un singleton et j'obtiens une initialisation synchronisée paresseuse avec une quantité minimale de code.

Conseil : la mise à jour du modèle singleton d'Android Studio permet de gagner beaucoup de temps.

Answer 2

Je pense que vous pouvez utiliser la classe Application pour de nombreuses choses, mais elles sont toutes liées à votre besoin de faire certaines choses AVANT que vos activités ou services ne soient lancés. Par exemple, dans mon application, j'utilise des polices de caractères personnalisées. Au lieu d'appeler

Typeface.createFromAsset()

à partir de chaque activité pour obtenir les références de mes polices à partir du dossier Assets (ce n'est pas bon car cela entraînera une fuite de mémoire car vous gardez une référence aux assets à chaque fois que vous appelez cette méthode), je le fais à partir de la méthode onCreate() dans ma classe d'application :

private App appInstance;
Typeface quickSandRegular;
...
public void onCreate() {
    super.onCreate();

    appInstance = this;
    quicksandRegular = Typeface.createFromAsset(getApplicationContext().getAssets(),
                       "fonts/Quicksand-Regular.otf");
   ...
   }

Maintenant, j'ai aussi une méthode définie comme ceci :

public static App getAppInstance() {
    return appInstance;
}

et ceci :

public Typeface getQuickSandRegular() {
    return quicksandRegular;
}

Donc, de n'importe où dans mon application, tout ce que j'ai à faire est :

App.getAppInstance().getQuickSandRegular()

Une autre utilisation de la classe Application consiste pour moi à vérifier si l'appareil est connecté à l'Internet AVANT que les activités et services qui nécessitent une connexion ne démarrent réellement et ne prennent les mesures nécessaires.

Answer 3

Fuente: https://github.com/codepath/android_guides/wiki/Understanding-the-Android-Application-Class

Dans de nombreuses applications, il n'est pas nécessaire de travailler directement avec une classe d'application. Cependant, il existe quelques utilisations acceptables d'une classe d'application personnalisée :

• Tâches spécialisées qui doivent être exécutées avant la création de votre première activité
• Initialisation globale qui doit être partagée par tous les composants (rapport de crash, persistance).
• Méthodes statiques pour un accès facile à des données statiques immuables, telles qu'un objet client réseau partagé.

Vous ne devez jamais stocker de données d'instance mutables à l'intérieur de l'objet Application car si vous supposez que vos données y resteront, votre application se plantera inévitablement à un moment donné avec une exception NullPointerException. L'objet Application n'est pas garanti de rester en mémoire pour toujours, il sera tué. Contrairement à la croyance populaire, l'application ne sera pas redémarrée à partir de zéro. Android créera un nouvel objet Application et commencera l'activité là où l'utilisateur se trouvait auparavant pour donner l'illusion que l'application n'a jamais été tuée en premier lieu.

Answer 4

Pour ajouter aux autres réponses qui indiquent que vous pourriez souhaiter stocker des variables dans la portée de l'application, pour tous les threads à long terme ou d'autres objets qui ont besoin d'être liés à votre application lorsque vous n'utilisez PAS une activité (l'application n'est pas une activité) comme l'impossibilité de demander un service lié alors la liaison à l'instance de l'application est préférable. Le seul avertissement évident avec cette approche est que les objets vivent aussi longtemps que l'application est vivante, donc un contrôle plus implicite de la mémoire est nécessaire, sinon vous rencontrerez des problèmes liés à la mémoire comme des fuites.

Autre chose qui peut vous être utile : dans l'ordre des opérations, l'application démarre en premier avant toute activité. Dans ce laps de temps, vous pouvez, si vous le souhaitez, préparer toute opération de gestion interne qui aurait lieu avant votre première activité.

2018-10-19 11:31:55.246 8643-8643/: application created
2018-10-19 11:31:55.630 8643-8643/: activity created

Answer 5

Vous pouvez accéder aux variables de n'importe quelle classe sans créer d'objets, si elle est étendue par Application. Ils peuvent être appelés globalement et leur état est maintenu jusqu'à ce que l'application ne soit pas tuée.