Fermeture d'une application - est qui attaquaient?

Question

De passer dans ma tentative d'apprendre Android, je viens de lire ce qui suit:

Question: les utilisateurs ont un choix de tuer l'application à moins de mettre une option de menu à la tuer? Si une telle option existe, comment l'utilisateur de mettre fin à l'application?

Réponse: (Romain Guy): L'utilisateur n'est pas, le système gère automatiquement. C'est ce que l'activité du cycle de vie (surtout onPause/onStop/onDestroy). Quoi que vous fassiez, ne pas mettre une "quitter" ou "quitter" bouton de l'application. Il est inutile avec Android de l'application du modèle. C'est aussi contraire à la façon dont les applications de base de travail.

Hehe, pour chacun de mes pas dans le monde Android je tombe sur un type de problème =(

Apparemment, vous ne pouvez pas quitter une application sur Android (mais le système Android peut totalement détruire votre application à chaque fois qu'elle se sent comme elle). Qu'est-ce qui? Je commence à penser qu'il est impossible d'écrire une application qui fonctionne comme un "normal app" -, que l'utilisateur peut quitter l'application quand il/elle décide de le faire. Ce n'est pas quelque chose qui devrait être fondée sur l'OS pour le faire.

L'application que je suis en train de créer n'est pas une application pour Android Market. Il n'est pas une application pour "l'utilisation à grande échelle" par le public en général, c'est une application d'entreprise qui est destiné à être utilisé dans un sens très étroit domaine d'activité.

En réalité, j'étais vraiment impatient de développement de la plate-forme Android, car il répond à beaucoup de questions qui existent dans Windows Mobile et .NET. Cependant, la semaine dernière, a été quelque peu d'une bretelle de sortie pour moi... j'espère que je n'ai pas à abandonner Android, mais il n'a pas l'air très bien en ce moment =(

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

Answer 1

Ce sera finalement arriver à votre question, mais je veux d'abord répondre à un certain nombre de questions que vous soulevez dans vos commentaires divers pour les différentes réponses déjà fournies au moment de cette écriture. Je n'ai pas l'intention de changer votre esprit -- ou plutôt, ce sont ici pour les autres qui viennent de lire ce post dans l'avenir.

Le point est que je ne peux pas permettre de Android pour déterminer quand mon application est va être résilié. qui doit être le choix de l'utilisateur.

Des Millions de personnes sont parfaitement heureux avec le modèle de l'environnement, ferme l'application en tant que de besoin. Ces utilisateurs n'ont tout simplement pas penser à "la résiliation de" l'application Android, pas plus qu'ils ne pensent à propos de "terminaison" une page Web ou de "terminaison" un thermostat.

les utilisateurs d'iPhone sont beaucoup de la même manière, en cliquant sur le bouton iPhone n'a pas nécessairement de "sentir" que l'app a été résilié, depuis de nombreuses apps iPhone reprendre là où l'utilisateur l'a laissée, même si l'application était vraiment arrêter (comme l'iPhone ne permet qu'une seule application tierce à un moment, à l'heure actuelle).

Comme je l'ai dit ci-dessus, il y a beaucoup de choses qui se passent dans mon application (données en cours d' Poussé à l'appareil, les listes de tâches qui doit toujours être là, etc).

Je ne sais pas ce que "listes de tâches qui doivent toujours être là", mais les "données d'être Poussé à l'appareil" est une agréable fiction et ne doit pas être fait par une activité, en tout cas. L'utilisation d'une tâche planifiée (via AlarmManager) de mettre à jour vos données pour un maximum de fiabilité.

Nos utilisateurs de se connecter et ne peut pas être fait chaque fois qu'ils reçoivent un coup de téléphone et Android décide de tuer l'application.

Il existe de nombreuses applications iPhone et Androïde qui traitent de ce. Généralement, c'est parce qu'ils détiennent sur les informations d'identification d'ouverture de session, plutôt que de forcer les utilisateurs à se connecter à chaque fois manuellement.

Par exemple, nous voulons vérifier les mises à jour lorsque vous quittez l'application

C'est une erreur sur n'importe quel système d'exploitation. Pour tous vous le savez, la raison pour laquelle votre demande est "sorti" c'est parce que l'OS est en cours d'arrêt, et ensuite, votre processus de mise à jour échoue à mi-parcours. En général, ce n'est pas une bonne chose. Vérifier les mises à jour sur démarrer ou vérifier les mises à jour totalement asynchrone (par exemple, via une tâche planifiée), de ne jamais quitter.

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

Appuyez sur le bouton RETOUR ne pas "tuer l'application". Il termine l'activité qui était à l'écran lorsque l'utilisateur appuie sur le bouton RETOUR.

Il ne doit se terminer lorsque l' Les utilisateurs veulent y mettre fin, jamais jamais de toute autre manière. Si vous ne pouvez pas écrire les applications qui se comportent comme ça dans Android, puis je pense qu'android ne peut pas être utilisé pour l'écriture réel apps =(

Alors ni peut les applications Web. Ou WebOS, si je comprends leur modèle correctement (n'ont pas eu la chance de jouer avec encore). Dans toutes ces applications, les utilisateurs de ne pas "mettre fin" à quoi que ce soit-ils les abandonnent. l'iPhone est un peu différent, en ce qu'il ne actuellement permet à une chose à la fois (avec quelques exceptions), et donc le fait de quitter implique une assez résiliation immédiate de l'application.

Est-il un moyen pour moi de vraiment arrêter l'application?

Comme tout le monde vous l'a dit, les utilisateurs (par l'ARRIÈRE) ou votre code (via finish()) peuvent se fermer actuellement en cours d'exécution de l'activité. Les utilisateurs n'ont généralement pas besoin d'autre chose, de bien-écrit applications, pas plus qu'ils ont besoin d'une option "quit" pour l'utilisation des applications Web.

---

Pas de deux environnements d'application sont les mêmes, par définition. Cela signifie que vous pouvez voir les tendances dans les environnements de nouvelles questions se posent et d'autres s'enterrent.

Par exemple, il y a un mouvement de plus en plus pour essayer d'éliminer la notion de "fichier". La plupart des Web apps ne pas forcer les utilisateurs à penser de fichiers. les applications de l'iPhone n'est généralement pas forcer les utilisateurs à penser de fichiers. Les applications Android en général de ne pas forcer les utilisateurs à penser de fichiers. Et ainsi de suite.

De même, il y a un mouvement de plus en plus pour essayer d'éliminer la notion de "terminaison" une application. La plupart des Web apps ne force pas l'utilisateur de se déconnecter, mais plutôt implicitement journal de l'utilisateur après une période d'inactivité. Même chose avec Android, et dans une moindre mesure, de l'iPhone (et, éventuellement, WebOS).

Cela nécessite davantage l'accent sur la conception de l'application, en se concentrant sur les objectifs de l'entreprise et ne collant pas avec un modèle de mise en œuvre liée à une demande précédente de l'environnement. Les développeurs qui n'a pas le temps ou l'envie de le faire ce sera frustré avec de nouveaux environnements qui cassent leur modèle mental. Ce n'est pas la faute de l'environnement, pas plus que c'est la faute d'une montagne pour les tempêtes qui coule autour d'elle plutôt qu'à travers elle.

Par exemple, certains environnements de développement, comme Hypercard et Smalltalk, si l'application et le développement des outils de co-mêlés dans une installation. Ce concept n'a pas pris beaucoup, en dehors de la langue des extensions pour les applications (par exemple, VBA dans Excel, LISP dans AutoCAD). Les développeurs qui sont venus avec des modèles mentaux qui présume l'existence d'outils de développement dans l'application elle-même, donc, que ce soit dû changer de modèle ou de se limiter à des environnements où leurs modèle serait vrai.

Donc, quand vous écrivez:

Le long de avec d'autres désordonné des choses que je découvert, je pense que le développement de notre app pour Android ne va pas se produire.

qui semble être pour le mieux, pour vous, pour maintenant. De même, je voudrais vous conseiller à l'encontre de la tentative de port de votre application pour le Web, depuis certains des mêmes problèmes que vous avez signalé avec Android, vous trouverez dans les applications Web (par exemple, pas de "résiliation"). Ou, à l'inverse, un jour, si vous n' port de votre application pour le Web, vous pouvez constater que l'application Web de l'écoulement peut être un meilleur match pour Android, qui vous permet de retrouver un Android port à l'époque.

Answer 2

Je voudrais juste ajouter une correction, pour les futurs lecteurs de ce fil. Cette nuance a échappé à ma compréhension pour un long moment donc je veux vous assurer qu'aucun de vous faire les mêmes erreurs:

System.exit() ne pas tuer votre application si vous avez plus d'une activité sur la pile. Ce qui se passe réellement est que le processus est tué et immédiatement redémarré avec un moins d'activité sur la pile. C'est aussi ce qui se passe lorsque votre application est tué par la Force de Fermer la boîte de dialogue, ou même lorsque vous essayez de tuer le processus de DDMS. C'est un fait qui est entièrement sans-papiers, à ma connaissance.

La réponse courte est, si vous voulez sortir de votre application, vous avez obtenu de garder une trace de toutes les activités dans votre pile et finish() TOUS lorsque l'utilisateur veut quitter (et non, il n'y a pas de moyen pour parcourir par le biais de l'Activité de la pile, de sorte que vous avez à gérer tout cela, vous-même). Même si cela ne l'a pas fait tuer le processus ou tout en balançant les références que vous pourriez avoir. Simplement, il termine les activités. Aussi, je ne suis pas sûr qu' Process.killProcess(Process.myPid()) fonctionne mieux; je n'ai pas testé.

Si, d'autre part, il est acceptable pour vous d'avoir des activités restantes dans votre pile, il y a une autre méthode qui rend les choses très facile pour vous: Activity.moveTaskToBack(true) sera tout simplement l'arrière-plan de vos processus et de montrer l'écran d'accueil.

La réponse longue implique 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 dans le fond le processus prendra fin à l'amende juste. Toutefois, si elle est au premier plan, le système suppose que l'utilisateur veut continuer à faire tout ce qu'il/elle était en train de faire. (Si vous êtes en essayant de tuer le processus de DDMS, vous devez appuyez sur le bouton de la maison d'abord, puis de le tuer)
2. Il suppose également que chaque activité est indépendante de toutes les autres activités. C'est souvent le cas, par exemple dans le cas où votre application lance l'Activité du Navigateur, qui est totalement indépendante et n'a pas été écrit par vous. L'Activité du Navigateur peut ou ne peut pas être créé sur la même Tâche, en fonction de son manifeste attributs.
3. Il suppose que chacune de vos activités est complètement autonomes et peuvent être tués/restauré dans la notification d'un moment. (Je n'aime pas cette hypothèse donnée, depuis mon application a de nombreuses activités qui s'appuient sur une grande quantité de données mises en cache, trop grande pour être efficace sérialisé pendant onSaveInstanceState, mais whaddya vas faire?) Pour la plupart, bien écrite Android apps ce doit être vrai, puisque vous ne savez jamais quand votre application va être tué dans l'arrière-plan.
4. Le dernier facteur n'est pas tellement une hypothèse, mais plutôt d'une limitation de l'OS: tuer l'application explicitement est le même que l'application de s'écraser, et aussi le même que Android tuer l'application pour récupérer de la mémoire. Ce qui culmine dans notre coup de grâce: depuis Android ne peut pas dire si l'application abandonnées ou en panne ou a été tué dans le fond, il suppose que l'utilisateur veut retourner là d'où ils l'avaient laissée, et donc la ActivityManager redémarre le processus.

Quand vous pensez à ce sujet, ce qui est approprié pour la plate-forme. Tout d'abord, c'est exactement ce qui se passe lorsque le processus est tué dans l'arrière-plan et l'utilisateur revient à elle, donc elle a besoin d'être redémarré où il l'avait laissé. La seconde, c'est ce qui se produit lorsque l'application se bloque et présente la redoutable Force de Fermer la boîte de dialogue.

Dire que je veux que mes utilisateurs d'être en mesure de prendre une photo et la télécharger. J'ai lancer l'Activité de la Caméra de mon activité, et de lui demander de renvoyer une image. La Caméra est poussé sur le haut de ma Tâche en cours (plutôt que d'être créé à sa propre Tâche). Si l'Appareil photo a une erreur et il se bloque, cela devrait entraîner l'ensemble de l'application de s'écraser? Du point de vue de l'utilisateur, seulement l'Appareil a échoué, et ils doivent être retournés à leurs activités précédentes. Jusqu'à ce qu'il redémarre le processus avec tous les mêmes Activités dans la pile, moins de la Caméra. Depuis vos Activités devraient être conçus de sorte qu'ils peuvent être tués et restauré à la baisse d'un chapeau, cela ne devrait pas être un problème. Malheureusement, pas toutes les applications peuvent être conçues de cette manière, donc c' est un problème pour beaucoup d'entre nous, peu importe ce que Romain Guy ou quelqu'un d'autre vous dit. Donc, nous avons besoin d'utiliser des solutions de contournement.

Donc, ma clôture des conseils:

• N'essayez pas de tuer le processus. Soit appelez - finish() sur toutes les activités ou appelez - moveTaskToBack(true).
• Si votre processus se bloque ou se fait tuer, et si, comme moi, vous avez besoin des données dans la mémoire qui est maintenant perdu, vous aurez besoin de revenir à la racine de l'activité. Pour ce faire, vous devez appeler startActivity() avec une Intention qui contient l' Intent.FLAG_ACTIVITY_CLEAR_TOP drapeau.
• Si vous voulez tuer votre application à partir de l'Éclipse DDMS point de vue, il vaut mieux ne pas être au premier plan, ou il redémarre de lui-même. Vous devez appuyer sur le bouton de la Maison d'abord, et ensuite de tuer le processus.

Answer 3

Toutes mes applications ont cessé de boutons... et je suis assez souvent obtenir de bons commentaires des utilisateurs à cause de cela. Je n'ai pas de soins si la plate-forme a été conçue de manière que les applications ne devraient pas en avoir besoin. L'expression "ne pas mettre là" est un peu ridicule. Si l'utilisateur veut quitter... je leur fournir l'accès à de faire exactement cela. Je ne pense pas qu'il réduit les comment Android fonctionne à tous et semble comme une bonne pratique. Je comprends le cycle de vie... et de mon observation a été que Android ne fait pas un bon travail lors de la manipulation.... et c'est un fait.

Answer 4

Cesser de penser à votre application comme une application monolithique. C'est un ensemble d'écrans d'INTERFACE utilisateur que l'utilisateur peut interagir avec votre "application", et de "fonctions" fourni par Android services.

Ne sachant pas ce que votre mystérieux app "ne" n'est pas vraiment important. Imaginons qu'il tunnels dans certains super sécurisé à l'intranet de l'entreprise, exécution de certaines activités de surveillance ou d'interaction et reste connecté jusqu'à ce que l'utilisateur quitte l'application". Parce que votre service informatique des commandes, les utilisateurs doivent être conscients quand ils sont DANS ou HORS de l'intranet. Par conséquent, votre mentalité de étant important pour les utilisateurs de "quitter".

C'est simple. Un service qui met en cours de notification dans la barre de notification en disant: "je suis dans l'intranet, ou je suis en cours d'exécution". Ont que le service effectuer toutes les fonctionnalités dont vous avez besoin pour votre application. Ont des activités qui se lient à ce service pour permettre à vos utilisateurs d'accéder aux bits de l'INTERFACE utilisateur, ils ont besoin d'interagir avec votre "application". Et avoir un Android Menu -> Quit (ou de déconnexion, ou quoi que ce soit) bouton qui indique le service de cesser de fumer, puis ferme l'activité elle-même.

C'est, pour toutes fins utiles, exactement ce que vous dites que vous voulez. Fait Android. Regardez Google Talk ou Google Maps Navigation pour des exemples de cette "sortie" est possible mentalité. La seule différence est qu'en appuyant sur bouton retour de votre activité pourrait laisser votre processus UNIX à l'affût au cas où l'utilisateur veut relancer votre application. Ce n'est pas différent d'un système d'exploitation moderne qui met en cache récemment accédé à des fichiers dans la mémoire. Après que vous quittez votre programme de windows, le plus probable de ressources qu'il faut, ce sont encore dans la mémoire, en attente d'être remplacés par d'autres ressources comme ils sont chargés, maintenant qu'ils ne sont plus nécessaires. Android est la même chose.

Je ne vois vraiment pas votre problème.

Answer 5

C'est une question intéressante et perspicace de discussion avec de nombreux experts qui ont contribué. Je crois que ce post devrait être bouclée à partir de l'intérieur de l'android dev principal site web, car il ne s'articulent autour de l'un des principaux modèles de système d'exploitation android.

Je tiens aussi à ajouter mes 2 cents ici.

Jusqu'à présent j'ai été impressionné par Android manière de gérer les événements de cycle de vie, portant le concept de web comme des applications natives.

Cela dit je persiste à croire qu'il devrait y avoir un bouton Quitter. Pourquoi .. pas pour moi ou ted ou de l'un des tech des gourous ici, mais dans le seul but de satisfaire à une demande des utilisateurs finaux.

Si je ne suis pas un grand fan de Windows, mais depuis qu'ils ont introduit un concept que la plupart des utilisateurs sont utilisées pour (bouton X) ... "je veux arrêter l'exécution d'un widget quand" je "veux". Cela ne signifie pas que quelqu'un (OS, développeur ?) prendra soin de cela à son/sa/ses propre descretion... cela veut tout simplement dire "où est mon bouton X Rouge que je suis habitué". Mon action doit être analogue à "mettre fin à un appel en appuyant sur un bouton", "d'éteindre l'appareil en appuyant sur un bouton" ainsi de suite et ainsi de suite ... c'est une perception. Il apporte une satisfaction de soi que mon action est en effet de parvenir à ses fins.

Même si un développeur peut usurper ce comportement à l'aide des suggestions ici, la perception reste c'est à dire une application doit cesser totalement de la fonction (Maintenant), par un organisme indépendant, fiable et neutre de la source (OS) sur demande de l'utilisateur final.