J'essaie d'écrire une application qui fait quelque chose de spécifique lorsqu'elle est remise au premier plan après un certain temps. Existe-t-il un moyen de détecter lorsqu'une application est envoyée en arrière-plan ou mise au premier plan?
android
background
foreground
iHorse
la source
la source
Réponses:
Les méthodes
onPause()
etonResume()
sont appelées lorsque l'application est mise en arrière-plan et à nouveau au premier plan. Cependant, ils sont également appelés lorsque l'application est démarrée pour la première fois et avant d'être supprimée. Vous pouvez en savoir plus dans Activity .Il n'y a pas d'approche directe pour obtenir l'état de l'application en arrière-plan ou au premier plan, mais même moi, j'ai rencontré ce problème et trouvé la solution avec
onWindowFocusChanged
etonStop
.Pour plus de détails, consultez ici Android: Solution pour détecter lorsqu'une application Android passe en arrière-plan et revenir au premier plan sans getRunningTasks ou getRunningAppProcesses .
la source
2018: Android prend en charge cela nativement via les composants du cycle de vie.
MISE À JOUR DE MARS 2018 : Il y a maintenant une meilleure solution. Voir ProcessLifecycleOwner . Vous devrez utiliser les nouveaux composants de l'architecture 1.1.0 (les plus récents à l'heure actuelle), mais il est spécialement conçu pour cela.
Il y a un exemple simple fourni dans cette réponse, mais j'ai écrit un exemple d'application et un blog à ce sujet.
Depuis que j'ai écrit cela en 2014, différentes solutions sont apparues. Certains fonctionnaient, certains étaient censés fonctionner , mais avaient des défauts (y compris le mien!) Et nous, en tant que communauté (Android), avons appris à vivre avec les conséquences et avons écrit des solutions de contournement pour les cas spéciaux.
Ne présumez jamais qu'un seul extrait de code est la solution que vous recherchez, il est peu probable que ce soit le cas; mieux encore, essayez de comprendre ce qu'il fait et pourquoi il le fait.
La
MemoryBoss
classe n'a jamais été utilisée par moi comme écrit ici, c'était juste un morceau de pseudo-code qui fonctionnait.À moins qu'il n'y ait une raison valable pour que vous n'utilisiez pas les nouveaux composants de l'architecture (et il y en a certains, surtout si vous ciblez de super vieux API), alors allez-y et utilisez-les. Ils sont loin d'être parfaits, mais aucun ne l'était
ComponentCallbacks2
.MISE À JOUR / NOTES (novembre 2015) : Les gens ont fait deux commentaires, le premier est que cela
>=
devrait être utilisé au lieu de==
parce que la documentation indique que vous ne devriez pas vérifier les valeurs exactes . C'est très bien dans la plupart des cas, mais gardez à l'esprit que si vous ne voulez faire quelque chose que lorsque l'application est passée en arrière-plan, vous devrez utiliser == et la combiner avec une autre solution (comme les rappels de cycle de vie d'activité), ou vous peut ne pas obtenir l'effet souhaité. L'exemple (et cela m'est arrivé) est que si vous voulez verrouillervotre application avec un écran de mot de passe en arrière-plan (comme 1Password si vous le connaissez), vous pouvez accidentellement verrouiller votre application si vous manquez de mémoire et que vous testez soudainement>= TRIM_MEMORY
, car Android déclenchera unLOW MEMORY
appel et c'est plus élevé que le vôtre. Soyez donc prudent comment / ce que vous testez.De plus, certaines personnes ont demandé comment détecter quand vous revenez.
La manière la plus simple à laquelle je pense est expliquée ci-dessous, mais comme certaines personnes ne la connaissent pas, j'ajoute un pseudo-code ici. En supposant que vous avez
YourApplication
et lesMemoryBoss
classes, dans votreclass BaseActivity extends Activity
(vous devrez en créer un si vous n'en avez pas).Je recommande onStart car Dialogs peut suspendre une activité, donc je parie que vous ne voulez pas que votre application pense "qu'elle est passée en arrière-plan" si tout ce que vous avez fait était d'afficher une boîte de dialogue en plein écran, mais votre kilométrage peut varier.
Et c'est tout. Le code dans le bloc si vous ne sera exécutée une fois la nouvelle (qui a également, même si vous allez à une autre activité,
extends BaseActivity
) fera rapportwasInBackground
estfalse
donc il ne sera pas exécuter le code, jusqu'à ce que l'onMemoryTrimmed
on appelle et le drapeau est défini sur true à nouveau .J'espère que cela pourra aider.
MISE À JOUR / NOTES (avril 2015) : Avant de commencer à copier et coller sur ce code, notez que j'ai trouvé quelques exemples où il peut ne pas être fiable à 100% et doit être combiné avec d'autres méthodes pour obtenir les meilleurs résultats. Il existe notamment deux cas connus où le
onTrimMemory
rappel n'est pas garanti d'être exécuté:Si votre téléphone verrouille l'écran pendant que votre application est visible (par exemple, votre appareil se verrouille après nn minutes), ce rappel n'est pas appelé (ou pas toujours) parce que l'écran de verrouillage est juste au-dessus, mais votre application est toujours en cours d'exécution, bien que couverte.
Si votre appareil est relativement faible en mémoire (et soumis à un stress mémoire), le système d'exploitation semble ignorer cet appel et passer directement à des niveaux plus critiques.
Maintenant, selon l'importance pour vous de savoir quand votre application est passée en arrière-plan, vous devrez peut-être étendre cette solution avec le suivi du cycle de vie de l'activité et ainsi de suite.
Gardez simplement à l'esprit ce qui précède et ayez une bonne équipe d'AQ;)
FIN DE MISE À JOUR
Il peut être tard, mais il existe une méthode fiable dans Ice Cream Sandwich (API 14) et au-dessus .
Il s'avère que lorsque votre application n'a plus d'interface utilisateur visible, un rappel est déclenché. Le rappel, que vous pouvez implémenter dans une classe personnalisée, s'appelle ComponentCallbacks2 (oui, avec deux). Cette fonction de rappel n'est disponible qu'en API niveau 14 (Ice Cream Sandwich) et au-dessus.
Vous obtenez essentiellement un appel à la méthode:
Le niveau est de 20 ou plus spécifiquement
J'ai testé cela et cela fonctionne toujours, car le niveau 20 n'est qu'une "suggestion" que vous souhaitiez peut-être libérer certaines ressources car votre application n'est plus visible.
Pour citer les documents officiels:
Bien sûr, vous devez l'implémenter pour faire ce qu'il dit (purger la mémoire qui n'a pas été utilisée depuis un certain temps, effacer certaines collections qui étaient inutilisées, etc. Les possibilités sont infinies (voir les documents officiels pour d'autres plus possibles). niveaux critiques ).
Mais, ce qui est intéressant, c'est que le système d'exploitation vous dit: HEY, votre application est passée en arrière-plan!
C'est exactement ce que vous vouliez savoir en premier lieu.
Comment déterminez-vous votre retour?
Eh bien c'est facile, je suis sûr que vous avez une "BaseActivity" afin que vous puissiez utiliser votre onResume () pour signaler le fait que vous êtes de retour. Parce que la seule fois où vous direz que vous n'êtes pas de retour, c'est lorsque vous recevez réellement un appel à la
onTrimMemory
méthode ci-dessus .Ça marche. Vous n'obtenez pas de faux positifs. Si une activité reprend, vous êtes de retour, 100% du temps. Si l'utilisateur retourne à l'arrière, vous recevez un autre
onTrimMemory()
appel.Vous devez vous inscrire à vos activités (ou mieux encore, un cours personnalisé).
Le moyen le plus simple de garantir que vous recevez toujours ceci est de créer une classe simple comme celle-ci:
Pour l'utiliser, dans votre implémentation d'application ( vous en avez un, DROIT? ), Faites quelque chose comme:
Si vous créez un,
Interface
vous pouvez ajouter unelse
à celaif
et implémenterComponentCallbacks
(sans le 2) utilisé dans quoi que ce soit en dessous de l'API 14. Ce rappel n'a que laonLowMemory()
méthode et n'est pas appelé lorsque vous passez en arrière-plan , mais vous devez l'utiliser pour réduire la mémoire .Maintenant, lancez votre application et appuyez sur home. Votre
onTrimMemory(final int level)
méthode doit être appelée (indice: ajouter la journalisation).La dernière étape consiste à se désinscrire du rappel. Le meilleur endroit est probablement la
onTerminate()
méthode de votre application, mais cette méthode n'est pas appelée sur un appareil réel:Donc, sauf si vous avez vraiment une situation où vous ne voulez plus être enregistré, vous pouvez l'ignorer en toute sécurité, car votre processus est en train de mourir au niveau du système d'exploitation de toute façon.
Si vous décidez de vous désinscrire à un moment donné (si vous fournissez, par exemple, un mécanisme d'arrêt pour que votre application se nettoie et meure), vous pouvez faire:
Et c'est tout.
la source
level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN
ce qui évite le problème dans votre mise à jour, point 2. En ce qui concerne le point 1, ce n'est pas un problème pour moi, car l'application n'est pas vraiment passée en arrière-plan, c'est donc la façon dont elle est censée fonctionner.Voici comment j'ai réussi à résoudre ce problème. Il part du principe que l'utilisation d'une référence temporelle entre les transitions d'activité fournira très probablement des preuves suffisantes qu'une application a été "mise en arrière-plan" ou non.
Tout d'abord, j'ai utilisé une instance android.app.Application (appelons-la MyApplication) qui a un Timer, une TimerTask, une constante pour représenter le nombre maximal de millisecondes que la transition d'une activité à une autre pourrait raisonnablement prendre (je suis allé avec une valeur de 2s), et un booléen pour indiquer si l'application était "en arrière-plan" ou non:
L'application propose également deux méthodes pour démarrer et arrêter le minuteur / la tâche:
Le dernier élément de cette solution consiste à ajouter un appel à chacune de ces méthodes à partir des événements onResume () et onPause () de toutes les activités ou, de préférence, dans une activité de base dont toutes vos activités concrètes héritent:
Ainsi, dans le cas où l'utilisateur navigue simplement entre les activités de votre application, la onPause () de l'activité en cours démarre le chronomètre, mais presque immédiatement, la nouvelle activité entrée annule le chronomètre avant qu'il n'atteigne le temps de transition maximum. Et donc, InBackground serait faux .
D'un autre côté, lorsqu'une activité arrive au premier plan à partir du lanceur, le réveil de l'appareil, la fin d'un appel téléphonique, etc., plus que probablement la tâche du minuteur exécutée avant cet événement, et donc InBackground a été défini sur true .
la source
Edit: les nouveaux composants de l'architecture ont apporté quelque chose de prometteur: ProcessLifecycleOwner , voir la réponse de @ vokilam
La solution réelle selon une conférence Google I / O :
Oui. Je sais qu'il est difficile de croire que cette solution simple fonctionne, car nous avons tant de solutions étranges ici.
Mais il y a de l'espoir.
la source
ProcessLifecycleOwner
semble également être une solution prometteuse.Une implémentation peut être aussi simple que
Selon le code source, la valeur actuelle du retard est
700ms
.L'utilisation de cette fonctionnalité nécessite également
dependencies
:la source
implementation "android.arch.lifecycle:extensions:1.0.0"
etannotationProcessor "android.arch.lifecycle:compiler:1.0.0"
du référentiel de Google (c'est-à-diregoogle()
)Sur la base de la réponse de Martín Marconcinis (merci!) J'ai finalement trouvé une solution fiable (et très simple).
Ajoutez ensuite ceci à votre onCreate () de votre classe Application
la source
Nous utilisons cette méthode. Cela semble trop simple pour fonctionner, mais il a été bien testé dans notre application et fonctionne en fait étonnamment bien dans tous les cas, y compris pour accéder à l'écran d'accueil par le bouton "Accueil", par le bouton "Retour" ou après le verrouillage de l'écran. Essaie.
L'idée est que, au premier plan, Android commence toujours une nouvelle activité juste avant d'arrêter la précédente. Ce n'est pas garanti, mais c'est comme ça que ça fonctionne. BTW, Flurry semble utiliser la même logique (juste une supposition, je n'ai pas vérifié cela, mais il accroche aux mêmes événements).
Edit: selon les commentaires, nous sommes également passés à onStart () dans les versions ultérieures du code. En outre, j'ajoute des super appels, qui manquaient dans mon message initial, car il s'agissait plus d'un concept que d'un code de travail.
la source
onStop is called when the activity is no longer visible to the user
.Si votre application se compose de plusieurs activités et / ou d'activités empilées comme un widget de barre d'onglets, la substitution de onPause () et onResume () ne fonctionnera pas. C'est-à-dire qu'au démarrage d'une nouvelle activité, les activités en cours seront interrompues avant la création de la nouvelle. Il en va de même lorsque vous terminez (à l'aide du bouton "retour") une activité.
J'ai trouvé deux méthodes qui semblent fonctionner comme souhaité.
La première nécessite l'autorisation GET_TASKS et consiste en une méthode simple qui vérifie si l'activité en cours d'exécution sur le périphérique appartient à l'application, en comparant les noms de packages:
Cette méthode a été trouvée dans le framework Droid-Fu (maintenant appelé Ignition).
La deuxième méthode que j'ai implémentée moi-même ne nécessite pas l'autorisation GET_TASKS, ce qui est bien. Au lieu de cela, il est un peu plus compliqué à mettre en œuvre.
Dans votre classe MainApplication, vous avez une variable qui suit le nombre d'activités en cours d'exécution dans votre application. Dans onResume () pour chaque activité, vous augmentez la variable et dans onPause () vous la diminuez.
Lorsque le nombre d'activités en cours d'exécution atteint 0, l'application est mise en arrière-plan SI les conditions suivantes sont remplies:
Lorsque vous pouvez détecter que l'application a démissionné en arrière-plan, il est également facile de détecter lorsqu'elle est ramenée au premier plan.
la source
getRunnintTasks()
Créez une classe qui s'étend
Application
. Ensuite, nous pouvons utiliser sa méthode de remplacement,onTrimMemory()
.Pour détecter si l'application est passée en arrière-plan, nous utiliserons:
la source
FragmentActivity
vous pourriez aussi vouloir ajouterlevel == ComponentCallbacks2.TRIM_MEMORY_COMPLETE
aussi.Pensez à utiliser onUserLeaveHint. Cela ne sera appelé que lorsque votre application sera en arrière-plan. onPause aura des cas d'angle à gérer, car il peut être appelé pour d'autres raisons; par exemple, si l'utilisateur ouvre une autre activité dans votre application telle que votre page de paramètres, la méthode onPause de votre activité principale sera appelée même si elle est toujours dans votre application; le suivi de ce qui se passe entraînera des bogues lorsque vous pourrez simplement utiliser le rappel onUserLeaveHint qui fait ce que vous demandez.
Quand on UserLeaveHint est appelé, vous pouvez définir un indicateur booléen inBackground sur true. Lorsque onResume est appelé, supposez seulement que vous êtes revenu au premier plan si l'indicateur inBackground est défini. En effet, onResume sera également appelé sur votre activité principale si l'utilisateur n'était que dans votre menu de paramètres et n'a jamais quitté l'application.
N'oubliez pas que si l'utilisateur clique sur le bouton d'accueil dans votre écran de paramètres, onUserLeaveHint sera appelé dans votre activité de paramètres et lorsqu'il reviendra, Resume sera appelé dans votre activité de paramètres. Si vous n'avez que ce code de détection dans votre activité principale, vous raterez ce cas d'utilisation. Pour avoir ce code dans toutes vos activités sans dupliquer le code, ayez une classe d'activité abstraite qui étend l'activité et mettez votre code commun dedans. Ensuite, chaque activité que vous avez peut prolonger cette activité abstraite.
Par exemple:
la source
ActivityLifecycleCallbacks peut être intéressant, mais il n'est pas bien documenté.
Cependant, si vous appelez registerActivityLifecycleCallbacks (), vous devriez pouvoir obtenir des rappels lorsque des activités sont créées, détruites, etc. Vous pouvez appeler getComponentName () pour l'activité.
la source
Le package android.arch.lifecycle fournit des classes et des interfaces qui vous permettent de créer des composants adaptés au cycle de vie
Votre application doit implémenter l'interface LifecycleObserver:
Pour ce faire, vous devez ajouter cette dépendance à votre fichier build.gradle:
Comme recommandé par Google, vous devez minimiser le code exécuté dans les méthodes d'activités du cycle de vie:
Vous pouvez en savoir plus ici: https://developer.android.com/topic/libraries/architecture/lifecycle
la source
Dans votre application, ajoutez le rappel et vérifiez l'activité root de la manière suivante:
la source
J'ai créé un projet sur Github app-foreground-background-listen
Créez une activité de base pour toutes les activités dans votre application.
Utilisez maintenant cette BaseActivity comme une super classe de toutes vos activités comme MainActivity étend BaseActivity et onAppStart sera appelé lorsque vous démarrez votre application et onAppPause () sera appelé lorsque l'application passera en arrière-plan à partir de n'importe quel écran.
la source
C'est assez facile avec ProcessLifecycleOwner
Ajoutez ces dépendances
À Kotlin :
Puis dans votre activité de base:
Voir mon article sur ce sujet: https://medium.com/@egek92/how-to-actually-detect-foreground-background-changes-in-your-android-application-without-wanting-9719cc822c48
la source
Vous pouvez utiliser ProcessLifecycleOwner en y attachant un observateur de cycle de vie.
puis, dans la
onCreate()
classe Application, vous appelez ceci:avec cela, vous pourrez capturer les événements
ON_PAUSE
etON_STOP
de votre application qui se produisent quand il passe en arrière-plan.la source
Il n'y a pas de méthodes de cycle de vie simples pour vous dire quand toute l'application passe en arrière-plan / au premier plan.
Je l'ai fait de manière simple. Suivez les instructions ci-dessous pour détecter la phase d'arrière-plan / de premier plan de l'application.
Avec une petite solution de contournement, c'est possible. Ici, ActivityLifecycleCallbacks vient à la rescousse. Permettez-moi de vous guider pas à pas.
Tout d'abord, créez une classe qui étend android.app.Application et implémente l' interface ActivityLifecycleCallbacks . Dans Application.onCreate (), enregistrez le rappel.
Enregistrez la classe «App» dans le manifeste comme ci-dessous
<application android:name=".App"
.Il y aura au moins une activité à l'état démarré lorsque l'application est au premier plan et il n'y aura pas d'activité à l'état démarré lorsque l'application est en arrière-plan.
Déclarez 2 variables comme ci-dessous dans la classe «App».
activityReferences
conservera le nombre d'activités dans l' état démarré .isActivityChangingConfigurations
est un indicateur pour indiquer si l'activité en cours subit un changement de configuration comme un commutateur d'orientation.En utilisant le code suivant, vous pouvez détecter si l'application passe au premier plan.
Voici comment détecter si l'application passe en arrière-plan.
Comment ça fonctionne:
C'est un petit truc fait avec la façon dont les méthodes de cycle de vie sont appelées en séquence. Permettez-moi de vous présenter un scénario.
Supposons que l'utilisateur lance l'application et que l'activité de lancement A soit lancée. Les appels du cycle de vie seront,
Maintenant, l'activité A commence l'activité B.
Ensuite, l'utilisateur revient de l'activité B,
Ensuite, l'utilisateur appuie sur le bouton Accueil,
Dans le cas, si l'utilisateur appuie sur le bouton Accueil de l'activité B au lieu du bouton Précédent, ce sera toujours le même et les références d'activité seront
0
. Par conséquent, nous pouvons détecter que l'application entre en arrière-plan.Alors, quel est le rôle de
isActivityChangingConfigurations
? Dans le scénario ci-dessus, supposons que l'activité B modifie l'orientation. La séquence de rappel sera,C'est pourquoi nous avons une vérification supplémentaire
isActivityChangingConfigurations
pour éviter le scénario lorsque l'activité passe par les changements de configuration.la source
J'ai trouvé une bonne méthode pour détecter l'application, que ce soit en avant-plan ou en arrière-plan. Voici mon code . J'espère que cela vous aidera.
}
la source
Vous pouvez utiliser:
Pour différer entre les nouveaux démarrages et redémarrages.
la source
Edit 2: Ce que j'ai écrit ci-dessous ne fonctionnera pas réellement. Google a rejeté une application qui inclut un appel à ActivityManager.getRunningTasks (). De la documentation ressort de que cette API est uniquement destinée au débogage et au développement. Je mettrai à jour cet article dès que j'aurai le temps de mettre à jour le projet GitHub ci-dessous avec un nouveau schéma qui utilise des minuteries et est presque aussi bon.
Edit 1: J'ai rédigé un article de blog et créé un simple référentiel GitHub pour rendre cela vraiment facile.
La réponse acceptée et la mieux notée ne sont pas vraiment la meilleure approche. L'implémentation de la réponse la mieux notée de isApplicationBroughtToBackground () ne gère pas la situation où l'activité principale de l'application cède le pas à une activité définie dans la même application, mais elle a un package Java différent. J'ai trouvé un moyen de le faire qui fonctionnera dans ce cas.
Appelez cela dans onPause (), et il vous dira si votre application va en arrière-plan parce qu'une autre application a démarré ou si l'utilisateur a appuyé sur le bouton d'accueil.
la source
Bonne réponse ici
Créez une classe avec le nom MyApp comme ci-dessous:
Ensuite, partout où vous voulez (meilleure première activité lancée dans l'application), ajoutez le code ci-dessous:
Terminé! Maintenant, lorsque l'application est en arrière-plan, nous obtenons le journal
status : we are out
et lorsque nous allons dans l'application, nous obtenons le journalstatus : we are out
la source
Ma solution a été inspirée par la réponse de @ d60402 et repose également sur une fenêtre de temps, mais sans utiliser le
Timer
:où
SingletonApplication
est une extension deApplication
classe:la source
J'utilisais cela avec Google Analytics EasyTracker, et cela a fonctionné. Il pourrait être étendu pour faire ce que vous cherchez en utilisant un simple entier.
la source
Je sais que c'est un peu tard mais je pense que toutes ces réponses ont des problèmes pendant que je le fais comme ci-dessous et cela fonctionne parfaitement.
créer un rappel de cycle de vie d'activité comme celui-ci:
et enregistrez-le simplement sur votre classe d'application comme ci-dessous:
la source
Cela semble être l'une des questions les plus compliquées d'Android car (au moment de la rédaction de ce document), Android n'a pas d'équivalent iOS
applicationDidEnterBackground()
ni deapplicationWillEnterForeground()
rappel. J'ai utilisé une bibliothèque AppState créée par @jenzz .Il s'est avéré que c'était exactement ce dont j'avais besoin, surtout parce que mon application avait plusieurs activités, donc simplement vérifier
onStart()
ouonStop()
sur une activité n'allait pas le couper.J'ai d'abord ajouté ces dépendances à gradle:
Ensuite, il s'agissait simplement d'ajouter ces lignes à un endroit approprié dans votre code:
Selon la façon dont vous vous abonnez à l'observable, vous devrez peut-être vous désabonner pour éviter les fuites de mémoire. Encore plus d'informations sur la page github .
la source
Il s'agit de la version modifiée de la réponse de @ d60402: https://stackoverflow.com/a/15573121/4747587
Faites tout ce qui y est mentionné. Mais au lieu d'avoir un
Base Activity
et d'en faire un parent pour chaque activité et pour remplacer leonResume()
etonPause
, procédez comme suit:Dans votre classe d'application, ajoutez la ligne:
registerActivityLifecycleCallbacks (rappel Application.ActivityLifecycleCallbacks);
Cela
callback
a toutes les méthodes de cycle de vie d'activité et vous pouvez maintenant remplaceronActivityResumed()
etonActivityPaused()
.Jetez un œil à ce Gist: https://gist.github.com/thsaravana/1fa576b6af9fc8fff20acfb2ac79fa1b
la source
Vous pouvez y parvenir facilement à l'aide de
ActivityLifecycleCallbacks
etComponentCallbacks2
quelque chose comme ci-dessous.Créez une classe
AppLifeCycleHandler
implémentant au-dessus desdites interfaces.Dans votre classe, qui étend l'
Application
implémentationAppLifeCycleCallback
pour obtenir les rappels lorsque l'application bascule entre le premier plan et l'arrière-plan. Quelque chose comme ci-dessous.J'espère que cela t'aides.
EDIT Comme alternative, vous pouvez maintenant utiliser le composant d'architecture sensible au cycle de vie.
la source
Comme je n'ai trouvé aucune approche, qui gère également la rotation sans vérifier les horodatages, j'ai pensé partager également comment nous le faisons maintenant dans notre application. Le seul ajout à cette réponse https://stackoverflow.com/a/42679191/5119746 est que nous prenons également en compte l'orientation.
Ensuite, pour les rappels, nous avons d'abord le CV:
Et onActivityStopped:
Et puis, voici l'ajout: Vérification des changements d'orientation:
C'est ça. J'espère que cela aide quelqu'un :)
la source
Nous pouvons étendre cette solution en utilisant
LiveData
:Maintenant, nous pouvons nous abonner à ce LiveData et attraper les événements nécessaires. Par exemple:
la source
Ces réponses ne semblent pas être correctes. Ces méthodes sont également appelées lorsqu'une autre activité commence et se termine. Ce que vous pouvez faire est de garder un indicateur global (oui, les globaux sont mauvais :) et définissez-le sur true chaque fois que vous démarrez une nouvelle activité. Réglez-le sur false dans le onCreate de chaque activité. Ensuite, dans la onPause, vous cochez ce drapeau. Si c'est faux, votre application se met en arrière-plan ou elle se fait tuer.
la source