Ici Dianne dit que les anciennes méthodes de conservation des objets via onRetainNonConfigurationInstance() sont maintenant rendus obsolètes par le fait que vous pouvez conserver les instances de Fragment sur les changements de configuration.
Et aquí dans les démonstrations de l'API pour les fragments, il montre comment utiliser cette méthode pour maintenir les threads après un changement de configuration.
Je constate que lors d'un changement de configuration, lorsque le fragment peut ne pas être attaché à une activité et que le thread a terminé son travail, il peut appeler wait() afin qu'il n'essaie pas de fournir des résultats alors qu'une activité n'est pas attachée. Je trouve cela très utile, et c'est un excellent moyen d'atténuer l'un des problèmes les plus pénibles liés aux changements d'orientation d'Android.
Cependant, si vous utilisez une bibliothèque threadée (une bibliothèque API qui utilise un exécuteur de threads, par exemple), où vous n'avez pas accès à l'option wait() sur lesdits fils, comment pourrions-nous utiliser cette nouvelle fonctionnalité à notre avantage ?
Comment s'assurer que les messages ne seront pas délivrés lorsqu'une activité n'est pas attachée ?
J'ai pensé à un moyen de mettre les messages en file d'attente et de les délivrer lorsqu'une nouvelle activité est jointe, mais je voulais vous demander si vous aviez déjà trouvé des solutions.
Par ailleurs, j'ai étudié l'API LoaderManager et il me semble qu'elle conviendrait pour les données qui doivent être chargées lors de l'affichage d'une activité, mais pas pour les événements, comme la connexion via un bouton, etc.
