Quitter une application est-il mal vu?

1154

En poursuivant ma tentative d'apprendre Android, je viens de lire ce qui suit :

Question: L'utilisateur a-t-il le choix de supprimer l'application à moins que nous ne mettions une option de menu pour la supprimer? Si une telle option n'existe pas, comment l'utilisateur met-il fin à l'application?

Réponse: (Romain Guy): L'utilisateur ne le fait pas, le système gère cela automatiquement. C'est à cela que sert le cycle de vie de l'activité (en particulier onPause / onStop / onDestroy). Quoi que vous fassiez, ne mettez pas de bouton d'application "Quitter" ou "Quitter". Il est inutile avec le modèle d'application d'Android. Cela est également contraire au fonctionnement des applications principales.

Hehe, pour chaque pas que je fais dans le monde Android, je rencontre une sorte de problème = (

Apparemment, vous ne pouvez pas quitter une application sous Android (mais le système Android peut très bien détruire totalement votre application à tout moment). Qu'est-ce qui se passe? Je commence à penser qu'il est impossible d'écrire une application qui fonctionne comme une "application normale" - que l'utilisateur peut quitter l'application quand il / elle décide de le faire. Ce n'est pas quelque chose sur lequel le système d'exploitation doit s'appuyer.

L'application que j'essaie de créer n'est pas une application pour Android Market. Ce n'est pas une application "grand usage" par le grand public, c'est une application métier qui va être utilisée dans un domaine commercial très étroit.

J'étais vraiment impatient de développer pour la plate-forme Android, car il résout un grand nombre de problèmes qui existent dans Windows Mobile et .NET. Cependant, la semaine dernière a été un peu un tournant pour moi ... J'espère que je n'ai pas à abandonner Android, mais ça n'a pas l'air très bien en ce moment = (

Existe-t-il un moyen pour moi de vraiment quitter l'application?

Ted
la source

Réponses:

1287

Cela finira par arriver à votre question, mais je veux d'abord aborder un certain nombre de questions que vous soulevez dans vos divers commentaires aux différentes réponses déjà données au moment de la rédaction de ce document. Je n'ai pas l'intention de changer d'avis - plutôt, ceux-ci sont là pour ceux qui viendront lire ce post à l'avenir.

Le fait est que je ne peux pas autoriser Android à déterminer quand mon application va être fermée. cela doit être le choix de l'utilisateur.

Des millions de personnes sont parfaitement satisfaites du modèle où l'environnement ferme l'application au besoin. Ces utilisateurs ne pensent tout simplement pas à «terminer» l'application Android, pas plus qu'ils ne pensent à «terminer» une page Web ou à «terminer» un thermostat.

Les utilisateurs d'iPhone sont à peu près de la même manière, en ce sens que le fait d'appuyer sur le bouton iPhone ne donne pas nécessairement l'impression que l'application a été interrompue, car de nombreuses applications iPhone reprennent là où l'utilisateur s'est arrêté, même si l'application a vraiment été arrêtée (puisque l'iPhone uniquement autorise une application tierce à la fois à l'heure actuelle).

Comme je l'ai dit ci-dessus, il y a beaucoup de choses qui se passent dans mon application (les données sont POUSSÉES sur l'appareil, les listes de tâches qui devraient toujours être là, etc.).

Je ne sais pas ce que signifie "des listes avec des tâches qui devraient toujours être là", mais les "données PUSHées sur l'appareil" sont une fiction agréable et ne doivent en aucun cas être faites par une activité. Utilisez une tâche planifiée (via AlarmManager) pour mettre à jour vos données pour une fiabilité maximale.

Nos utilisateurs se connectent et ne peuvent pas le faire chaque fois qu'ils reçoivent un appel téléphonique et Android décide de tuer l'application.

Il existe de nombreuses applications iPhone et Android qui traitent de cela. Habituellement, c'est parce qu'ils conservent les informations d'identification de connexion, plutôt que de forcer les utilisateurs à se connecter à chaque fois manuellement.

Par exemple, nous voulons vérifier les mises à jour lors de la fermeture de l'application

C'est une erreur sur n'importe quel système d'exploitation. Pour tout ce que vous savez, la raison pour laquelle votre application est «fermée» est que le système d'exploitation est en train de s'arrêter, puis votre processus de mise à jour échouera en cours de route. En général, ce n'est pas une bonne chose. Vérifiez les mises à jour au démarrage ou vérifiez les mises à jour de manière totalement asynchrone (par exemple, via une tâche planifiée), jamais à la sortie.

Certains commentaires suggèrent que le fait de cliquer sur le bouton de retour ne tue pas du tout l'application (voir le lien dans ma question ci-dessus).

Appuyer sur le bouton RETOUR ne "tue pas l'application". Il termine l'activité qui était à l'écran lorsque l'utilisateur a appuyé sur le bouton RETOUR.

Il ne doit se terminer que lorsque les utilisateurs souhaitent y mettre fin - jamais jamais autrement. Si vous ne pouvez pas écrire des applications qui se comportent comme ça dans Android, alors je pense qu'Android ne peut pas être utilisé pour écrire de vraies applications = (

Les applications Web non plus. Ou WebOS , si je comprends bien leur modèle (je n'ai pas encore eu l'occasion de jouer avec un). Dans tous ces cas, les utilisateurs ne "mettent fin" à rien - ils partent simplement. L'iPhone est un peu différent, en ce qu'il ne permet actuellement qu'une seule chose à exécuter à la fois (à quelques exceptions près), et donc le fait de quitter implique une interruption assez immédiate de l'application.

Existe-t-il un moyen pour moi de vraiment quitter l'application?

Comme tout le monde vous l'a dit, les utilisateurs (via BACK) ou votre code (via finish()) peuvent fermer votre activité en cours. Les utilisateurs n'ont généralement besoin de rien d'autre, pour les applications correctement écrites, pas plus qu'ils n'ont besoin d'une option "quitter" pour utiliser les applications Web.


Par définition, il n'y a pas deux environnements d'application identiques. Cela signifie que vous pouvez voir les tendances dans les environnements à mesure que de nouveaux surviennent et que d'autres s'enfouissent.

Par exemple, il y a un mouvement croissant pour essayer d'éliminer la notion de "fichier". La plupart des applications Web n'obligent pas les utilisateurs à penser aux fichiers. Les applications iPhone n'obligent généralement pas les utilisateurs à penser aux fichiers. Les applications Android n'obligent généralement pas les utilisateurs à penser aux fichiers. Etc.

De même, il existe un mouvement croissant pour tenter d'éliminer la notion de «résiliation» d'une application. La plupart des applications Web ne forcent pas l'utilisateur à se déconnecter, mais le déconnectent implicitement après une période d'inactivité. Même chose avec Android, et dans une moindre mesure, iPhone (et éventuellement WebOS).

Cela nécessite de mettre davantage l'accent sur la conception d'applications, de se concentrer sur les objectifs commerciaux et de ne pas s'en tenir à un modèle de mise en œuvre lié à un environnement d'application précédent. Les développeurs qui n'ont pas le temps ou l'envie de le faire seront frustrés par les nouveaux environnements qui brisent leur modèle mental existant. Ce n'est pas la faute de l'un ou l'autre environnement, pas plus que ce n'est la faute d'une montagne pour les tempêtes qui coulent autour d'elle plutôt que de la traverser.

Par exemple, dans certains environnements de développement, comme Hypercard et Smalltalk, l'application et les outils de développement étaient mélangés dans une seule configuration. Ce concept n'a pas fait grand bruit, en dehors des extensions de langage pour les applications (par exemple, VBA dans Excel , Lisp dans AutoCAD ). Les développeurs qui ont proposé des modèles mentaux qui supposaient l'existence d'outils de développement dans l'application elle-même ont donc dû soit modifier leur modèle, soit se limiter à des environnements où leur modèle resterait vrai.

Ainsi, lorsque vous écrivez:

Avec d'autres choses désordonnées que j'ai découvertes, je pense que le développement de notre application pour Android ne se fera pas.

Cela semblerait être pour le mieux, pour vous, pour le moment. De même, je vous déconseille de tenter de porter votre application sur le Web, car certains des mêmes problèmes que vous avez signalés avec Android se retrouvent également dans les applications Web (par exemple, pas de "résiliation"). Ou, à l' inverse, si un jour vous faites le port de votre application sur le Web, vous pouvez constater que le flux de l' application Web peut être une meilleure adéquation pour Android, et vous pouvez revenir sur un port Android à ce moment - là.

