Cycle de vie des activités

Article
02/28/2018

Les activités sont un bloc de construction fondamental des applications Android et elles peuvent exister dans un certain nombre d’états différents. Le cycle de vie de l’activité commence par l’instanciation et se termine par la destruction, et inclut de nombreux états entre les deux. Lorsqu’une activité change d’état, la méthode d’événement de cycle de vie appropriée est appelée, informant l’activité de la modification d’état imminente et lui permettant d’exécuter du code pour s’adapter à cette modification. Cet article examine le cycle de vie des activités et explique la responsabilité d’une activité pendant chacun de ces changements d’état de faire partie d’une application fiable et bien comportementée.

Vue d’ensemble du cycle de vie des activités

Les activités sont un concept de programmation inhabituel propre à Android. Dans le développement d’applications traditionnels, il existe généralement une méthode main statique, qui est exécutée pour lancer l’application. Avec Android, cependant, les choses sont différentes; Les applications Android peuvent être lancées via n’importe quelle activité inscrite au sein d’une application. Dans la pratique, la plupart des applications n’auront qu’une activité spécifique spécifiée comme point d’entrée de l’application. Toutefois, si une application se bloque ou est arrêtée par le système d’exploitation, le système d’exploitation peut essayer de redémarrer l’application à la dernière activité ouverte ou n’importe où ailleurs dans la pile d’activités précédente. En outre, le système d’exploitation peut suspendre les activités lorsqu’elles ne sont pas actives et les récupérer si la mémoire est insuffisante. Une attention particulière doit être prise en compte pour permettre à l’application de restaurer correctement son état en cas de redémarrage d’une activité, en particulier si cette activité dépend des données des activités précédentes.

Le cycle de vie de l’activité est implémenté sous la forme d’une collection de méthodes que le système d’exploitation appelle tout au long du cycle de vie d’une activité. Ces méthodes permettent aux développeurs d’implémenter les fonctionnalités nécessaires pour répondre aux exigences de gestion de l’état et des ressources de leurs applications.

Il est extrêmement important pour le développeur d’applications d’analyser les exigences de chaque activité afin de déterminer les méthodes exposées par le cycle de vie de l’activité qui doivent être implémentées. Si vous ne le faites pas, cela peut entraîner une instabilité des applications, des plantages, une surcharge des ressources et peut-être même une instabilité du système d’exploitation sous-jacente.

Ce chapitre examine en détail le cycle de vie de l’activité, notamment :

États d’activité
Méthodes de cycle de vie
Conservation de l’état d’une application

Cette section inclut également une procédure pas à pas qui fournit des exemples pratiques sur la façon d’enregistrer efficacement l’état pendant le cycle de vie de l’activité. À la fin de ce chapitre, vous devez avoir une compréhension du cycle de vie de l’activité et de la prise en charge dans une application Android.

Cycle de vie des activités

Le cycle de vie de l’activité Android comprend une collection de méthodes exposées dans la classe Activity qui fournissent au développeur une infrastructure de gestion des ressources. Cette infrastructure permet aux développeurs de répondre aux exigences de gestion d’état uniques de chaque activité au sein d’une application et de gérer correctement la gestion des ressources.

États d’activité

Le système d’exploitation Android arbitre les activités en fonction de leur état. Cela permet à Android d’identifier les activités qui ne sont plus utilisées, ce qui permet au système d’exploitation de récupérer de la mémoire et des ressources. Le diagramme suivant illustre les états qu’une activité peut traverser pendant sa durée de vie :

Ces états peuvent être divisés en 4 groupes main comme suit :

