Question Quitter une application est-il mal vu?


Passant dans ma tentative d'apprendre Android, je viens de Lisez ce qui suit:

Question: Est-ce que l'utilisateur a le choix de tuer l'application   à moins que nous mettions une option de menu dedans pour le tuer? Si aucune option n'existe,   comment l'utilisateur met-il fin à l'application?

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

Hehe, pour chaque étape que je prends 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 dès qu'il en a envie). Qu'est-ce qui se passe avec ça? 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 que l'on devrait faire confiance à l'OS.

L'application que j'essaie de créer n'est pas une application pour l'Android Market. Il ne s'agit pas d'une application «grand public» par le grand public, c'est une application métier qui va être utilisée dans un domaine très étroit.

J'étais vraiment impatient de développer pour la plate-forme Android, car il résout beaucoup de problèmes qui existent dans Windows Mobile et .NET. Cependant, la dernière semaine a été quelque peu une sortie pour moi ... J'espère que je ne dois pas abandonner Android, mais il ne semble pas très bon dès maintenant = (

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


1037


origine


Réponses:


Cela finira par arriver à votre question, mais je veux d'abord aborder un certain nombre de questions que vous soulevez dans vos différents commentaires aux diverses 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 - ils sont plutôt destinés à d'autres personnes qui viendront lire cet article à l'avenir.

Le fait est que je ne peux pas permettre   Android pour déterminer quand mon application est   va être terminé. ça 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 à «mettre fin» à l'application Android, pas plus qu'ils ne pensent à «mettre fin» à une page Web ou à «mettre fin» à un thermostat.

Les utilisateurs d'iPhone sont très similaires, car presser le bouton de l'iPhone ne signifie pas nécessairement que l'application a été interrompue, car de nombreuses applications iPhone reprennent là où l'utilisateur s'était arrêté, même si l'application était vraiment fermée (depuis l'iPhone uniquement) permet une application tierce à la fois, à l'heure actuelle).

Comme je l'ai dit plus haut, il y a beaucoup de   les choses se passent dans mon application (données étant   PUSHed à l'appareil, listes avec des tâches   cela devrait toujours être là, etc.).

Je ne sais pas ce que «les listes avec des tâches qui devraient toujours être là» signifie, mais les «données étant PUSHed à l'appareil» est une fiction agréable et ne devrait pas être fait par une activité dans tous les cas. Utiliser 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   que 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   en quittant l'application

C'est une erreur sur n'importe quel système d'exploitation. Pour autant que vous sachiez, la raison de la fermeture de votre application est que le système d'exploitation s'arrête et votre processus de mise à jour échouera à mi-parcours. Généralement, ce n'est pas une bonne chose. Vous pouvez soit vérifier les mises à jour au démarrage, soit vérifier les mises à jour de manière totalement asynchrone (par exemple, via une tâche planifiée), jamais à la sortie.

Certains commentaires suggèrent que frapper le   bouton retour ne tue pas l'application à   tous (voir le lien dans ma question ci-dessus).

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

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

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

Y a-t-il un moyen pour moi d'arrêter   L'application?

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


Aucun environnement d'application n'est identique, par définition. Cela signifie que vous pouvez voir les tendances dans les environnements au fur et à mesure que de nouveaux apparaissent et que d'autres sont enterrés.

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

De même, il y a un mouvement croissant pour essayer d'éliminer la notion de «terminer» une application. La plupart des applications Web ne forcent pas l'utilisateur à se déconnecter, mais plutôt à se déconnecter implicitement de l'utilisateur 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 des applications, en se concentrant sur les objectifs métier et de ne pas coller à un modèle d'implémentation 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 c'est la faute d'une montagne pour les orages qui circulent autour d'elle plutôt que par son intermédiaire.

Par exemple, certains environnements de développement, comme Hypercard et Smalltalk, avaient l'application et les outils de développement mélangés dans une configuration. Ce concept n'a pas beaucoup retenu l'attention, en dehors des extensions de langue pour les applications (p. VBA dans Exceller, Lisp dans AutoCAD). Les développeurs qui ont inventé des modèles mentaux supposant l'existence d'outils de développement dans l'application elle-même devaient donc soit changer de modèle, soit se limiter à des environnements où leur modèle serait vrai.