CommonsWare
la source
21
Une pensée qui a dérivé dans ma tête: si je réécrivais simplement l'application entière en tant que service et que je traite ce service comme l'application réelle - peut-être que cela fonctionnerait mieux? Ensuite, je pourrais "bousiller" les activités (tout comme Android le veut) pour simplement présenter les données contenues dans le service. Dans ce cas, je pourrais peut-être y conserver l'état de connexion et d'autres éléments. En utilisant startForeground (int, Notification), je peux presque empêcher Android de tuer le service ...?
Ted
66
"Veuillez noter que mes utilisateurs sont des professionnels, qui utilisent l'appareil dans le seul but d'utiliser l'application Im essayant de porter sur Android." En fait, vous avez indiqué le contraire ("ne peut pas faire cela chaque fois qu'ils reçoivent un appel téléphonique" - un "appel téléphonique" n'est pas votre application). De plus, à moins que vous ne construisiez votre propre appareil, vous ne pouvez pas empêcher les gens d'installer d'autres applications s'ils le souhaitent.
CommonsWare
25
@SomeCallMeTim: Non, ce n'est pas une raison valable d'utiliser killProcess(). C'est une raison valable pour écrire un meilleur code iOS.
CommonsWare
24
@CommonsWare: Désolé, mais c'est une réponse banale qui ne m'est d'aucune utilité. Je porte du code que je suis payé pour porter. Dois-je passer deux fois plus de temps à faire le portage, à réécrire leur code, ou à le faire de manière à réduire les coûts pour mon employeur, leur permettant de mettre plus de jeux sur Android plus tôt? C'est une question tout à fait académique de toute façon: ils ne veulent pas que j'apporte des changements aussi importants à leur moteur, car je ne peux pas tester les changements sur iOS. ET c'est tout simplement faux: il n'y a rien de "mauvais" à utiliser des motifs Singleton pour les objets appropriés. Android est juste des applications WRT NDK cassées.
SomeCallMeTim
10
@Ted pour une réinitialisation plus fiable, vous pouvez peut-être minimiser la quantité d'état stockée sur l'activité ou le service lui-même. Au lieu de cela, placez la plupart de l'état et du code dans une classe distincte que vous recréez "à partir de zéro" à chaque démarrage de l'activité ou du service.
Qwertie
290

Je voudrais juste ajouter une correction ici pour les futurs lecteurs de ce fil. Cette nuance particulière a échappé à ma compréhension depuis longtemps, donc je veux m'assurer qu'aucun d'entre vous ne fait les mêmes erreurs:

System.exit()ne tue pas votre application si vous avez plusieurs activités sur la pile. Ce qui se passe réellement, c'est que le processus est tué et immédiatement redémarré avec une activité de moins sur la pile. C'est également ce qui se produit lorsque votre application est tuée par la boîte de dialogue Forcer la fermeture, ou même lorsque vous essayez de tuer le processus à partir de DDMS. C'est un fait qui est entièrement non documenté, à ma connaissance.

La réponse courte est, si vous voulez quitter votre application, vous devez garder une trace de toutes les activités de votre pile et de finish()TOUTES celles-ci lorsque l'utilisateur veut quitter (et non, il n'y a aucun moyen de parcourir la pile d'activités , vous devez donc gérer tout cela vous-même). Même cela ne tue pas réellement le processus ou les références pendantes que vous pourriez avoir. Il termine simplement les activités. De plus, je ne sais pas si cela Process.killProcess(Process.myPid())fonctionne mieux; Je ne l'ai pas testé.

Si, d'un autre côté, il est normal que vous ayez des activités dans votre pile, il existe une autre méthode qui vous simplifie la tâche: Activity.moveTaskToBack(true)il suffit d'arrière-plan de votre processus et d'afficher l'écran d'accueil.

La réponse longue implique une explication de la philosophie derrière ce comportement. La philosophie est née d'un certain nombre d'hypothèses:

  1. Tout d'abord, cela ne se produit que lorsque votre application est au premier plan. S'il est en arrière-plan, le processus se terminera très bien. Cependant, s'il est au premier plan, le système d'exploitation suppose que l'utilisateur souhaite continuer à faire ce qu'il faisait. (Si vous essayez de tuer le processus à partir de DDMS, vous devez d'abord appuyer sur le bouton d'accueil, puis le tuer)
  2. Il suppose également que chaque activité est indépendante de toutes les autres activités. Cela est souvent vrai, par exemple dans le cas où votre application lance l'activité du navigateur, qui est entièrement distincte et n'a pas été écrite par vous. L'activité du navigateur peut être créée ou non sur la même tâche, selon ses attributs de manifeste.
  3. Il suppose que chacune de vos activités est entièrement autonome et peut être tuée / restaurée en un instant. (Je n'aime pas assez cette hypothèse particulière, car mon application a de nombreuses activités qui reposent sur une grande quantité de données mises en cache, trop volumineuses pour être sérialisées efficacement onSaveInstanceState, mais qu'est-ce qui va le faire?) Pour la plupart des applications Android bien écrites, cela devrait être vrai, car vous ne savez jamais quand votre application va être supprimée en arrière-plan.
  4. Le dernier facteur n'est pas tant une hypothèse, mais plutôt une limitation du système d'exploitation: tuer explicitement l'application est la même que le crash de l'application, et aussi la même chose qu'Android tuant l'application pour récupérer de la mémoire. Cela culmine dans notre coup de grâce: étant donné qu'Android ne peut pas savoir si l'application s'est arrêtée ou s'est écrasée ou a été tuée en arrière-plan, elle suppose que l'utilisateur veut revenir là où il s'était arrêté, et donc ActivityManager redémarre le processus.

Lorsque vous y pensez, cela convient à la plate-forme. Tout d'abord, c'est exactement ce qui se passe lorsque le processus est tué en arrière-plan et que l'utilisateur y revient, il doit donc être redémarré là où il s'était arrêté. Deuxièmement, c'est ce qui se passe lorsque l'application se bloque et présente la redoutable boîte de dialogue Forcer la fermeture.

Supposons que mes utilisateurs puissent prendre une photo et la télécharger. Je lance l'activité de caméra à partir de mon activité et lui demande de renvoyer une image. La caméra est poussée en haut de ma tâche actuelle (plutôt que d'être créée dans sa propre tâche). Si l'appareil photo a une erreur et qu'il se bloque, cela devrait-il entraîner le plantage de l'application entière? Du point de vue de l'utilisateur, seule la caméra est tombée en panne, et ils doivent être retournés à leur activité précédente. Ainsi, il redémarre simplement le processus avec toutes les mêmes activités dans la pile, moins la caméra. Étant donné que vos activités doivent être conçues de manière à pouvoir être tuées et restaurées en un rien de temps, cela ne devrait pas poser de problème. Malheureusement, toutes les applications ne peuvent pas être conçues de cette façon, il est doncun problème pour beaucoup d'entre nous, quoi que vous dise Romain Guy ou quelqu'un d'autre. Nous devons donc utiliser des solutions de contournement.

Donc, mon dernier conseil:

  • N'essayez pas de tuer le processus. Appelez finish()toutes les activités ou appelez moveTaskToBack(true).
  • Si votre processus se bloque ou est tué, et si, comme moi, vous avez besoin des données en mémoire qui sont maintenant perdues, vous devrez revenir à l'activité racine. Pour ce faire, vous devez appeler startActivity()avec une intention qui contient l' Intent.FLAG_ACTIVITY_CLEAR_TOPindicateur.
  • Si vous voulez tuer votre application du point de vue Eclipse DDMS, il vaut mieux ne pas être au premier plan, sinon elle redémarrera d'elle-même. Vous devez d'abord appuyer sur le bouton Accueil, puis tuer le processus.
Neil Traft
la source
8
En fait, depuis que j'ai recommencé avec Android, je termine toutes les activités (une seule activité est active à un moment donné), puis j'appelle System.exit (0); dans mon Service - et cela fonctionne comme je le veux aussi. Je sais que la plupart des gens disent "ne fais pas ça", mais j'obtiens exactement le comportement que je veux avec ce mouvement ...
Ted
13
Tuer le processus est parfois très utile - par exemple lors de l'écriture de jeux qui utilisent du code natif. Tuer le processus signifie libérer immédiatement toute la mémoire allouée au système.
Sulthan
10
Pour tous ceux qui s'en soucient, Process.killProcess montre exactement le même comportement que System.exit ()
PacificSky
6
Dérivez toutes les activités d'une base AtivityBase commune. Maintenez ensuite un indicateur pour forcer la fermeture de l'application, dans onResume, vérifiez si l'indicateur de fermeture forcée est défini. Si c'est le cas, appelez System.exit (0); Cela se répercutera sur toute la pile d'activités et fermera enfin l'application.
Nar Gar
12
Merci d'avoir fourni des réponses réelles ( moveTaskToBack()c'est ce que je cherchais). Tant de gens disent simplement "Non, vous êtes un idiot à jamais vouloir quitter votre application." sans même considérer qu'il peut y avoir des cas où vous le souhaitez (par exemple, échecs de connexion).
Timmmm
180

Toutes mes applications ont des boutons Quitter ... et je reçois assez souvent des commentaires positifs des utilisateurs à cause de cela. Je me fiche que la plate-forme ait été conçue de manière à ce que les applications n'en aient pas besoin. Dire «ne les mettez pas là» est un peu ridicule. Si l'utilisateur veut quitter ... je lui donne l'accès pour faire exactement cela. Je ne pense pas que cela réduit le fonctionnement d'Android et cela semble être une bonne pratique. Je comprends le cycle de vie ... et mon observation a été qu'Android ne fait pas un bon travail pour le gérer ... et c'est un fait fondamental.