Actif ou en cours d’exécution : les activités sont considérées comme actives ou en cours d’exécution si elles se trouvent au premier plan, également appelées haut de la pile d’activités. Cette activité est considérée comme la priorité la plus élevée dans Android, et en tant que telle, elle ne sera supprimée par le système d’exploitation que dans des situations extrêmes, par exemple si l’activité tente d’utiliser plus de mémoire que celle disponible sur l’appareil, car cela pourrait empêcher l’interface utilisateur de répondre.
Suspendu : lorsque l’appareil est mis en veille, ou qu’une activité est toujours visible, mais partiellement masquée par une nouvelle activité transparente ou de taille non complète, l’activité est considérée comme suspendue. Les activités suspendues sont toujours actives, c’est-à-dire qu’elles conservent toutes les informations d’état et de membre, et restent attachées au gestionnaire de fenêtres. Cette activité est considérée comme la deuxième activité de priorité la plus élevée dans Android et, en tant que telle, ne sera tuée par le système d’exploitation que si l’arrêt de cette activité répond aux besoins en ressources nécessaires pour maintenir la stabilité et la réactivité de l’activité active/en cours d’exécution.
Arrêté/en arrière-plan : les activités complètement masquées par une autre activité sont considérées comme arrêtées ou en arrière-plan. Les activités arrêtées tentent toujours de conserver leurs informations d’état et de membre aussi longtemps que possible, mais les activités arrêtées sont considérées comme étant la priorité la plus basse des trois états et, par conséquent, le système d’exploitation tuera d’abord les activités dans cet état pour répondre aux besoins en ressources des activités de priorité plus élevée.
Redémarrage : il est possible qu’une activité qui est en pause ou arrêtée dans le cycle de vie soit supprimée de la mémoire par Android. Si l’utilisateur revient à l’activité, elle doit être redémarrée, restaurée à son état précédemment enregistré, puis affichée à l’utilisateur.

Activité Re-Creation en réponse aux modifications de configuration

Pour compliquer les choses, Android lance une clé de plus dans la combinaison appelée Modifications de configuration. Les modifications de configuration sont des cycles rapides de destruction/recréation de l’activité qui se produisent lorsque la configuration d’une activité change, par exemple lorsque l’appareil est pivoté (et que l’activité doit être réinitonnée en mode paysage ou portrait), lorsque le clavier est affiché (et que l’activité a la possibilité de se redimensionner elle-même), ou lorsque l’appareil est placé dans une station d’accueil, entre autres.

Les modifications de configuration entraînent toujours les mêmes changements d’état d’activité que lors de l’arrêt et du redémarrage d’une activité. Toutefois, pour s’assurer qu’une application se sente réactive et fonctionne correctement lors des modifications de configuration, il est important qu’elles soient gérées aussi rapidement que possible. Pour cette raison, Android a une API spécifique qui peut être utilisée pour conserver l’état pendant les modifications de configuration. Nous aborderons cela plus loin dans la section Gestion de l’état tout au long du cycle de vie .

Méthodes de cycle de vie d’activité

Le Kit de développement logiciel (SDK) Android et, par extension, l’infrastructure Xamarin.Android fournissent un modèle puissant pour gérer l’état des activités au sein d’une application. Lorsque l’état d’une activité change, l’activité est avertie par le système d’exploitation, qui appelle des méthodes spécifiques sur cette activité. Le diagramme suivant illustre ces méthodes par rapport au cycle de vie de l’activité :

En tant que développeur, vous pouvez gérer les modifications d’état en remplaçant ces méthodes au sein d’une activité. Il est important de noter, toutefois, que toutes les méthodes de cycle de vie sont appelées sur le thread d’interface utilisateur et empêchent le système d’exploitation d’effectuer le travail suivant de l’interface utilisateur, tel que le masquage de l’activité actuelle, l’affichage d’une nouvelle activité, etc. Par conséquent, le code de ces méthodes doit être aussi bref que possible pour qu’une application se sente performante. Toutes les tâches de longue durée doivent être exécutées sur un thread d’arrière-plan.

Examinons chacune de ces méthodes de cycle de vie et leur utilisation :

OnCreate

OnCreate est la première méthode à appeler lors de la création d’une activité. OnCreate est toujours remplacé pour effectuer toutes les initialisations de démarrage qui peuvent être requises par une activité, par exemple :

Création de vues
Initialisation des variables
Liaison de données statiques à des listes

OnCreateprend un paramètre Bundle, qui est un dictionnaire permettant de stocker et de transmettre des informations d’état et des objets entre des activités Si le bundle n’est pas null, cela indique que l’activité redémarre et qu’elle doit restaurer son état à partir de la instance précédente. Le code suivant illustre comment récupérer des valeurs à partir du bundle :

