android arrière - Quitter une application est-il mal vu?




15 Answers

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 de déterminer quand mon application va être terminé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 à «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 choses qui se passent dans mon application (les données sont PUSHed sur l'appareil, les listes avec des tâches qui devraient 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. 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 supprimer 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 lorsque vous quittez 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 que votre processus de mise à jour échouera à mi-parcours. Généralement, 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 "Retour" ne tue pas du tout l'application (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 d'une autre manière. Si vous ne pouvez pas écrire des applications qui se comportent comme 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 (n'ai pas encore eu l'occasion de jouer avec 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 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 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 surgissent 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, tels que Hypercard et Smalltalk, ont intégré l'application et les outils de développement dans une configuration unique. Ce concept n'a pas beaucoup retenu l'attention, en dehors des extensions de langage pour les applications (par exemple, VBA dans Excel , 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 malpropres que j'ai découvertes, je pense que le développement de notre application pour Android ne va pas arriver.

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 aussi dans les applications Web (par exemple, pas de «résiliation»). Ou, inversement, un jour, si vous transférez votre application sur le Web, vous trouverez peut-être que le flux de l'application Web est peut-être mieux adapté à Android, et vous pourrez revoir un port Android à ce moment-là.

en plan

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

Question: L'utilisateur a-t-il le choix de tuer l'application à moins de mettre une option de menu pour la 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?




Toutes mes applications ont des boutons de quitter ... et je reçois fréquemment 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.




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 bouton Quitter . Pourquoi? ... pas pour moi ou Ted ou n'importe lequel 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 à savoir une application devrait cesser complètement de fonctionner (maintenant), par une source indépendante, fiable et neutre (OS) à la demande de l'utilisateur final.




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.




Article de blog Quand inclure un bouton de sortie dans les applications Android (Indice: Jamais) l' explique loin, bien mieux que je ne 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 de CPU, transfert de données, etc.).

De nombreux utilisateurs perçoivent qu'un bouton de sortie met en œuvre cette exigence et demande à ce qu'elle soit ajoutée. Les développeurs, qui cherchent à plaire à leurs utilisateurs, en ajoutent 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 fait, 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? Que devrait faire Back ? Que se passe-t-il s'ils frappent Home à la place? Que se passe-t-il si votre application dispose d'un widget? Le bouton de sortie devrait-il arrêter de mettre à jour aussi?

The solution is to make the back button behave as you'd expect the exit button to. Better yet, simply stop consuming resources whenever the app isn't visible.

Go ahead and read the complete article.




If you are unable to fathom how to make your data/connections (and thereby your "application") persistent, then you will be unable to do what you "need" to do with Android.

Those who do download those cutesy little App Killers usually find they do not help battery life or memory usage, but hinder the OS from doing it's job of managing memory efficiently...

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




Answer: (Romain Guy): The user doesn't, the system handles this automatically. That's what the activity lifecycle (especially onPause/onStop/onDestroy) is for. No matter what you do, do not put a "quit" or "exit" application button. It is useless with Android's application model. This is also contrary to how core applications work.

1: Totally exiting an application may be generally unmandatory, but it is not useless. What if windows had no exit option? System would be doggy slow as memory was full and the OS had to guess at which programs you were done with. I don't care what Romain Guy or even Larry Page and Sergey Brin say - these are unquestionable facts: Systems run slower when they have to kill tasks to get their memory before a new app can be launched. You just can't tell me that it doesn't take time to kill an app! Even the light from distant stars take time... There is some use in allowing the user to fully close apps.

2: Contrary to how core applications work? What's that supposed to mean? When I'm done running an app for now, it is no longer doing any work...It's just waiting to be killed by the OS when its memory is needed.

In summary, there is a distinct difference between minimizing and exiting, and neither pinch hits well for the other. Do we leave a screwdriver in every screw? Or a key in every door? Do we leave all of our appliances on high until the breaker blows and we need to turn on another appliance? Do we leave the dish washer full of dishes, and only take out enough each time to make room for some new dirty ones? Do we leave all the cars running in the driveway until -- oh never mind.

If the user wants to minimize an app, then the best thing is to minimize it. If a user wants to exit an app, then by all means it is best to exit.

Is it frowned on? That's Android's view - they frown on it. And many many independent rookie Android developers frown on it.

But when it comes right down to it, there is good coding and bad coding. There is good program flow models and there are bad program flow models.

Leaving programs in memory when the user knows they are done with them simply is not good program flow. It serves absolutely no purpose whatsoever, and it slows things down when launching new apps or when running apps allocate more memory.

It is sort of like your car: There are times when you leave it running, like stopping at a stop light, or perhaps the fast food drive through, or stopping at the ATM. But there are other situations where you do want to shut it off - like when you get to work, or the grocery store or even home.

Similarly, if you're playing a game and the phone rings, yes. Pause the game and keep it running. But if the user is done with the game for a while, then by all means let them exit.

The exit button on some applications should be more out in front than others. Games, for example, or programs where the user is likely to want to fully exit, should have an obvious exit. Other programs, like, perhaps, email programs, where exiting is an unlikely desire (so that it can keep checking for email) -- these programs should not waste prime control input screen space with an exit option, but for good program flow, it should have an exit option. What if someone decides they don't want their mail program trying to check email when they are in poor coverage area, or maybe in a Skype call or whatever? Let them exit the email program if they want!

Suspending and exiting are two vital tasks and neither fulfills the role of the other.




When I conceive an application in Android, I see it this way:

  • You are working with your application
  • The phone rang
  • You take the call
  • At the end of the call, you come back to your application at the same place you were

To do that, you only need the Back button or the Home button of your phone (either by short or long press) and the notification bar.

When I exit my application, I only use the Back button until I am out of it or the Home button.

That's how most of the applications are conceived I think. But if I need some sort of session or connection, I made it clear to the user with a login/logout button and notification (title bar or anything else). This is a rather different style than the pure "exit" style application.

On PCs, you have a multi-GUI desktop, and on Android, you obviously have multi-tasks, but you only display one app at a time (I don't consider widgets here ^^). And on a mobile phone, at anytime, you could have a notification for something more important than what you are doing.

So the whole concept of an application rely on something different that "enter application - work - exit application".




As an Application in an Android context is just a bunch of vaguely related Activities, quitting an Application doesn't really make much sense. You can finish() an Activity, and the view of the previous Activity in the Activity stack will be drawn.




I agree with Ted. I understand that exiting the application is not the "Android way", but it doesn't seem like it should be precluded. Here are three reasons why you might want a real exit to the application (not just the activity):

  1. The user might want some control over which app gets killed in the case of low memory. If important app A is running in the background, then you might like to exit app B when you are done with it so that app A doesn't get killed by the operating system.

  2. If your application has sensitive data cached in memory, you might like to kill the app so that a virus/worm/rogue app can't get at it. I know the security model is supposed to prevent that, but just in case...

  3. If your application uses resources (like network, CPU, sensors, etc.) that could adversely affect the phone, then one way of ensuring that those resources are freed up is to exit the application. I understand that well-behaved apps should free up resources when they are not needed. But again, exiting the application seems like a reasonable way of ensuring that.




First of all, never never never use System.exit(0). It is like making a person sleep punching him on the head!

Second: I'm facing this problem. Before sharing my solution a I want to share my thoughts.

I think that an "Exit Button" is stupid. Really really really stupid. And I think that users (consumer) that ask for an exit button for your application is stupid too. They don't understand how the OS is working and how is managing resources (and it does a great job).

I think that if you write a good piece of code that do the right things (updates, saves, and pushes) at the right moment and conditions and using the correct things (Service and Receiver) it will work pretty well and no one will complain.

But to do that you have to study and learn how things works on Android. Anyway, this is my solution to provide to users an "Exit Button".

I created an Options Menu always visible in each activity (I've a super activity that do that).

When the user clicks on that button this is what happens:

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

So I'm saving in SharedPreferences that I want to kill my app, and I start an Intent. Please look at those flags; those will clear all my backstack calling my DashBoard Activity that is my "home" activity.

So in my Dashboard Activity I run this method in the 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();
    }
}

And it will work pretty well.

The only thing that I don't understand why it's happening is that when I do the last finish (and I've checked: it's following all the correct flow of onPause → onStop → onDestroy) the application is still on the recent activity (but it's blank).

It seems like the latest intent (that has started the DashboardActivity) is still in the system.

I've to dig more in order to also remove it.




I hope things will change over time. The user should be able to kill an app or process if the app process is sandboxed correctly by the OS. There is a notion that apps should be written perfectly or user will use only the apps that follow all SDK recommendations. I think that is a tall order.




Without an exit function for the application developer to kill their own application it is very bad design.

My application needs to allow the user to dynamically change data dynamically during runtime and the user needs to restart my application to make the change effect, but Android did not allow my application restart by itself. Android OS has a very bad design application life cycle.




Every time while you move to the next page through intent, use:

`YourActivityname.this.finish()`;

Exemple:

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

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

So that no activity will be running on background and when you want to Exit your app, use:

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

This exiting worked like a charm for me :)




In any case, if you want to terminate your application you can always call System.exit(0); .




Related

android

Tags

android