androidworkz
la source
15
+1 parce que malheureusement, il ne fait pas du bon travail à ce stade (mais je veux quand même essayer de faire les choses comme prévu, donc cela me met dans un dilemme)
Richard Le Mesurier
25
Quel mécanisme utilisez-vous pour arrêter?
Gary Rudolph
4
@Igor finish () - les activités ne tuent pas l'application (étend l'application). Ainsi, même lorsqu'aucune des activités n'était active, les paramètres sont toujours actifs et réels, de sorte que lorsque les activités tentent d'y accéder, ce sont celles qui ont été utilisées auparavant. System.exit (0); d'autre part, tue l'application, de sorte que lorsqu'elle sera redémarrée, l'application devra réinitialiser les paramètres à nouveau. C'est ce dont j'ai besoin lors de la mise à jour manuelle de mon application, car je change fréquemment le format des données et j'ai besoin qu'elles soient réactivées immédiatement.
Nar Gar
1
Eh bien, c'est la seule façon d'accomplir ce dont j'ai besoin pour le moment. J'utilise system.exit lorsque l'application est mise à jour (sinon j'obtiendrai des exceptions de sérialisation ou de conversion de classe en fonction de mes modifications de code). Je dois cependant mentionner que je ne donne pas à l'utilisateur une poignée d'interface utilisateur pour tuer l'application via system.exit - il est réservé pour moi en tant qu'ingénieur de l'application à utiliser uniquement lorsque l'application doit absolument décharger complètement. Le reste du temps, une simple finition () (ou l'opération par défaut du bouton de retour) est utilisée.
Nar Gar
13
Ouais .. au diable avec 'pas la norme Android' .. Android est puissant car il permet aux gens d'expérimenter .. S'il fournit des API pour faire quelque chose, comment peut-on dire que ce n'est pas la norme Android? Je ne peux pas digérer toutes ces réponses «philosophiques». Vous faites en sorte que l'application garde à l'esprit vos utilisateurs. s'ils sont heureux ou s'ils veulent voir cette fonctionnalité, alors il est tout à fait correct de l'implémenter même si ces soi-disant philosophes sont contre.
Rahul
144

Arrêtez de considérer votre application comme une application monolithique. Il s'agit d'un ensemble d'écrans d'interface utilisateur que l'utilisateur peut interagir avec votre "application" et les "fonctions" fournies via les services Android.

Ne pas savoir ce que fait votre mystérieuse application n'est pas vraiment important. Supposons qu'il se transforme en un intranet d'entreprise super sécurisé, effectuant une surveillance ou une interaction et reste connecté jusqu'à ce que l'utilisateur "quitte l'application". Parce que votre service informatique le commande, les utilisateurs doivent être très conscients du moment où ils sont IN ou OUT de l'intranet. D'où votre état d'esprit qu'il est important pour les utilisateurs de "quitter".

C’est simple. Créez un service qui place une notification en cours dans la barre de notification en disant "Je suis sur l'intranet ou je suis en cours d'exécution" Demandez à ce service d'exécuter toutes les fonctionnalités dont vous avez besoin pour votre application. Ayez des activités qui se lient à ce service pour permettre à vos utilisateurs d'accéder aux bits de l'interface utilisateur dont ils ont besoin pour interagir avec votre "application". Et disposez d'un bouton Menu Android -> Quitter (ou déconnecter, ou autre) qui indique au service de quitter, puis ferme l'activité elle-même.

C'est, à toutes fins utiles, exactement ce que vous dites vouloir. Fait la manière Android. Regardez Google Talk ou Google Maps Navigation pour des exemples de cette "sortie" est une mentalité possible. La seule différence est que le fait d'appuyer sur le bouton de retour de votre activité peut laisser votre processus UNIX en attente au cas où l'utilisateur voudrait relancer votre application. Ce n'est vraiment pas différent d'un système d'exploitation moderne qui met en cache les fichiers récemment accédés en mémoire. Après avoir quitté votre programme Windows, les ressources dont il avait probablement besoin sont toujours en mémoire, en attente d'être remplacées par d'autres ressources car elles sont chargées maintenant qu'elles ne sont plus nécessaires. Android, c'est la même chose.

Je ne vois vraiment pas votre problème.

Eric
la source
3
@Eric, vous ne voyez pas le problème car vous vous en éloignez. Vous avez simplement utilisé un autre programme qui fonctionne sur l'ancien "modèle de programme" pour faire ce qui ne peut pas être fait par le "modèle Android". Pour voir le problème avec le "modèle Android", vous devez imaginer que vous n'avez pas le luxe de déléguer des tâches à des boîtiers Linux / Windows. Vous devez imaginer que vous êtes obligé de tout faire du front-end au back-end avec seulement des boîtes qui exécutent le "modèle Android". Ensuite, vous verrez que les limitations du "modèle Android" sont aussi claires que le ciel.
Pacerier
considérez votre application comme une application monolithique. Il est écrit en java qui est exécuté par un seul processus JVM (Java Virtual Machine). System.exit () quitte la JVM et termine complètement et complètement tous les écrans d'interface utilisateur et tout. L'exception à cela est SI le programmeur se donne la peine de configurer plusieurs threads qui s'exécutent dans plusieurs processus - mais par défaut, ce n'est PAS le cas, et selon Google, cela ne devrait pas se faire normalement.
Jesse Gordon
@JesseGordon Ce n'est tout simplement pas vrai. System.exit()supprime uniquement une activité de la pile. La JVM est immédiatement réinitialisée. Voir cette réponse .
forresthopkinsa
1
@forresthopkinsa OK, je l'ai testé sur Android 7.0. Une application simple à thread unique s'exécute toujours dans sa propre instance JVM dédiée, en tant qu'ID utilisateur unique pour cette application. Je n'ai pas encore essayé une application multi-thread pour ce test. Et System.exit () STILL tue TOUJOURS la JVM entière pour cette application. Si System.exit () est appelé à partir de l'activité principale, il se ferme simplement. Si System.exit () est appelé à partir d'une sous-activité, la JVM est toujours tuée, mais Android la redémarre sous un nouvel ID de processus à l'activité principale / première. android.os.Process.killProcess (android.os.Process.myPid ()); et tuer <pid> fonctionne de la même manière.
Jesse Gordon
1
Intéressant .. En regardant la réponse que vous avez liée, @forresthopkinsa, il semble qu'Android se comporte comme des navigateurs Web, en restaurant les activités après un system.exit afin que l'utilisateur ne le remarque pas, mais en excluant l'activité qui a provoqué la sortie. .? Bizarre. Mais de toute façon, System.exit () fait près toutes les activités et free () est la mémoire et met fin à la machine virtuelle Java pour cette application. Mais je n'ai aucune idée de ce que fait Android pour le redémarrer / restaurer. Est-ce pour contrecarrer les applications qui tuent les applications? Donc je suppose que si quelqu'un veut un bouton de sortie, il devrait le mettre dans l'activité principale.
Jesse Gordon
71

Il s'agit d'un débat intéressant et perspicace auquel participent de nombreux experts. Je pense que ce message devrait être bouclé à partir du site Web principal de développement Android, car il tourne autour de l'une des conceptions principales du système d'exploitation Android.

Je voudrais également ajouter mes deux cents ici.

Jusqu'à présent, j'ai été impressionné par la façon dont Android gère les événements du cycle de vie, apportant le concept d'une expérience de type Web aux applications natives.

Cela dit, je pense toujours qu'il devrait y avoir un Quitbouton. Pourquoi? ... pas pour moi, ni Ted ni aucun des gourous de la technologie ici, mais dans le seul but de répondre à la demande d'un utilisateur final.

Bien que je ne sois pas un grand fan de Windows, mais il y a longtemps, ils ont introduit un concept auquel la plupart des utilisateurs finaux sont habitués (un bouton X) ... "Je veux arrêter d'exécuter un widget quand je le veux".

Cela ne signifie pas que quelqu'un (OS, développeur?) S'en chargera à sa discrétion ... cela signifie simplement "où est mon bouton Red X auquel je suis habitué". Mon action devrait être analogue à «mettre fin à un appel en appuyant sur un bouton», «éteindre l'appareil en appuyant sur un bouton», etc., c'est une perception. Cela apporte une satisfaction en soi que mon action atteigne effectivement son but.

Même si un développeur peut usurper ce comportement en utilisant les suggestions données ici, la perception demeure, c'est-à-dire qu'une application devrait complètement cesser de fonctionner (maintenant), par une source (OS) indépendante, fiable et neutre à la demande de l'utilisateur final.

Paul
la source
2
Droite. Bon vieux Windows Mobile offrait le même bouton X que les PC Windows, sauf qu'il ne quittait pas réellement l'application, il la «minimisait» intelligemment. De nombreux utilisateurs n'ont probablement jamais découvert que l'application n'avait pas vraiment quitté. (L'approche a très bien fonctionné, bien que si vous avez utilisé .NET Compact Framework, l'application n'a pas été informée que cela s'était produit et n'a donc pas eu la possibilité de libérer des ressources ou de quitter.)
Qwertie
3
Vraiment, cela revient à mentir à vos utilisateurs pour leur donner une sensation chaleureuse et floue. En fin de compte, il vaut mieux laisser les reliques du passé tomber au bord du chemin, de peur qu'elles ne restent des éléments permanents de la technologie. Le mobile et le Web sont de nouvelles plates-formes et ne devraient pas se comporter de la même manière que les ordinateurs de bureau. Et pour l'anecdote, au moins, les décisions de cycle de vie d'Android semblent prendre le pas sur les utilisateurs: alors que ma plus grande application passe son anniversaire de 2 ans, j'ai remarqué que le flux de demandes des utilisateurs finaux pour les boutons de «sortie» s'asséchait à mesure qu'ils s'habituaient à la nouvelle plateforme.
Jon O
2
@Jon Que recommandez-vous? Vous ne proposez pas d'option de sortie n'importe où dans l'application?
IgorGanapolsky
Eh bien, lorsqu'un utilisateur a demandé un bouton de sortie, je leur expliquais précisément comment les choses fonctionnaient différemment que sur un bureau (ce qui est la même explication que je leur donne quand ils mentionnent des tueurs de tâches). Maintenant, les informations semblent avoir fait leur chemin et je ne reçois plus ces demandes. Donc, je vous recommande de l'expliquer plusieurs fois (peut-être de trouver une réponse standardisée) et de laisser de côté le bouton. Ou mettez un faux bouton de sortie qui ouvre une boîte de dialogue expliquant pourquoi il n'y a plus de boutons de sortie. : D (Également dans Android 4+, un utilisateur peut faire glisser une application "hors" de l'affichage multitâche pour la "tuer".)
Jon O
3
Je n'ai pas non plus trouvé le raisonnement derrière tous les conseils disant "ne tuez pas le processus". À mon avis, le client a toujours raison, alors qu'y a-t-il de mal à fournir un bouton de sortie une fois qu'il a été demandé et à "mentir à vos utilisateurs pour leur donner une sensation chaleureuse et floue", si c'est ce qu'ils veulent? C'est en partie ce qu'est l'écriture de bonnes applications. La plupart des utilisateurs ne savent pas ou ne se soucient pas de ce qui se passe vraiment sous le capot, mais s'ils aiment votre application et font ce qu'ils veulent et attendent, ils reviendront et achèteront plus de vos applications. C'est ce que nous voulons tous, non? Ou est-ce que je manque quelque chose?
DDSports
37

Vous pouvez quitter, soit en appuyant sur le Backbouton, soit en appelant finish()votre Activity. Appelez simplement finish()un MenuItemsi vous voulez le supprimer explicitement.

Romain ne dit pas que cela ne peut pas être fait, juste que c'est inutile - les utilisateurs n'ont pas besoin de se soucier de quitter ou d'enregistrer leur travail ou quoi que ce soit, car la façon dont le cycle de vie de l'application fonctionne vous encourage à écrire un logiciel intelligent qui enregistre et restaure son état quoi qu'il arrive.

Christopher Orr
la source
5
Ce n'est pas inutile s'il remplit un objectif, et dans notre application, il fait exactement cela. Par exemple, nous voulons vérifier les mises à jour lors de la fermeture de l'application. Nous ne pouvons pas quitter l'application, aucune mise à jour ne peut être effectuée. Certains commentaires suggèrent que le fait de cliquer sur le bouton de retour ne tue pas du tout l'application (voir le lien dans ma question ci-dessus).
Ted
2
Comme le dit Romain, ce n'est pas ainsi que fonctionnent les applications principales. Donc, si les utilisateurs ont l'habitude d'appuyer sur «Retour» pour quitter une application, il semble probable qu'ils continueront à le faire avec votre application plutôt que de choisir explicitement Quitter? Vous pouvez faire une vérification de mise à jour au démarrage, ou onDestroy (), ou en utilisant une alarme répétée .. cela ne semble pas être quelque chose qui nécessite d'être déclenché par un utilisateur.
Christopher Orr
1
Tom: Je code pour Windows Mobile depuis près de 5 ans maintenant. C'est un téléphone avec des "ressources limitées". Il n'y a pas un tel comportement là-bas, et il n'y a pas de problème qu'il n'agisse pas non plus dans ce "grand frère". "Real apps" = où le programmeur a beaucoup plus de contrôle dessus, c'est-à-dire en quittant, quand les éléments de l'interface graphique sont supprimés etc ...
Ted
1
Jay: parce que si c'est toujours en mémoire, je ne peux pas mettre à jour l'application. Impossible de supprimer les fichiers en cours d'utilisation, non? Je veux mettre à jour à la sortie car nous ne pouvons pas forcer nos utilisateurs à mettre à jour au démarrage. Cela a à voir avec leur fonctionnement et leurs besoins. Ce n'est pas OK pour eux d'être forcés de faire une mise à jour au début de leur quart de travail pour différentes raisons. C'est un peu compliqué.
Ted
1
Jay: Non, comme je l'ai dit ci-dessus, ce n'est PAS une application de marché, et ça ne le sera pas non plus. C'est une application très spécialisée, pas pour un usage général.
Ted
31