protected override void OnCreate(Bundle bundle)
{
   base.OnCreate(bundle);

   string intentString;
   bool intentBool;

   if (bundle != null)
   {
      intentString = bundle.GetString("myString");
      intentBool = bundle.GetBoolean("myBool");
   }

   // Set our view from the "main" layout resource
   SetContentView(Resource.Layout.Main);
}

Une fois terminé OnCreate , Android appelle OnStart.

OnStart

OnStart est toujours appelé par le système une fois OnCreate terminé. Les activités peuvent remplacer cette méthode si elles doivent effectuer des tâches spécifiques juste avant qu’une activité ne devienne visible, comme l’actualisation des valeurs actuelles des vues au sein de l’activité. Android appelle OnResume immédiatement après cette méthode.

OnResume

Le système appelle OnResume lorsque l’activité est prête à commencer à interagir avec l’utilisateur. Les activités doivent remplacer cette méthode pour effectuer des tâches telles que :

Augmentation des fréquences d’images (une tâche courante dans le développement de jeux)
Animations de démarrage
Écoute des mises à jour GPS
Afficher les alertes ou boîtes de dialogue pertinentes
Relier des gestionnaires d’événements externes

Par exemple, l’extrait de code suivant montre comment initialiser l’appareil photo :

protected override void OnResume()
{
    base.OnResume(); // Always call the superclass first.

    if (_camera==null)
    {
        // Do camera initializations here
    }
}

OnResume est important, car toute opération effectuée dans OnPause doit être supprimée dans OnResume, car il s’agit de la seule méthode de cycle de vie qui est garantie de s’exécuter après OnPause lors de la remise à vie de l’activité.

OnPause

OnPause est appelé lorsque le système est sur le point de mettre l’activité en arrière-plan ou lorsque l’activité est partiellement masquée. Les activités doivent remplacer cette méthode si elles doivent :

Valider les modifications non enregistrées dans des données persistantes
Détruire ou propre d’autres objets consommant des ressources
Réduire les fréquences d’images et suspendre les animations
Annuler l’inscription des gestionnaires d’événements externes ou des gestionnaires de notification (c’est-à-dire ceux qui sont liés à un service). Cette opération doit être effectuée pour empêcher les fuites de mémoire d’activité.
De même, si l’activité a affiché des boîtes de dialogue ou des alertes, elles doivent être nettoyées avec la .Dismiss() méthode .

Par exemple, l’extrait de code suivant libère la caméra, car l’activité ne peut pas l’utiliser en pause :

protected override void OnPause()
{
    base.OnPause(); // Always call the superclass first

    // Release the camera as other activities might need it
    if (_camera != null)
    {
        _camera.Release();
        _camera = null;
    }
}

Il existe deux méthodes de cycle de vie possibles qui seront appelées après OnPause:

OnResume sera appelé si l’activité doit être retournée au premier plan.
OnStop sera appelé si l’activité est placée en arrière-plan.

OnStop

OnStop est appelé lorsque l’activité n’est plus visible par l’utilisateur. Cela se produit lorsque l’une des opérations suivantes se produit :

Une nouvelle activité est en cours de démarrage et couvre cette activité.
Une activité existante est mise au premier plan.
L’activité est en cours de destruction.

OnStop peut ne pas toujours être appelé dans des situations de mémoire insuffisante, par exemple quand Android est privé de ressources et ne peut pas correctement mettre en arrière-plan l’activité. Pour cette raison, il est préférable de ne pas se fier OnStop à l’appel lors de la préparation d’une activité en vue de sa destruction. Les méthodes de cycle de vie suivantes qui peuvent être appelées après celle-ci seront OnDestroy si l’activité disparaît ou OnRestart si l’activité revient pour interagir avec l’utilisateur.

OnDestroy