Donc, quand vous écrivez:

Avec d'autres choses en désordre je   découvert, je pense que le développement   notre application pour Android ne va pas   se produire.

Cela semble être pour le mieux, pour vous, pour le moment. De même, je vous conseille de ne pas tenter de porter votre application sur le Web, car certains des problèmes que vous avez signalés avec Android se retrouvent également dans les applications Web (par exemple, pas de «résiliation»). Ou, inversement, un jour si vous faire Port votre application sur le Web, vous pouvez trouver que le flux de l'application Web peut être une meilleure correspondance pour Android, et vous pouvez revisiter un port Android à ce moment-là.


1216



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

System.exit() ne tue pas votre application si vous avez plus d'une activité sur la pile.  Qu'est-ce qui se passe réellement est que le processus est tué et redémarré immédiatement avec une activité en moins sur la pile. C'est également ce qui se produit lorsque votre application est supprimée par la boîte de dialogue Forcer la fermeture, ou même lorsque vous essayez de supprimer le processus 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 dans votre pile et finish() Tous quand l'utilisateur veut sortir (et non, il n'y a aucun moyen de parcourir la pile d'activité, donc vous devez 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 finit simplement les activités. De plus, je ne suis pas sûr que Process.killProcess(Process.myPid()) fonctionne mieux; Je ne l'ai pas testé.

Si, d'un autre côté, il est acceptable que vous ayez des activités dans votre pile, il existe une autre méthode qui rend les choses super faciles pour vous: Activity.moveTaskToBack(true) mettra simplement en arrière-plan votre processus et affichera 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 se produit uniquement lorsque votre application est au premier plan. Si c'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 veut continuer à faire ce qu'il / elle faisait. (Si vous essayez de tuer le processus de DDMS, vous devez d'abord frapper le bouton d'accueil, puis le tuer)
  2. Il suppose également que chaque activité est indépendante de toutes les autres activités. Ceci est souvent vrai, par exemple dans le cas où votre application lance l'activité du navigateur, qui est entièrement séparée et n'a pas été écrite par vous. L'activité du navigateur peut ou non être créée sur la même tâche, en fonction de ses attributs manifestes.
  3. Il suppose que chacune de vos activités est complètement autonome et peut être tué / restauré dans un délai d'un instant. (Je n'aime pas 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 grandes pour être sérialisées efficacement pendant onSaveInstanceState, mais whaddya va faire?) Pour la plupart des applications Android bien écrites cela devrait être vrai, puisque vous ne savez jamais quand votre application va être tué en arrière-plan.
  4. Le facteur final n'est pas tant une hypothèse, mais plutôt une limitation de l'OS: tuer l'application explicitement est la même que l'application s'écraser, et aussi le même que Android tuant l'application pour récupérer la mémoire.  Cela aboutit à notre coup de grâce: puisque Android ne peut pas dire si l'application a quitté ou s'est écrasé ou a été tué en arrière-plan, il suppose que l'utilisateur veut retourner là où ils l'avaient laissé, et ActivityManager redémarre le processus.

Quand vous y réfléchissez, c'est approprié pour la plate-forme. Tout d'abord, c'est exactement ce qui se passe quand le processus est tué en arrière-plan et que l'utilisateur y revient, il doit donc être redémarré là où il s'est arrêté. Deuxièmement, c'est ce qui se passe lorsque l'application se bloque et présente la redoutable boîte de dialogue Force Close.