Ce débat se résume à la question séculaire de savoir si les développeurs connaissent le mieux ou si l'utilisateur le sait le mieux. Les concepteurs professionnels dans tous les domaines des facteurs humains sont confrontés à cela tous les jours.

Ted a fait valoir que l'une des applications les plus téléchargées sur le marché est l '«App Killer». Les gens reçoivent un peu de sérotonine supplémentaire lorsqu'ils quittent les applications. Ils y sont habitués avec un ordinateur de bureau / portable. Cela fait avancer les choses rapidement. Il garde le processeur frais et le ventilateur de se mettre en marche. Il utilise moins d'énergie.

Lorsque vous considérez qu'un appareil mobile est un navire beaucoup plus petit, vous pouvez particulièrement apprécier leur incitation à «jeter par-dessus bord ce dont vous n'avez plus besoin». Maintenant, les développeurs d'Android ont estimé que le système d'exploitation était le plus efficace et que quitter une application était ancien. J'appuie sans réserve cela.

Cependant, je pense également que vous ne devez pas frustrer l'utilisateur, même si cette frustration est née de sa propre ignorance. Pour cette raison, je conclus qu'avoir une option «Quitter» est une bonne conception, même si c'est surtout un bouton placebo qui ne fait que fermer une vue.

Peter Mortensen
la source
8
Oui, avoir un bouton «Quitter» est en effet convivial. Sinon, comment l'utilisateur quitterait-il l'application s'il avait 5 activités profondes? Bien sûr, ils peuvent appuyer plusieurs fois, mais je ne pense pas qu'ils aimeraient ça.
IgorGanapolsky
4
Seulement 5? Le navigateur Web Android 2.2 me fait passer quelques minutes à appuyer sur le bouton de retour jusqu'à ce que je quitte finalement
Joe Plante
3
Je commencerais à écouter les développeurs d'Android lorsqu'ils développent un gestionnaire de mémoire qui FONCTIONNE. À partir de Froyo, cela a fonctionné extrêmement mal, tuant des applications aléatoires, redémarrant des applications qui n'ont pas besoin d'être (et n'ont aucune intention de les démarrer légitimement), et OTOH, ralentissant à une analyse COMPLÈTE lorsque la mémoire atteint 50 Mo d'espace libre.
DVK
10
Lorsque votre religion dit qu'Android Task Killer n'est "pas nécessaire", mais l'utilisation d'ATK pour tuer les tâches stupides qui n'ont aucune activité en cours change le système d'exploitation de l'exploration à ~ 1-5% de la vitesse normale pour revenir à 100% de la vitesse normale ( mesurée) 100% du temps sur des milliers d'utilisations d'ATK sur 2 ans chaque fois que le système atteint 50 Mo de bas de gamme gratuit, votre religion est erronée
DVK
@JoePlante Vous pouvez d'abord fermer tous les onglets et fenêtres ouverts, puis appuyer simplement une fois sur le bouton Retour pour quitter :) Au moins sur ma GS2.
ldam
29

Ted, ce que vous essayez d'accomplir peut être fait, peut-être tout simplement pas comment vous y pensez maintenant.

Je vous suggère de lire sur les activités et services. Arrêtez d'utiliser le terme «application» et commencez à vous référer aux composants, c'est-à-dire l'activité, le service. Je pense que vous avez juste besoin d'en savoir plus sur la plate-forme Android; c'est un changement de mentalité par rapport à une application PC standard. Le fait qu'aucun de vos messages ne contienne le mot «activité» (à part une citation de FAQ, c'est-à-dire pas vos mots), me dit que vous devez en lire davantage.

Peter Mortensen
la source
J'ai lu la plupart des trucs sur android.com =) et je peux créer un lien vers plusieurs de mes questions où je parle d'activités, donc ce n'est pas vrai (ex: stackoverflow.com/questions/2032335/… ou stackoverflow.com/questions/ 2032335 /… etc ...) Cependant, je pourrais essayer une dernière fois et essayer de créer l'appli who en tant que Servce ...
Ted
4
Une application peut contenir des services et des activités, et il semble que votre application puisse avoir besoin des deux. L'activité n'est que la partie UI.
Aaron
23

L'article de blog Quand inclure un bouton de sortie dans les applications Android (indice: jamais) l' explique bien, bien mieux que moi. Je souhaite que chaque développeur Android l'ait déjà lu.

Extraits:

D'après mon expérience, ce que [les utilisateurs] veulent vraiment est: un moyen sans équivoque de garantir qu'une application cessera de consommer des ressources (batterie, cycles CPU, transfert de données, etc.).

De nombreux utilisateurs perçoivent qu'un bouton de sortie met en œuvre cette exigence et demandent à ce qu'il soit ajouté. Les développeurs, soucieux de plaire à leurs utilisateurs, en ajoutent obligatoirement un. Peu de temps après, ils échouent tous les deux.

  • Dans la plupart des cas, le bouton de sortie appelle simplement Activity.finish(). Cela équivaut exactement à appuyer sur le bouton de retour. Exactement. Les services continuent de fonctionner et le sondage continue. Les utilisateurs peuvent penser qu'ils ont tué l'application, mais ils ne l'ont pas fait, et bientôt ils seront encore plus ennuyés.
  • Le comportement de sortie est désormais ambigu. Votre bouton de sortie doit-il simplement fermer l'activité ou doit-il également arrêter tous les services, récepteurs et alarmes associés? Que faut Back- il faire? Que se passe-t-il s'ils frappent à la Homeplace? Que se passe-t-il si votre application dispose d'un widget? Le bouton de sortie devrait-il également empêcher la mise à jour?

La solution consiste à faire en sorte que le bouton de retour se comporte comme vous vous en doutez. Mieux encore, arrêtez simplement de consommer des ressources lorsque l'application n'est pas visible.

Allez-y et lisez l'article complet.

Dheeraj VS
la source
3
Exit et Back ne sont pas toujours utilisés dans le même but. Prenez, par exemple, Pandora. Lorsque vous appuyez sur pour quitter cette application, elle ne quitte pas l'application (la conserve en arrière-plan en tant que service).
IgorGanapolsky
@IgorG. Une application de lecteur de musique a besoin d'un bouton "Stop" pour arrêter la lecture de la musique, pas d'un bouton "Quitter" pour quitter l'application.
Dheeraj Vepakomma
Avez-vous déjà utilisé Pandora, iHeartRadio, Spotify, Jango et d'autres applications de streaming musical? Ils ont tous un bouton Quitter. Arrêter la lecture de musique N'EST PAS LA MÊME CHOSE que de quitter une application. Surtout si vous avez un service en cours d'exécution dans la barre de notification.
IgorGanapolsky
2
Mythique ou non, utilisateurs primitifs ou non, mais presque tous les logiciels d'interface utilisateur jamais écrits - sur n'importe quelle plate-forme et système d'exploitation - implémentent un bouton Quitter / Fermer / Quitter. Sinon, comment le mettriez-vous en œuvre?
IgorGanapolsky
3
@ DheerajV.S., Arrêtez simplement de consommer des ressources lorsque l'application n'est pas visible? Mauvais conseil. Très. Très x99. Chaque fois que j'essaie de m'envoyer une photo par e-mail, je dois garder l'application visible pendant 5 minutes, car si je la minimise, elle arrête d'envoyer la photo par e-mail. Correct, je ne peux pas utiliser mon téléphone pendant 5 minutes uniquement à cause d'un développeur qui pense que les applications ne devraient s'exécuter que lorsqu'elles sont visibles. Imaginez maintenant envoyer un fichier plus gros comme une vidéo .....
Pacerier
21

Réponse: (Romain Guy): L'utilisateur ne le fait pas, le système gère cela automatiquement. C'est à cela que sert le cycle de vie de l'activité (en particulier onPause / onStop / onDestroy). Quoi que vous fassiez, ne mettez pas de bouton d'application "Quitter" ou "Quitter". Il est inutile avec le modèle d'application d'Android. Cela est également contraire au fonctionnement des applications principales.

1: La fermeture totale d'une application peut être généralement non obligatoire, mais elle n'est pas inutile. Et si Windows n'avait pas d'option de sortie? Le système serait lent comme la mémoire était pleine et le système d'exploitation devait deviner avec quels programmes vous aviez fini. Peu m'importe ce que disent Romain Guy ou même Larry Page et Sergey Brin - ce sont des faits incontestables: les systèmes fonctionnent plus lentement lorsqu'ils doivent tuer des tâches pour obtenir leur mémoire avant qu'une nouvelle application puisse être lancée. Vous ne pouvez tout simplement pas me dire qu'il ne faut pas de temps pour tuer une application! Même la lumière des étoiles lointaines prend du temps ... Il est utile de permettre à l'utilisateur de fermer complètement les applications.

2: Contrairement au fonctionnement des applications principales? Qu'est ce que c'est censé vouloir dire? Quand j'ai fini d'exécuter une application pour l'instant, elle ne fait plus de travail ... Elle attend juste d'être tuée par le système d'exploitation lorsque sa mémoire est nécessaire.

En résumé, il existe une différence distincte entre la minimisation et la sortie, et aucune pincée ne frappe bien l'autre. Laissons-nous un tournevis dans chaque vis? Ou une clé à chaque porte? Laissons-nous tous nos appareils en haut jusqu'à ce que le disjoncteur saute et que nous devons allumer un autre appareil? Laissons-nous le lave-vaisselle plein de vaisselle et n'en prenons-nous que suffisamment à chaque fois pour faire de la place pour de nouveaux sales? Laissons-nous toutes les voitures rouler dans l'allée jusqu'à - oh tant pis.

Si l'utilisateur souhaite minimiser une application, la meilleure chose à faire est de la minimiser. Si un utilisateur veut quitter une application, il est préférable de quitter.

Est-il mal vu? C'est le point de vue d'Android - ils froncent les sourcils. Et beaucoup de développeurs Android débutants indépendants froncent les sourcils.

Mais en fin de compte, il y a un bon codage et un mauvais codage. Il existe de bons modèles de flux de programmes et de mauvais modèles de flux de programmes.

Laisser des programmes en mémoire lorsque l'utilisateur sait qu'ils en ont fini avec eux n'est tout simplement pas un bon flux de programme. Il ne sert absolument à rien et ralentit les choses lorsque vous lancez de nouvelles applications ou lorsque vous exécutez des applications allouez plus de mémoire.

C'est un peu comme votre voiture: il y a des moments où vous la laissez tourner, comme s'arrêter à un feu stop, ou peut-être le fast-food, ou s'arrêter au guichet automatique. Mais il y a d'autres situations où vous voulez le fermer - comme lorsque vous arrivez au travail, à l'épicerie ou même à la maison.

De même, si vous jouez à un jeu et que le téléphone sonne, oui. Mettez le jeu en pause et continuez à le faire fonctionner. Mais si l'utilisateur en a fini avec le jeu pendant un certain temps, alors laissez-le sortir.

Le bouton de sortie de certaines applications devrait être plus en avant que d'autres. Les jeux, par exemple, ou les programmes où l'utilisateur est susceptible de vouloir quitter complètement, devraient avoir une sortie évidente. D'autres programmes, comme, peut-être, les programmes de messagerie électronique, où la sortie est un désir improbable (afin qu'il puisse continuer à vérifier les e-mails) - ces programmes ne devraient pas gaspiller l'espace de l'écran de contrôle principal avec une option de sortie, mais pour un bon flux de programme, il devrait avoir une option de sortie. Que se passe-t-il si quelqu'un décide qu'il ne veut pas que son programme de messagerie essaie de vérifier ses e-mails lorsqu'il se trouve dans une zone de couverture médiocre, ou peut-être lors d'un appel Skype ou autre? Laissez-les quitter le programme de messagerie s'ils le souhaitent!

La suspension et la sortie sont deux tâches vitales et aucune ne remplit le rôle de l'autre.

Jesse Gordon
la source
2
"Si l'utilisateur veut minimiser une application, alors la meilleure chose est de la minimiser. Si un utilisateur veut quitter une application, alors il est préférable de quitter." - Il y a une chose (basée sur plus d'une décennie d'expérience): les utilisateurs savent rarement ce qu'ils veulent. Si vous ne les aidez pas, vous devrez le changer. À propos des échantillons ci-dessus: laissez-moi vous donner un autre échantillon: vous travaillez sur une voiture et avez une table à portée de main pour les choses. Mettez-vous toujours de côté pour placer correctement tous les outils nécessaires dans l'armoire ou gardez-vous les plus utilisés à portée de main? Et juste mettre de côté un gros gros utilisé pour avoir de la place pour de nouveaux?
HoGo
4
HoGo, merci pour votre commentaire. Naturellement, je ne suis pas d'accord. Plus précisément, autant que je sache, votre point de vue est que, puisque certains utilisateurs ne savent pas ce qu'ils doivent faire, ne laissez donc aucun utilisateur faire ce qu'il doit faire, pas même ceux qui savent ce qu'il doit faire. Si Android avait un moyen de savoir avec précision s'il devait mettre fin à une application au lieu de la minimiser, alors très bien. Mais ce n'est pas le cas, et forcer tous les utilisateurs à toujours vivre avec la minimisation lorsqu'ils veulent quitter conduit à de mauvaises performances de l'appareil.
Jesse Gordon
Le fait est que le système sait que lorsque vous démarrez une application et qu'il n'y a pas de mémoire, elle devrait tuer la dernière. L'utilisateur ne devrait pas savoir cela. Vous ne le voulez que parce que vous êtes un humain qui aime l'abandon du contrôle, sa mémoire musculaire juste stupide, son contrôle même inutile d'avoir à fermer des programmes. Les ordinateurs ont été inventés pour automatiser, j'aimerais plus que Windows fonctionne comme Android et se ferme automatiquement pour moi, mais je dois me rappeler d'enregistrer et de quitter, c'est idiot, pourquoi devrais-je, l'utilisateur, faire ça? les ordinateurs doivent gérer leur mémoire, j'ai d'autres choses à gérer.
Luiz Felipe
En fait, je ne ferme pas les programmes sur ma machine Windows, j'ai 32 Go de RAM, je laisse tout fonctionner, je les ferme lorsque je termine mon travail. Pourquoi fermer le programme, l'ouvrir à nouveau 5 minutes plus tard, cela n'a aucun sens. Pensez à un grand projet C ++ qui prend 2 minutes pour devenir réactif, je laisse simplement Visual Studio ouvert pour toujours. Et je m'attends à ce qu'il ne plante pas non plus après 15 jours d'ouverture (et oui, j'utilise de la mémoire ECC pour cela).
Luiz Felipe
L'analogie avec l'atelier d'usinage est bonne, je laisse également les outils les plus utilisés sur mon bureau, je ne prends pas l'outil, je ne l'utilise pas et je le remets à chaque fois. De plus, je ne démarre pas la journée, j'allume l'ordinateur, j'attends qu'il démarre, j'ouvre IDE, peu importe. Je le laisse juste en marche, l'ordinateur moderne peut tourner au ralenti à 40w, pourquoi fermer? il porte aussi moins les composants (pas de courant d'appel, les EE le savent :))
Luiz Felipe
19