OnDestroy est la méthode finale appelée sur une activité instance avant qu’elle ne soit détruite et complètement supprimée de la mémoire. Dans des situations extrêmes, Android peut tuer le processus d’application qui héberge l’activité, ce qui entraîne OnDestroy l’invocation. La plupart des activités n’implémentent pas cette méthode, car la plupart des propre et l’arrêt ont été effectués dans les OnPause méthodes et OnStop . La OnDestroy méthode est généralement remplacée pour propre des tâches de longue durée susceptibles de fuiter des ressources. Par exemple, les threads d’arrière-plan qui ont été démarrés dans OnCreate.

Aucune méthode de cycle de vie n’est appelée après la destruction de l’activité.

OnRestart

OnRestart est appelé après l’arrêt de votre activité, avant qu’elle ne soit redémarrée. Un bon exemple de cela est lorsque l’utilisateur appuie sur le bouton d’accueil lors d’une activité dans l’application. Lorsque cela se produit OnPause , les OnStop méthodes sont appelées, et l’activité est déplacée vers l’arrière-plan, mais n’est pas détruite. Si l’utilisateur devait ensuite restaurer l’application à l’aide du gestionnaire des tâches ou d’une application similaire, Android appellera la OnRestart méthode de l’activité.

Il n’existe aucune directive générale sur le type de logique à implémenter dans OnRestart. Cela est dû au fait que OnStart est toujours appelé, que l’activité soit en cours de création ou de redémarrage, de sorte que toutes les ressources requises par l’activité doivent être initialisées dans OnStart, plutôt que OnRestartdans .

La méthode de cycle de vie suivante appelée après OnRestart sera OnStart.

Retour et accueil

De nombreux appareils Android ont deux boutons distincts : un bouton « Précédent » et un bouton « Accueil ». Vous pouvez en voir un exemple dans la capture d’écran suivante d’Android 4.0.3 :

Il existe une différence subtile entre les deux boutons, même s’ils semblent avoir le même effet de placer une application en arrière-plan. Lorsqu’un utilisateur clique sur le bouton Précédent, il indique à Android qu’il a terminé l’activité. Android va détruire l’activité. En revanche, lorsque l’utilisateur clique sur le bouton Accueil, l’activité est simplement placée en arrière-plan : Android ne tue pas l’activité.

Gestion de l’état tout au long du cycle de vie

Lorsqu’une activité est arrêtée ou détruite, le système offre la possibilité d’enregistrer l’état de l’activité pour une réactivation ultérieure. Cet état enregistré est appelé état instance. Android fournit trois options pour stocker instance’état pendant le cycle de vie de l’activité :

Stockage de valeurs primitives dans un Dictionary ensemble connu sous le nom d’un bundle qu’Android utilisera pour enregistrer l’état.
Création d’une classe personnalisée qui contiendra des valeurs complexes telles que des bitmaps. Android utilisera cette classe personnalisée pour enregistrer l’état.
Contourner le cycle de vie des modifications de configuration et assumer l’entière responsabilité du maintien de l’état dans l’activité.

Ce guide couvre les deux premières options.

État de l’offre groupée

L’option principale pour enregistrer instance’état consiste à utiliser un objet de dictionnaire clé/valeur appelé Bundle. Rappelez-vous que lorsqu’une activité est créée, la OnCreate méthode est passée à un bundle en tant que paramètre, ce bundle peut être utilisé pour restaurer l’état instance. Il n’est pas recommandé d’utiliser un bundle pour des données plus complexes qui ne sérialisent pas rapidement ou facilement en paires clé/valeur (telles que les bitmaps) ; Au lieu de cela, il doit être utilisé pour des valeurs simples telles que des chaînes.

Une activité fournit des méthodes pour faciliter l’enregistrement et la récupération de l’état instance dans le bundle :

OnSaveInstanceState : il est appelé par Android lorsque l’activité est en cours de destruction. Les activités peuvent implémenter cette méthode si elles doivent conserver des éléments d’état clé/valeur.
OnRestoreInstanceState : cette opération est appelée une fois la OnCreate méthode terminée et offre une autre possibilité à une activité de restaurer son état une fois l’initialisation terminée.

Le diagramme suivant illustre l’utilisation de ces méthodes :

