Quitter une application est-il mal vu?

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?

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à.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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. :)

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 ).

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".

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.

É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.

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.

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:

• OOM killer n'est pas pour l'espace utilisateur

• Notes Android (OOM Killer Info - où vous pouvez configurer la fonction OOM sur Android)

• Portage Android sur une cible réelle

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

• Autokiller / Configuration du tueur de tâches interne d'Android

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.

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.

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.

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.

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.

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.

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.

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.

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 :)

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

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);
            }
        });
    }
}