Je pense que le fait est qu'il n'est pas nécessaire de quitter l'application à moins d'avoir un logiciel buggy. Android quitte l'application lorsque l'utilisateur ne l'utilise pas et que l'appareil a besoin de plus de mémoire. Si vous avez une application qui doit exécuter un service en arrière-plan, vous souhaiterez probablement un moyen de désactiver le service.

Par exemple, Google Listen continue de lire le podcast lorsque l'application n'est pas visible. Mais il y a toujours le bouton pause pour désactiver le podcast lorsque l'utilisateur en a terminé. Si je me souviens bien, Listen, met même un raccourci dans la barre de notification pour que vous puissiez toujours accéder rapidement au bouton pause. Un autre exemple est une application comme une application Twitter par exemple qui interroge en permanence un service sur Internet. Ces types d'applications devraient vraiment permettre à l'utilisateur de choisir la fréquence d'interrogation du serveur, ou même d'interroger dans un thread d'arrière-plan.

Si vous avez besoin d'un code qui s'exécute à la sortie, vous pouvez remplacer onPause (), onStop () ou onDestroy () selon le cas. http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

Jay Askren
la source
5
Avec d'autres choses désordonnées que j'ai découvertes, je pense que le développement de notre application pour Android ne se fera pas. C'est trop "grand frère" - tout se passe, où Android me dit quelle application devrait fonctionner ou non. En tant que programmeur, je devrais avoir ce choix, pas google ou android = (
Ted
3
Vos activités - l'interface utilisateur active - disparaissent lorsqu'une autre application arrive en haut, ou que vous appuyez en arrière ou quoi que ce soit. L'utilisateur n'interagit pas avec eux, il est donc plus sûr de sauvegarder l'état au cas où l'utilisateur ne reviendrait pas pendant longtemps, et ainsi de suite, comme vous le savez. Rien ne vous empêche d'écrire une Servicenote pour que le travail en cours se déroule en arrière-plan, comme recevoir des push de données ou autre chose. Google Talk ne s'arrête pas de fonctionner lorsque vous utilisez une autre application. Même chose avec le lecteur de musique. Regardez les autres applications et leur fonctionnement.
Christopher Orr
3
Vous devriez pouvoir enregistrer les informations d'identification afin que les utilisateurs n'aient pas besoin de se connecter à chaque fois qu'ils reçoivent un appel téléphonique ou s'éloignent de votre application. Je recommanderais de regarder le cycle de vie d'Android. Lorsque l'application est suspendue, arrêtée ou détruite, vous pouvez enregistrer toutes les données pertinentes de sorte que lorsque l'application se rouvrira, ce sera comme elles l'ont quitté. L'utilisateur n'a même pas besoin de savoir que l'application a été arrêtée.
Jay Askren
1
Je peux imaginer qu'un utilisateur peut vouloir quitter certaines applications très gourmandes en ressources. Peut-être qu'il devrait simplement réduire son utilisation des ressources lorsqu'il est en pause, mais cela pourrait ne pas toujours être possible
Casebash
1
Cette question est toujours vivante, je vois, 4 ans après l'avoir soulevée =) Je l'ai effectivement exécutée en tant que service en arrière-plan, mais j'ai ajouté le bouton Quitter, car je me sens toujours - 4 ans plus tard - c'est nécessaire et important. Et je vois de plus en plus d'applications qui ont ça aussi (Skype par exemple).
Ted
19

Si vous ne parvenez pas à comprendre comment rendre vos données / connexions (et donc votre "application") persistantes, vous ne pourrez pas faire ce que vous "devez" faire avec Android.

Ceux qui téléchargent ces petits App Killers mignonnes trouvent généralement qu'ils n'aident pas la durée de vie de la batterie ou l'utilisation de la mémoire, mais empêchent le système d'exploitation de faire son travail de gestion efficace de la mémoire ...

http://android-developers.blogspot.com/2010/04/multitasking-android-way.html

Dan
la source
Alors que nous parlons de tueurs de tâches, un article très instructif est apparu sur le reddit Android il y a quelques jours. L'essentiel est d'utiliser les tueurs de tâches avec soin ou vous pourriez en fait finir par nuire à la vie de votre batterie: reddit.com/r/Android/comments/cwhm6/…
Neil Traft
@Neil Traft, j'ai trouvé les commentaires sur le post très instructifs. Les représentants des magasins recommandent et installent des tueurs de tâches pour leurs clients :)
dipu
3
@Dan, comment est-il même possible à distance que je quitte complètement une application avec laquelle j'ai terminé pendant une semaine entrave Android OS de son travail? Il y a donc plus de mémoire libre. Cela ne peut pas gêner Android! Mais cela pourrait accélérer les choses plus tard! Si je sais que j'en ai fini avec l'application pendant un certain temps, cela ne sert absolument à rien. Cela ne prend que de la mémoire, et tôt ou tard, je lancerai une nouvelle application et le système d'exploitation aura un délai supplémentaire car il doit aller tuer certaines applications que je connaissais il y a des SEMAINES et dont j'avais fini.
Jesse Gordon
@Jesse Gordon, Avez-vous regardé les processus réels après avoir tué une application? Ils sont redémarrés, le système d'exploitation suppose qu'il y avait un problème ... Le système d'exploitation tuera les applications lorsqu'il a besoin de mémoire. Avez-vous même lu quelque chose publié dans les articles mentionnés ici?
Dan
@Dan, penser qu'Android ferait quelque chose comme ça ... il a vraiment besoin d'une sérieuse rééducation au blanchiment.
Pacerier
18

J'envisagerais de lire "Android Wireless Application Development" publié par Addison-Wesley. Je suis en train de le terminer et c'est TRÈS complet.