Dites que je veux que mes utilisateurs puissent prendre une photo et la télécharger. Je lance l'activité Appareil photo depuis mon activité et je lui demande de renvoyer une image. La caméra est poussée sur le dessus de ma tâche actuelle (plutôt que d'être créée dans sa propre tâche). Si la caméra a une erreur et se bloque, cela devrait-il entraîner une panne totale de l'application? Du point de vue de l'utilisateur, seule la caméra a échoué, et ils devraient être retournés à leur activité précédente. Donc, il redémarre simplement le processus avec toutes les mêmes activités dans la pile, moins la caméra. Depuis vos activités devrait être conçu de sorte qu'ils puissent être tués et restaurés à la baisse d'un chapeau, cela ne devrait pas être un problème. Malheureusement, toutes les applications ne peuvent pas être conçues de cette façon, donc est un problème pour beaucoup d'entre nous, peu importe ce que Romain Guy ou quelqu'un d'autre vous dit. Donc, nous devons utiliser des solutions de contournement.

Alors, mon dernier conseil:

  • N'essayez pas de tuer le processus. Appelez finish() sur toutes les activités ou appel moveTaskToBack(true).
  • Si votre processus se bloque ou est tué, et si, comme moi, vous avez besoin des données qui étaient en mémoire et qui sont maintenant perdues, vous devrez revenir à l'activité racine. Pour ce faire, vous devriez appeler startActivity() avec une intention qui contient le Intent.FLAG_ACTIVITY_CLEAR_TOP drapeau.
  • Si vous voulez supprimer votre application de la perspective Eclipse DDMS, il vaut mieux ne pas être au premier plan, ou elle va redémarrer elle-même. Vous devez d'abord appuyer sur le bouton Accueil, et puis tuer le processus.

280



Toutes mes applications ont des boutons de quitter ... et souvent je reçois des commentaires positifs des utilisateurs à cause de cela. Je me fiche de savoir si la plateforme a été conçue de telle sorte que les applications ne devraient pas en avoir besoin. Dire "ne pas les mettre là" est un peu ridicule. Si l'utilisateur veut quitter ... Je leur donne l'accès à faire exactement cela. Je ne pense pas que cela réduit le fonctionnement d'Android et 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.


168



Arrêtez de penser à votre application en tant qu'application monolithique. C'est 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 votre application mystérieuse "fait" n'est pas vraiment important. Supposons qu'il s'introduit dans un intranet d'entreprise super sécurisé, effectue 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 entrés ou sortis 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 met une notification en cours dans la barre de notification en disant "Je suis dans l'intranet ou je cours". Avoir ce service effectuer toutes les fonctionnalités dont vous avez besoin pour votre application. Avoir des activités qui 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 avoir un menu Android -> Quitter (ou se déconnecter, ou autre) bouton qui dit au service de quitter, puis ferme l'activité elle-même.

C'est, à toutes fins utiles exactement ce que vous dites que vous voulez. Fait de la manière Android. Regardez Google Talk ou Google Maps Navigation pour des exemples de cette "sortie" est la mentalité possible. La seule différence est que le fait d'appuyer sur le bouton de retour hors de votre activité peut laisser votre processus UNIX à l'affût au cas où l'utilisateur voudrait faire revivre 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 les plus probables dont il a besoin sont toujours en mémoire, attendant d'être remplacées par d'autres ressources car elles sont chargées maintenant qu'elles ne sont plus nécessaires. Android est la même chose.

Je ne vois vraiment pas ton problème.


134



Ceci est une discussion intéressante et perspicace avec autant d'experts contribuant. Je pense que ce post devrait être refoulé à partir du site principal de développement Android, car il tourne autour de l'un des principaux concepts de l'OS Android.

J'aimerais aussi ajouter mes deux cents ici.

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

Cela dit, je crois toujours qu'il devrait y avoir un Quitter bouton. Pourquoi? ... pas pour moi ou Ted ou aucun des gourous de la technologie ici, mais dans le seul but de répondre à une demande de l'utilisateur final.

Bien que je ne suis pas un grand fan de Windows, il y a longtemps, ils ont introduit un concept auquel la plupart des utilisateurs finaux sont habitués (un bouton X) ... "Je veux quitter un widget quand je le veux".

Cela ne signifie pas que quelqu'un (OS, développeur?) S'en occupera à sa propre 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», et ainsi de suite ... c'est une perception. Il apporte une satisfaction en soi que mon action atteint en effet son but.

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


68



Toi pouvez quitter, soit en appuyant sur Arrière bouton ou en appelant finish() dans ton Activity. Il suffit d'appeler finish() de MenuItem si vous voulez le tuer explicitement.