OnSaveInstanceState

OnSaveInstanceState est appelé lorsque l’activité est en cours d’arrêt. Il reçoit un paramètre d’offre groupée dans lequel l’activité peut stocker son état. Lorsqu’un appareil subit une modification de configuration, une activité peut utiliser l’objet Bundle passé pour conserver l’état De l’activité en OnSaveInstanceStateremplaçant . Considérons par exemple le code suivant :

int c;

protected override void OnCreate (Bundle bundle)
{
  base.OnCreate (bundle);

  this.SetContentView (Resource.Layout.SimpleStateView);

  var output = this.FindViewById<TextView> (Resource.Id.outputText);

  if (bundle != null) {
    c = bundle.GetInt ("counter", -1);
  } else {
    c = -1;
  }

  output.Text = c.ToString ();

  var incrementCounter = this.FindViewById<Button> (Resource.Id.incrementCounter);

  incrementCounter.Click += (s,e) => {
    output.Text = (++c).ToString();
  };
}

Le code ci-dessus incrémente un entier nommé c lorsque l’utilisateur clique sur un bouton nommé incrementCounter , affichant le résultat dans un TextView nommé output. Lorsqu’un changement de configuration se produit , par exemple, lorsque l’appareil est pivoté, le code ci-dessus perd la valeur de c , car le bundle serait null, comme illustré dans la figure ci-dessous :

Pour conserver la valeur de c dans cet exemple, l’activité peut remplacer OnSaveInstanceState, en enregistrant la valeur dans le bundle, comme indiqué ci-dessous :

protected override void OnSaveInstanceState (Bundle outState)
{
  outState.PutInt ("counter", c);
  base.OnSaveInstanceState (outState);
}

À présent, lorsque l’appareil est pivoté vers une nouvelle orientation, l’entier est enregistré dans le bundle et est récupéré avec la ligne :

c = bundle.GetInt ("counter", -1);

Notes

Il est important d’appeler toujours l’implémentation de base de OnSaveInstanceState afin que l’état de la hiérarchie d’affichage puisse également être enregistré.

État de l’affichage

OnSaveInstanceState Le remplacement est un mécanisme approprié pour enregistrer des données temporaires dans une activité entre les changements d’orientation, comme le compteur dans l’exemple ci-dessus. Toutefois, l’implémentation par défaut de OnSaveInstanceState prend en charge l’enregistrement des données temporaires dans l’interface utilisateur pour chaque vue, à condition qu’un ID soit attribué à chaque vue. Par exemple, supposons qu’une application a un EditText élément défini en XML comme suit :

<EditText android:id="@+id/myText"
  android:layout_width="fill_parent"
  android:layout_height="wrap_content"/>

Étant donné que le EditText contrôle a un id affecté, lorsque l’utilisateur entre des données et fait pivoter l’appareil, les données sont toujours affichées, comme indiqué ci-dessous :

OnRestoreInstanceState

OnRestoreInstanceState est appelé après OnStart. Il offre à une activité la possibilité de restaurer tout état précédemment enregistré dans un bundle au cours de la précédente OnSaveInstanceState. Il s’agit du même bundle que celui fourni à OnCreate, cependant.

Le code suivant montre comment restaurer l’état dans OnRestoreInstanceState:

protected override void OnRestoreInstanceState(Bundle savedState)
{
    base.OnRestoreInstanceState(savedState);
    var myString = savedState.GetString("myString");
    var myBool = savedState.GetBoolean("myBool");
}

Cette méthode permet d’offrir une certaine flexibilité quant au moment où l’état doit être restauré. Parfois, il est plus approprié d’attendre que toutes les initialisations soient effectuées avant de restaurer instance’état. En outre, une sous-classe d’une activité existante peut uniquement vouloir restaurer certaines valeurs à partir de l’état instance. Dans de nombreux cas, il n’est pas nécessaire de remplacer OnRestoreInstanceState, car la plupart des activités peuvent restaurer l’état à l’aide du bundle fourni à OnCreate.

Pour obtenir un exemple d’enregistrement de l’état à l’aide d’un Bundle, reportez-vous à la procédure pas à pas - Enregistrement de l’état de l’activité.