Il semble que vous ayez des malentendus fondamentaux sur la plate-forme Android. Moi aussi, j'étais un peu frustré au début avec le cycle de vie des applications Android, mais après une meilleure compréhension, j'ai vraiment apprécié cette approche. Ce livre répondra à toutes vos questions et bien plus encore. C'est vraiment la meilleure ressource que j'ai trouvée pour les nouveaux développeurs Android.

De plus, je pense que vous devez abandonner un port ligne par ligne de l'application existante. Afin de porter votre application sur la plate-forme Android, une partie de la conception de l'application va changer. Le cycle de vie des applications utilisé est nécessaire car les appareils mobiles ont des ressources très limitées par rapport aux systèmes de bureau et permettent aux appareils Android d'exécuter plusieurs applications de manière ordonnée et respectueuse des ressources. Faites une étude plus approfondie de la plate-forme et je pense que vous vous rendrez compte que ce que vous voulez faire est tout à fait possible. Bonne chance.

Soit dit en passant, je ne suis aucunement affilié à Addison-Wesley ou à toute personne ou organisation associée à ce livre. Après avoir relu mon article, je sens que je suis sorti un peu fanboyish. J'ai vraiment, vraiment apprécié et trouvé cela extrêmement utile. :)

Peter Mortensen
la source
2
Merci pour l'astuce du livre. Je vais y jeter un œil si je peux et si je décide de passer sur le port Android. Juste pour le dire encore une fois: nos utilisateurs ne sont pas très à jour en ce qui concerne les ordinateurs. Je serai très difficile pour eux d'utiliser par exemple le NotificationBar dans Android. Trop petit (ils ont de gros doigts hehe). C'est un monde différent pour eux, nous devons donc le garder simple et sans options pour l'utilisateur. Nous avons construit notre solution .NET dans cet esprit - ne leur donnez pas le choix =)
Ted
J'entends ça. Vous devez supposer que la plupart des utilisateurs ne sont pas très intelligents sur le plan technologique.
Andy
8
Je suis tellement fatigué du mantra du peu de "ressources" d'un appareil mobile. Réveillez-vous, ils fonctionnent sur plus de 500 MHz et ont beaucoup de mémoire. Mon ancien Dell Axim avait 128 Mo de RAM. Les appareils actuels ont généralement plus de 512 RAM et fonctionnent sur 1 GHz! C'est 10 fois plus que mon ancien Pentium 90Mhz, et je n'ai pas entendu ppl dire "les ressources très limitées" ceci et cela. Il est temps de se réveiller et de sentir le café - nous sommes dans le 2010 maintenant, pas dans les années 80.
Ted
16

Presque 99% du temps, il n'est pas nécessaire qu'une application Android prenne en charge son propre cycle de vie. La plupart du temps, il s'agit d'une meilleure planification ou d'une conception plus intelligente de l'application. Par exemple, créez plutôt un service interne (non exporté) pour gérer les téléchargements, etc., ou concevez des actions et des tâches autour du flux de travail utilisateur.

Mais cela étant dit, là où il y a une volonté, il y a un moyen. Android fournit - via la classe android.os.Process, une bien meilleure API que Java pour contrôler le processus sous-jacent. Et contrairement à Java, il ne traite pas le développeur comme un idiot en le cachant derrière un simple appel java.lang.System.exit ().

Alors, comment demandez-vous à votre application de se suicider dans Android? Eh bien, l'astuce est simple:

Créez votre propre classe d'application Android en héritant de la classe standard android.app.Application (n'oubliez pas de la déclarer dans le fichier AndroidManifest.xml).

Remplacez la méthode onCreate () et stockez l'ID de processus qui a démarré votre application:

this.pid = android.os.Process.myPid(); // Save for later use.

Maintenant, pour tuer votre application, fournissez une méthode kill ():

android.os.Process.sendSignal(pid, android.os.Process.SIGNAL_KILL);

Maintenant, chaque fois que vous avez besoin de votre application pour vous suicider, tapez simplement le contexte de l'application et appelez votre méthode kill!

((MySuicidalApp) context.getApplicationContext()).kill()

N'oubliez pas qu'en raison des politiques de gestion des processus dans Android, spécifiquement liées aux services, Android peut simplement choisir de redémarrer votre service (voir Vous ne devez pas utiliser les tueurs de tâches sur Android ).

Andries
la source
oui, je ne suis venu ici que parce que je voulais fermer mon application dans une situation, cela a du sens, mon cache de données OBB est corrompu et je dois redémarrer toute l'application
Luiz Felipe
14

Quand je conçois une application sous Android, je la vois de cette façon:

  • Vous travaillez avec votre application
  • Le téléphone a sonné
  • Vous prenez l'appel
  • A la fin de l'appel, vous revenez à votre candidature au même endroit où vous étiez

Pour ce faire, vous n'avez besoin que du Backbouton ou du Homebouton de votre téléphone (par appui court ou long) et de la barre de notification.

Lorsque je quitte mon application, je n'utilise le Backbouton que lorsque j'en suis sorti ou le Homebouton.

C'est ainsi que la plupart des applications sont conçues, je pense. Mais si j'ai besoin d'une sorte de session ou de connexion, je l'ai expliqué à l'utilisateur avec un bouton de connexion / déconnexion et une notification (barre de titre ou autre). Il s'agit d'un style assez différent de l'application de style pur "exit".

Sur les PC, vous avez un bureau multi-GUI, et sur Android, vous avez évidemment plusieurs tâches, mais vous n'affichez qu'une seule application à la fois (je ne considère pas les widgets ici ^^). Et sur un téléphone mobile, à tout moment, vous pouvez recevoir une notification pour quelque chose de plus important que ce que vous faites.

Ainsi, tout le concept d'une application repose sur quelque chose de différent qui "entre l'application - travaille - quitte l'application".

Solostaran14
la source
12

Hmmmm ...

Je pense que vous ne voyez simplement pas l'application Android de la bonne façon. Vous pouvez facilement faire quelque chose comme ce que vous voulez:

  • Faites l'état d'enregistrement / restauration des activités de l'application comme cela est encouragé dans la documentation du développeur sur le cycle de vie.

  • Si une connexion est nécessaire à l'étape de la restauration (aucune information de connexion / session disponible), faites-le.

  • Ajoutez éventuellement un bouton / menu / timeout, auquel cas vous ferez un finish()sans enregistrer la connexion et les autres informations de session, ce qui entraînera implicitement la fin de la session de l'application: donc si l'application est démarrée / ramenée à l'avant, elle démarrera une nouvelle session.

De cette façon, vous ne vous souciez pas vraiment si l'application est vraiment supprimée de la mémoire ou non.

Si vous voulez vraiment le supprimer de la mémoire (cela est déconseillé, et BTW dans quel but?), Vous pouvez le tuer conditionnellement à la fin de onDestroy()avec java.lang.System.exit(0)(ou peut restartPackage(..)- être ?). Bien sûr, ne le faites que dans le cas où vous souhaitez "vraiment mettre fin à l'application", car cela onDestroy()fait partie du cycle de vie normal des activités et non pas une fin d'application du tout.

Slig
la source
11

Étant donné qu'une application dans un contexte Android n'est qu'un tas d'activités vaguement liées, quitter une application n'a pas vraiment de sens. Vous pouvez terminer () une activité, et la vue de l'activité précédente dans la pile d'activités sera dessinée.

Tom R
la source
2
Quitter une application peut être utile dans certaines situations. S'il s'agit d'un programme que vous utilisez plusieurs fois par mois pendant quelques minutes, il y a un avantage incontestable à quitter complètement l'application. Cet avantage est que le système d'exploitation n'aura pas à prendre le temps de quitter cette application une semaine plus tard lorsque sa mémoire est insuffisante et que votre téléphone sonne et que vous avez appuyé sur le bouton de réponse, et que vous attendez qu'Android libère de la mémoire pour pouvoir répondre à votre appel, par exemple. Ou peut-être que vous avez reçu un e-mail et que vous souhaitez le lire - toute application qui a besoin de plus de mémoire se lancera plus rapidement si le système d'exploitation ne le libère pas au préalable.
Jesse Gordon
3
Ce que @JesseGordon a dit, et un autre aspect de cette raison pour laquelle arrêter est logique: si je ne quitte pas cette application gourmande en ressources, je sais que je ne vais pas l'utiliser à nouveau pendant un mois, le système d'exploitation tuera parfois à tort une autre application lorsque les ressources se raréfient, tout en laissant cette application de porc de ressources inutile en cours d'exécution ... ce qui rend cette autre application plus longue à reprendre qu'elle ne le devrait.
Don Hatch,
10