Romain ne dit pas que ça ne peut pas être fait, juste que c'est inutile: les utilisateurs n'ont pas besoin de quitter ou de sauvegarder leur travail ou autre, car le cycle de vie de l'application vous encourage à écrire des logiciels intelligents qui sauvegardent automatiquement restaure son état, peu importe ce qui se passe.


35



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

Ted a fait remarquer que l'une des applications les plus téléchargées sur le marché est le 'App Killer'. Les gens obtiennent un peu de sérotonine supplémentaire lorsqu'ils quittent les applications. Ils sont habitués avec un ordinateur de bureau / ordinateur portable. Ça fait avancer les choses rapidement. Il maintient le processeur au frais et le ventilateur ne s'allume pas. Il utilise moins de puissance.

Quand vous considérez qu'un appareil mobile est un navire beaucoup plus petit, alors 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 raisonné que l'OS sait mieux et que quitter une application est antique. Je soutiens de tout cœur cela.

Cependant, je crois aussi que vous ne devriez pas frustrer l'utilisateur, même si cette frustration vient de sa propre ignorance. Pour cette raison, je conclus que le fait d'avoir une option 'Quitter' est un bon design, même si c'est principalement un bouton placebo qui ne fait rien de plus que fermer une vue.


31



Ted, ce que vous essayez d'accomplir peut être fait, peut-être juste pas comment vous y pensez en ce moment.

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 Activité, Service. Je pense que vous avez juste besoin d'en savoir plus sur la plate-forme Android; C'est un changement d'état d'esprit d'une application PC standard. Le fait qu'aucun de vos posts n'ait eu le mot "Activité" (en l'absence d'une citation FAQ, c'est-à-dire pas vos mots) en eux me dit que vous devez en lire plus.


28



Article de blog Quand inclure un bouton de sortie dans les applications Android (indice: jamais) l'explique loin, loin mieux que je peux. 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, c'est:    Une façon non ambiguë de garantir qu'une application arrête de consommer des ressources (batterie, cycles du processeur, transfert de données, etc.).

De nombreux utilisateurs perçoivent qu'un bouton de sortie met en œuvre cette exigence   et demandez-lui d'être ajouté. Les développeurs, qui cherchent à plaire à leurs utilisateurs,   ajouter obligeamment un. Peu de temps après, ils échouent tous les deux.

  • Dans la plupart des cas, le bouton de sortie appelle simplement Activity.finish(). C'est exactement équivalent à frapper le bouton de retour.    Exactement.    Les services continuent à fonctionner et l'interrogation continue. Les utilisateurs peuvent penser qu'ils ont tué l'application, mais ils ne l'ont pas, et bientôt   ils seront encore plus agacés.
  • Le comportement de sortie est maintenant 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? Qu'est-ce que doit Arrière faire? Que se passe-t-il s'ils frappent Accueil au lieu? Que se passe-t-il si votre application dispose d'un widget? Le bouton de sortie devrait-il arrêter de mettre à jour aussi?

La solution consiste à faire en sorte que le bouton de retour se comporte comme prévu.   bouton de sortie pour. Mieux encore, arrêtez simplement de consommer des ressources à chaque fois   l'application n'est pas visible.

Allez-y et lisez l'article complet.


23



Je pense que le point est qu'il n'est pas nécessaire de quitter l'application, sauf si vous avez un logiciel bogué. 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 voudrez probablement un moyen de désactiver le service.

Par exemple, Google Listen continue de lire un podcast lorsque l'application n'est pas visible. Mais il y a toujours le bouton pause pour éteindre le podcast lorsque l'utilisateur en a fini avec. Si je me souviens bien, écouter, met même un raccourci dans la barre de notification afin que vous puissiez toujours accéder rapidement au bouton de pause. Un autre exemple est une application comme une application Twitter par exemple qui interroge constamment 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


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 "avez besoin" d'Android.

Ceux qui téléchargent ces petits app Killers appétissants trouvent généralement qu'ils n'aident pas la 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


19