Limitations de l’offre groupée

Bien qu’il soit OnSaveInstanceState facile d’enregistrer des données temporaires, il présente certaines limitations :

Il n’est pas appelé dans tous les cas. Par exemple, appuyer sur Accueil ou Précédent pour quitter une activité n’entraîne OnSaveInstanceState pas l’appel.
Le bundle passé dans OnSaveInstanceState n’est pas conçu pour les objets volumineux, tels que les images. Dans le cas d’objets volumineux, il est préférable d’enregistrer l’objet à partir de OnRetainNonConfigurationInstance , comme indiqué ci-dessous.
Les données enregistrées à l’aide de l’offre groupée sont sérialisées, ce qui peut entraîner des retards.

L’état de l’offre groupée est utile pour les données simples qui n’utilisent pas beaucoup de mémoire, tandis que les données de instance non-configuration sont utiles pour les données plus complexes ou les données qui sont coûteuses à récupérer, par exemple à partir d’un appel de service web ou d’une requête de base de données complexe. Les données de instance non-configuration sont enregistrées dans un objet en fonction des besoins. La section suivante présente un moyen de préserver des types de données plus complexes OnRetainNonConfigurationInstance par le biais de modifications de configuration.

Persistance des données complexes

Outre la persistance des données dans le bundle, Android prend également en charge l’enregistrement des données en remplaçant OnRetainNonConfigurationInstance et en retournant une instance d’un Java.Lang.Object qui contient les données à conserver. L’utilisation OnRetainNonConfigurationInstance de pour enregistrer l’état présente deux principaux avantages :

L’objet retourné à partir de OnRetainNonConfigurationInstance fonctionne bien avec des types de données plus volumineux et plus complexes, car la mémoire conserve cet objet.
La OnRetainNonConfigurationInstance méthode est appelée à la demande, et uniquement en cas de besoin. Cela est plus économique que l’utilisation d’un cache manuel.

L’utilisation OnRetainNonConfigurationInstance de est adaptée aux scénarios où il est coûteux de récupérer les données plusieurs fois, par exemple dans les appels de service web. Par exemple, considérez le code suivant qui recherche Twitter :

public class NonConfigInstanceActivity : ListActivity
{
  protected override void OnCreate (Bundle bundle)
  {
    base.OnCreate (bundle);
    SearchTwitter ("xamarin");
  }

  public void SearchTwitter (string text)
  {
    string searchUrl = String.Format("http://search.twitter.com/search.json?" + "q={0}&rpp=10&include_entities=false&" + "result_type=mixed", text);

    var httpReq = (HttpWebRequest)HttpWebRequest.Create (new Uri (searchUrl));
    httpReq.BeginGetResponse (new AsyncCallback (ResponseCallback), httpReq);
  }

  void ResponseCallback (IAsyncResult ar)
  {
    var httpReq = (HttpWebRequest)ar.AsyncState;

    using (var httpRes = (HttpWebResponse)httpReq.EndGetResponse (ar)) {
      ParseResults (httpRes);
    }
  }

  void ParseResults (HttpWebResponse httpRes)
  {
    var s = httpRes.GetResponseStream ();
    var j = (JsonObject)JsonObject.Load (s);

    var results = (from result in (JsonArray)j ["results"] let jResult = result as JsonObject select jResult ["text"].ToString ()).ToArray ();

    RunOnUiThread (() => {
      PopulateTweetList (results);
    });
  }

  void PopulateTweetList (string[] results)
  {
    ListAdapter = new ArrayAdapter<string> (this, Resource.Layout.ItemView, results);
  }
}

Ce code récupère les résultats du web au format JSON, les analyse, puis présente les résultats dans une liste, comme illustré dans la capture d’écran suivante :

Lorsqu’un changement de configuration se produit, par exemple, lorsqu’un appareil est pivoté, le code répète le processus. Pour réutiliser les résultats récupérés à l’origine et ne pas provoquer des appels réseau inutiles et redondants, nous pouvons utiliser OnRetainNonconfigurationInstance pour enregistrer les résultats, comme indiqué ci-dessous :