Je suis d'accord avec Ted. Je comprends que quitter l'application n'est pas la "voie Android", mais il ne semble pas que cela devrait être exclu. Voici trois raisons pour lesquelles vous souhaiterez peut-être une sortie réelle vers l'application (et pas seulement l'activité):

  1. L'utilisateur peut souhaiter un certain contrôle sur l'application qui sera tuée en cas de mémoire insuffisante. Si l'application A importante est exécutée en arrière-plan, vous souhaiterez peut-être quitter l'application B lorsque vous en aurez terminé afin que l'application A ne soit pas détruite par le système d'exploitation.

  2. Si votre application a des données sensibles mises en cache dans la mémoire, vous souhaiterez peut-être tuer l'application afin qu'une application de virus / ver / voyou ne puisse pas y accéder. Je sais que le modèle de sécurité est censé empêcher cela, mais juste au cas où ...

  3. Si votre application utilise des ressources (comme le réseau, le processeur, les capteurs, etc.) qui pourraient nuire au téléphone, alors une façon de vous assurer que ces ressources sont libérées est de quitter l'application. Je comprends que les applications qui se comportent bien devraient libérer des ressources lorsqu'elles ne sont pas nécessaires. Mais encore une fois, quitter l'application semble être un moyen raisonnable de garantir cela.

Burke
la source
6
Selon vous, que représente "l'application"? Si j'ouvre l'application Facebook et que je définis une nouvelle photo de profil - mes applications Appareil photo ou Galerie démarrent. En tant qu'utilisateur, j'effectue toujours la même tâche (en utilisant Facebook). Si je décide ensuite de fermer Facebook, mes applications Appareil photo et Galerie doivent également se fermer (car ce sont des activités lancées à partir de Facebook) ... Et si j'étais en train de modifier certaines de mes autres photos et que je n'avais l'intention que de fermer Facebook ? Vous auriez déplacé le problème vers une perte de données potentielle.
seanhodges
Eh bien, je ne pense pas que cela puisse aller jusqu'à la perte de données. Si vous avez une activité tierce exécutée dans la même tâche que votre propre activité et que votre propre activité est celle avec le bouton de sortie, alors l'utilisateur doit accéder à finish()l'activité tierce avant de pouvoir appuyer sur le bouton de sortie. Et l'activité de tiers doit être de sauvegarder toutes les informations non enregistrées à ce moment-là. Je ne pense pas que vous pouvez utiliser le sélecteur d'application pour revenir à l'activité du bouton de sortie, sauf s'il s'exécute dans une tâche distincte. Et si c'est une tâche distincte, c'est un processus distinct, et donc ne sera pas tué par le bouton de sortie.
Neil Traft
2
1. Je pense que 99,99% des utilisateurs d'Android ne devraient pas se soucier de la façon dont le système d'exploitation gère les applications derrière les rideaux. Les autres sont des geeks et trouveront que des outils avancés font que le système se comporte exactement comme ils le souhaitent. 2. Vous pouvez toujours décharger toutes les données sensibles lorsque l'activité est suspendue ou arrêtée. 3. Comme ci-dessus, les ressources peuvent être libérées dans les méthodes de rappel du cycle de vie. Lorsque l'activité reprend, les ressources peuvent être à nouveau allouées.
Zsolt Török
4
Je pense qu'il est plutôt intéressant de constater que de nombreux utilisateurs d'Android installent "Advanced Task Killer", une application qui ferme d'autres applications car vous ne pouvez normalement pas le faire vous-même. Je l'utilise tout le temps moi-même. Quitter une application n'est pas quelque chose dont je pense que vous pouvez vous passer.
Ted
2
@ ZsoltTörök, 99,99% des gens ont affaire à des ordinateurs / téléphones lents et sont forcés de choisir de se soucier de la façon dont le système d'exploitation gère les applications derrière les rideaux.
Pacerier
10

Le noyau Linux a une fonctionnalité appelée tueur de mémoire insuffisante (comme mentionné ci-dessus, les politiques sont configurables au niveau de l'espace utilisateur et le noyau n'est pas optimal, mais en aucun cas inutile).

Et il est largement utilisé par Android:

Certaines applications de l'espace utilisateur sont disponibles pour aider avec ces applications de suppression, par exemple:

Peter Teoh
la source
9

Vous avez apparemment trouvé la réponse que vous souhaitez dans la commande finish (). Cela ne supprimera pas votre application de la mémoire, mais Android le fera chaque fois qu'il aura besoin des ressources, donc cela ne fait aucune différence que vous ne le fassiez pas explicitement.

J'ajouterais seulement que pour obtenir le plein effet qu'une sortie d'application aurait généralement, vous voudriez réinitialiser l'état de l'application à son état normal au moment où elle est exécutée pour la première fois après le démarrage de l'appareil, juste avant pour appeler finish () sur toutes vos activités. De cette façon, si l'utilisateur sélectionne à nouveau votre application, elle semblera avoir été exécutée "fraîche", sans aucun état restant du point avant la "sortie" simulée.

S'il existe des actions spéciales qui ne doivent se produire qu'à la "sortie", telles que l'enregistrement du travail de l'utilisateur ou autre, vous pouvez également les exécuter avant la partie de réinitialisation de la routine ci-dessus.

Cette approche vous permet d'atteindre votre objectif d'avoir une commande de «sortie» sans violer la philosophie d'Android de laisser la gestion des ressources du système d'exploitation, y compris la fermeture des applications, entre les mains du système d'exploitation.

Personnellement, je n'utiliserais pas cette approche, car les utilisateurs d'Android s'attendent à ce qu'une application préserve sa continuité lorsqu'ils la revisitent, et ils ne sont donc pas habitués à la modalité de "quitter" une application. Je prendrais plutôt en charge une fonction "claire" qu'un utilisateur peut invoquer pour réinitialiser l'application à un état initial par défaut, sans qu'il soit nécessaire de la "laisser" dans le processus.

La seule exception serait lorsque l'utilisateur a appuyé sur le bouton de retour un nombre suffisant de fois pour provoquer la fermeture de l'application. Dans cette situation, il n'y a aucune attente de la part de l'utilisateur que l'état aura été enregistré (et s'il y a un état non enregistré dans l'application, vous, en tant que développeur, devriez avoir du code gérant le bouton de retour qui détecte ces données non enregistrées, et invite l'utilisateur à l'enregistrer dans SharedPreferences ou dans un fichier, ou sur un autre support non volatile).

Concernant system.exit (0):

Si vous décidez d'utiliser system.exit (0) pour fermer votre application avec une finalité grossière (par exemple, à la suite d'une dernière pression sur le bouton de retour), je vous avertirais que même si pour moi cela "fonctionne", et dans certains cas a été la seule façon dont j'ai pu fermer une application sans qu'il n'en reste aucune trace, il y a un problème mineur qui se produit dans Jelly Bean lorsque vous utilisez cette approche.

Plus précisément, si vous utilisez la liste des applications récentes pour ouvrir votre application, puis utilisez le bouton de retour pour fermer l'application (avec cette fermeture implémentée via system.exit (0)), la liste des applications récentes redeviendra visible, car elle n'ont jamais été fermés. Si vous appuyez ensuite sur l'entrée de votre application dans cette liste pour l'exécuter une deuxième fois à partir de la même liste d'applications récentes, déjà ouverte, il n'y aura pas de réponse.

Je soupçonne que cela est dû au fait que la liste des applications récentes conserve une référence à votre application qui est devenue non fonctionnelle en raison de la fermeture de l'application à l'aide de system.exit (0). Une fermeture plus civilisée de votre application à l'aide de finish () aurait pu informer le système d'exploitation d'une manière qui lui aurait permis de rafraîchir sa liste des applications récentes, mais system.exit (0) ne le fait apparemment pas.

Ce n'est pas un énorme problème en soi, car très peu de gens ouvriront une application à partir des applications récentes, la quitteront, puis la rouvriront immédiatement à partir de la même liste d'applications récentes ouverte. Et si elles touchez le bouton d'accueil, puis ré-ouvrir la liste des applications récentes, l'entrée de votre application sera là, et il sera pleinement fonctionnel. Mais je pense que cela montre que l'utilisation de system.exit (0) peut interférer avec une bonne communication entre votre application et le système d'exploitation, ce qui suggère qu'il peut y avoir d'autres conséquences plus graves, peut-être subtiles, de l'utilisation de cette approche.

Carl
la source
Vous pouvez peut-être supprimer l'entrée des applications récentes avant d'appeler finish ()? C'est quelque chose que j'essaierai lorsque le temps le permettra. J'ai un service de premier plan avec une petite activité de lanceur. Comme l'activité est très petite, ce n'est pas grave si elle n'est pas tuée et enterrée, mais il est logique de dire à Android qu'il peut prendre celui-ci avant le reste, si possible.
nsandersen
9

J'espère que les choses changeront avec le temps. L'utilisateur doit pouvoir tuer une application ou un processus si le processus d'application est correctement mis en sandbox par le système d'exploitation. Il existe une notion selon laquelle les applications doivent être parfaitement écrites ou l'utilisateur n'utilisera que les applications qui suivent toutes les recommandations du SDK. Je pense que c'est une tâche difficile.

dipu
la source
Je connais. Les produits Apple sont bons pour certains consommateurs. Ils ne sont pas bons pour les développeurs. Android OS a tout le potentiel pour devenir comme "Windows OS du monde PC" pour les téléphones mobiles. peut être encore mieux. Il est déjà plus ouvert que les fenêtres du monde PC, sauf qu'il ne nous permet pas d'écrire un gestionnaire de tâches.
dipu
7

Il existe une conception (relativement) simple qui vous permettra de contourner l'énigme de la «sortie». Faites en sorte que votre application ait un état (activité) de base qui n'est qu'un écran vide. Lors de la première création de l'activité, vous pouvez lancer une autre activité dans laquelle se trouve la fonctionnalité principale de votre application. La "sortie" peut ensuite être accomplie en terminant () cette deuxième activité et en revenant à la base d'un simple écran vierge. L'OS peut garder cet écran vierge en mémoire aussi longtemps qu'il le souhaite ...

En substance, parce que vous ne pouvez pas quitter le système d'exploitation, vous vous transformez simplement en un néant créé par vous-même.

qwerty_ca
la source
2
Bonne idée. Cependant, même la fin d'une activité (ou d'un service) n'arrête pas le système d'exploitation. Oh non, même après l'exécution de onDestroy, toutes les variables et les éléments sont toujours là. Je viens de voir que dans un service, tout est le même, même si onDestroy a été appelé ...
Ted
2
... et donc System.exit (0) a aidé =)
Ted
7

Sans fonction de sortie pour que le développeur de l'application tue sa propre application, c'est une très mauvaise conception.

Mon application doit permettre à l'utilisateur de modifier dynamiquement les données dynamiquement pendant l'exécution et l'utilisateur doit redémarrer mon application pour effectuer l'effet de changement, mais Android n'a pas autorisé le redémarrage de mon application par lui-même. Le système d'exploitation Android a un cycle de vie d'application de conception très mauvais.

Peter Mortensen
la source
9
public void appRestart () {Intent i = new Intent (getBaseContext (), MyActivity.class); i.addFlags (Intent.FLAG_ACTIVITY_CLEAR_TOP); startActivity (i); }
androidworkz
2
Le code de ce commentaire ci-dessus fonctionne vraiment bien. Au moins, vous pouvez passer à la première activité au lieu de quitter complètement l'application. :)
Harpreet
7

Pour fermer une application à tout moment, utilisez l' FLAG_ACTIVITY_CLEAR_TOPindicateur dans Intent puissystem.exit();

Ou il existe une manière similaire, mais sans system.exit()quand vous voulez quitter, appelez cette méthode:

public void exit() {
    startActivity(new Intent(this, HomeActivity.class).
    setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | IntentCompat.FLAG_ACTIVITY_CLEAR_TASK).putExtra(EXIT_FLAG, true));
}

Dans votre HomeActivity.onCreate()code suivant ajouter

protected void onCreate(Bundle savedInstanceState) {
    if (getIntent().getBooleanExtra(EXIT_FLAG, false)) {
        if ((getIntent().getFlags() & Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY) == 0) {
            finish();
        }
    }
......................

Cela fonctionnera sans interrompre le cycle de vie d'Android.

Lemberg
la source
7

Tout d'abord, n'utilisez jamais System.exit (0). C'est comme faire dormir une personne en lui frappant la tête!

Deuxièmement: je suis confronté à ce problème. Avant de partager ma solution, je veux partager mes réflexions.

Je pense qu'un "bouton de sortie" est stupide. Vraiment vraiment vraiment stupide. Et je pense que les utilisateurs (consommateurs) qui demandent un bouton de sortie pour votre application sont aussi stupides. Ils ne comprennent pas comment fonctionne le système d'exploitation et comment gère les ressources (et il fait un excellent travail).

Je pense que si vous écrivez un bon morceau de code qui fait les bonnes choses (mises à jour, enregistre et pousse) au bon moment et dans les bonnes conditions et en utilisant les bonnes choses (service et récepteur), cela fonctionnera plutôt bien et personne ne se plaindra .

Mais pour ce faire, vous devez étudier et apprendre comment les choses fonctionnent sur Android. Quoi qu'il en soit, c'est ma solution pour fournir aux utilisateurs un "bouton de sortie".

J'ai créé un menu d'options toujours visible dans chaque activité (j'ai une super activité qui fait ça).

Lorsque l'utilisateur clique sur ce bouton, voici ce qui se passe:

Intent intent = new Intent(this, DashBoardActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

SharedPreferences settings = getSharedPreferences(getString(PREF_ID), Context.MODE_PRIVATE);
SharedPreferences.Editor editor = settings.edit();
editor.putBoolean(FORCE_EXIT_APPLICATION, true);

  // Commit the edits!
editor.commit();
startActivity(intent);
finish();

J'économise donc dans SharedPreferences que je veux tuer mon application et je démarre une intention. Veuillez regarder ces drapeaux; ceux-ci effaceront tout mon backstack en appelant mon activité DashBoard qui est mon activité "maison".

Donc, dans mon activité Dashboard, j'exécute cette méthode dans onResume:

private void checkIfForceKill() {

    // CHECK IF I NEED TO KILL THE APP

    // Restore preferences
    SharedPreferences settings = getSharedPreferences(
            getString(MXMSettingHolder.PREF_ID), Context.MODE_PRIVATE);
    boolean forceKill = settings.getBoolean(
            MusicSinglePaneActivity.FORCE_EXIT_APPLICATION, false);

    if (forceKill) {

        //CLEAR THE FORCE_EXIT SETTINGS
        SharedPreferences.Editor editor = settings.edit();
        editor.putBoolean(FORCE_EXIT_APPLICATION, false);

        // Commit the edits!
        editor.commit();

        //HERE STOP ALL YOUR SERVICES
        finish();
    }
}

Et cela fonctionnera plutôt bien.

La seule chose que je ne comprends pas pourquoi cela se produit, c'est que lorsque je fais la dernière finition (et j'ai vérifié: il suit tout le flux correct de onPause → onStop → onDestroy) l'application est toujours sur l'activité récente (mais c'est vide).

Il semble que la dernière intention (qui a démarré DashboardActivity) soit toujours dans le système.

Je dois creuser plus pour le supprimer également.

StErMi
la source
8
Peu de consommateurs savent ce qu'est un système d'exploitation et encore moins comment on fonctionne, cela ne les rend pas stupides. Vouloir un bouton Exit / Quit / Off les rend normaux. Lorsque vous quittez une pièce, vous éteignez les lumières, plus important encore lorsque vous quittez votre maison, vous verrouillez la porte et c'est là que je vois le problème de l'incapacité à quitter correctement un programme. Laisser le programme vivant en arrière-plan est un gros risque pour la sécurité.
Squiggles
4
"Je pense qu'un" bouton de sortie "est stupide". La plupart des applications logicielles proposent un bouton de sortie.
IgorGanapolsky
Vous avez dit "// ICI ARRÊTEZ TOUS VOS SERVICES", puis vous avez utilisé finish (). Les services Android n'ont pas de méthode finish (). Ils ont unbindService (mConnection);
IgorGanapolsky
@Squiggles Si vous avez une pièce qui éteint automatiquement toutes ses lumières et verrouille votre porte lorsque vous partez, vous n'avez pas besoin de vous en soucier.
Seshu Vinay
7

Le cycle de vie de l'application Android est conçu pour les utilisateurs de téléphones mobiles et non pour les utilisateurs d'ordinateurs.

Le cycle de vie de l'application est le paradigme brutalement simpliste requis pour transformer un serveur Linux en une appliance grand public.

Android est Java sur Linux, un véritable OS serveur multiplateforme. C'est ainsi qu'il s'est propagé si rapidement. Le cycle de vie de l'application résume la réalité sous-jacente du système d'exploitation.

Pour les utilisateurs mobiles, les applications sont simplement installées ou non installées. Il n'y a aucun concept de course ou de sortie. En fait, les processus d'application sont censés s'exécuter jusqu'à ce que le système d'exploitation les libère pour leurs ressources détenues.

Comme il s'agit de Stack Overflow, quiconque lit ceci est un utilisateur d'ordinateur et doit désactiver 90% de ses connaissances pour comprendre le cycle de vie de l'application mobile.

Dominic Cerisano
la source
Je ne suis pas à la hauteur de "les utilisateurs d'ordinateurs doivent désactiver 90% de leurs connaissances". Oui, c'est ce que dit Romain Guy, mais cela ne le rend pas vrai. Il me semble qu'une section "Options avancées pour les utilisateurs d'ordinateurs", avec un bouton "Quitter", répondrait aux besoins de chacun.
Don Hatch
Je n'ai aucune idée de qui est ce "Romain Guy", ni pourquoi il me cite. La fermeture des tâches récentes fermera l'application, tout comme l'arrêt des informations de l'application. ADB permet un accès shell pour les utilisateurs avancés.
Dominic Cerisano
6

Il m'a fallu plus de temps pour lire ce Q&R que pour mettre en œuvre un cycle de vie d'application Android semi-approprié.

C'est une application GPS qui interroge les points et envoie l'emplacement actuel à un service Web toutes les quelques secondes à l'aide d'un fil ... Cela pourrait être une interrogation toutes les 5 minutes dans le cas de Ted pour une mise à jour, puis onStop peut simplement démarrer l'activité de mise à jour Ted était soo inquiet de savoir si un a été trouvé (Ted asynchrone, ne codez pas comme un programmeur Windows ou vos programmes fonctionneront comme des programmes Windows ... eww, ce n'est pas si difficile).

J'ai fait du code initial dans onCreate pour configurer des choses pour la durée de vie de l'activité, notamment checkUpdate.start();:

...

@Override
public void onStart() {
    super.onStart();
    isRemote = true;
    checkUpdate.resume();

    locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 2000, 0, luh);
}

@Override
public void onPause() {
    isRemote = false;
    checkUpdate.suspend();
    locationManager.removeUpdates(luh);
    super.onStop();
}

Ce code peut être complètement faux, mais cela fonctionne. Ceci est l'une de mes premières applications Android.

Voilà, une application qui ne consomme pas de CPU lorsqu'elle est en arrière-plan, mais qui est instantanément prête à rouvrir car elle est en RAM (bien qu'elle ne contienne pas de RAM comme c'est le cycle de vie Android) ... une application est toujours prête, c'est un téléphone , les gars / filles. Si une application devait utiliser toute la RAM et ne pouvait pas être arrêtée par le système d'exploitation, la chose pourrait cesser de sonner = P C'est pourquoi le système d'exploitation doit pouvoir fermer votre application lorsqu'elle est en arrière-plan (si votre application n'est pas pas un porc de ressources, il ne sera pas fermé BTW), alors écrivons simplement de meilleures applications.

Brant
la source
Vous ne devriez pas appeler super.onStop à partir de la méthode onPause.
Matt Wolfe
1
Après avoir lu une vingtaine de réponses philosophiques qui esquivent simplement la question .... +1 pour avoir du code.
Pacerier
6

Chaque fois que vous passez à la page suivante par intention, utilisez:

`YourActivityname.this.finish()`;

Exemple:

Intent intent = new Intent(getApplicationContext(), SMS.class);

startActivity(intent);
MainActivity.this.finish();

Pour qu'aucune activité ne s'exécute en arrière-plan et lorsque vous souhaitez quitter votre application, utilisez:

MainActivity.this.finish();
android.os.Process.killProcess(android.os.Process.myPid());
System.exit(0);
getParent().finish();

Cette sortie a fonctionné comme un charme pour moi :)

GaneshKumar
la source
1
Il ne quitte pas l'application à la place, il s'agit de Mainactivité.
Sharath
1
Mais attention - onPause () N'EST PAS appelé dans le cas de killProcess et System.exit. Nous avons eu quelques problèmes avec cela.
Pavel Biryukov,
4

Dans tous les cas, si vous souhaitez mettre fin à votre candidature, vous pouvez toujours appeler System.exit(0);.

Tasos Kleisas
la source
5
System.exit()ne tue PAS votre application si vous avez plus d'une activité sur la pile. Un développeur Android qui l'utilise n'a pas compris le cycle de vie de base de l'application Android. Lisez cette réponse .
Dheeraj Vepakomma
Solution complète avec System.exit(0); stackoverflow.com/questions/2033914/…
Sohail Zahid
2
En fait, System.exit () ne tue votre application. Cependant, si System.exit () a été appelé depuis un endroit autre que l'activité principale, Android redémarrera l'application avec une activité de moins sur la pile. Pour moi, cela semble être une réponse ridicule à une System.exit intentionnelle propre. Je veux dire, s'il s'agissait d'un div0 ou d'un crash accidentel, il serait peut-être poli de redémarrer. Mais ceux-ci ne provoquent même pas de redémarrage automatique si je me souviens bien. Mais en tout cas, l'application est tuée. Il peut être redémarré, mais cela ne signifie pas qu'il n'a pas été tué.
Jesse Gordon
3

Si vous avez 10,20 .. plusieurs activités en cours d'exécution et que vous souhaitez les terminer toutes et quitter le système.

Créez un tableau statique dans application classouconstants class.

Constantes

public class Constants {

public static ArrayList<Activity> activities = new ArrayList<Activity>();

}

MainActivity Ajouter une référence d'activité actuelle dans ce tableau

activity = MainActivity.this; Constants.activities.add(activity);

public class MainActivity extends Activity {

    private ImageView imageButton;
    private Activity activity;


    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        activity = MainActivity.this;
        Constants.activities.add(activity);

        imageButton = (ImageView) findViewById(R.id.camera);
        imageButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {

                // existing app.
                if (Constants.activities != null) {
                    for (int i = 0; i < Constants.activities.size(); i++) {
                        Activity s = Constants.activities.get(i);
                        s.finish();
                    }
                }
                //super.finish();
                finish();
                android.os.Process.killProcess(android.os.Process.myPid());
                System.exit(1);
            }
        });
    }
}
Sohail Zahid
la source
1
Cela peut planter votre application lorsque les utilisateurs cliquent deux fois sur un bouton, en particulier lorsque le système est soumis à une charge élevée pour une raison quelconque. Cela peut être évité en supprimant les activités de la baie.
J'espère que