public class NonConfigInstanceActivity : ListActivity
{
  TweetListWrapper _savedInstance;

  protected override void OnCreate (Bundle bundle)
  {
    base.OnCreate (bundle);

    var tweetsWrapper = LastNonConfigurationInstance as TweetListWrapper;

    if (tweetsWrapper != null) {
      PopulateTweetList (tweetsWrapper.Tweets);
    } else {
      SearchTwitter ("xamarin");
    }

    public override Java.Lang.Object OnRetainNonConfigurationInstance ()
    {
      base.OnRetainNonConfigurationInstance ();
      return _savedInstance;
    }

    ...

    void PopulateTweetList (string[] results)
    {
      ListAdapter = new ArrayAdapter<string> (this, Resource.Layout.ItemView, results);
      _savedInstance = new TweetListWrapper{Tweets=results};
    }
}

À présent, lorsque l’appareil effectue une rotation, les résultats d’origine sont récupérés à partir de la LastNonConfiguartionInstance propriété . Dans cet exemple, les résultats se composent d’un string[] tweet contenant. Étant donné OnRetainNonConfigurationInstance que nécessite qu’un Java.Lang.Object soit retourné, est string[] encapsulé dans une classe qui sous-classe Java.Lang.Object, comme indiqué ci-dessous :

class TweetListWrapper : Java.Lang.Object
{
  public string[] Tweets { get; set; }
}

Par exemple, la tentative d’utilisation d’un TextView en tant qu’objet retourné à partir de entraîne la fuite de OnRetainNonConfigurationInstance l’activité, comme illustré par le code ci-dessous :

TextView _textView;

protected override void OnCreate (Bundle bundle)
{
  base.OnCreate (bundle);

  var tv = LastNonConfigurationInstance as TextViewWrapper;

  if(tv != null) {
    _textView = tv;
    var parent = _textView.Parent as FrameLayout;
    parent.RemoveView(_textView);
  } else {
    _textView = new TextView (this);
    _textView.Text = "This will leak.";
  }

  SetContentView (_textView);
}

public override Java.Lang.Object OnRetainNonConfigurationInstance ()
{
  base.OnRetainNonConfigurationInstance ();
  return _textView;
}

Dans cette section, nous avons appris à conserver des données d’état simples avec et à conserver des Bundletypes de données plus complexes avec OnRetainNonConfigurationInstance.

Résumé

Le cycle de vie de l’activité Android fournit une infrastructure puissante pour la gestion de l’état des activités au sein d’une application, mais il peut être difficile à comprendre et à implémenter. Ce chapitre a présenté les différents états qu’une activité peut traverser pendant sa durée de vie, ainsi que les méthodes de cycle de vie associées à ces états. Ensuite, des instructions ont été fournies sur le type de logique à exécuter dans chacune de ces méthodes.

Partager via

Cycle de vie des activités

Vue d’ensemble du cycle de vie des activités

Cycle de vie des activités

États d’activité

Activité Re-Creation en réponse aux modifications de configuration

Méthodes de cycle de vie d’activité

OnCreate

OnStart

OnResume

OnPause

OnStop

OnDestroy

OnRestart

Retour et accueil

Gestion de l’état tout au long du cycle de vie

État de l’offre groupée

OnSaveInstanceState

État de l’affichage

OnRestoreInstanceState

Limitations de l’offre groupée

Persistance des données complexes

Résumé

Ressources supplémentaires

Partager via

Cycle de vie des activités

Vue d’ensemble du cycle de vie des activités

Cycle de vie des activités

États d’activité

Activité Re-Creation en réponse aux modifications de configuration

Méthodes de cycle de vie d’activité

OnCreate

OnStart

OnResume

OnPause

OnStop

OnDestroy

OnRestart

Retour et accueil

Gestion de l’état tout au long du cycle de vie

État de l’offre groupée

OnSaveInstanceState

État de l’affichage

OnRestoreInstanceState

Limitations de l’offre groupée

Persistance des données complexes

Résumé

Liens associés

Ressources supplémentaires