Empêcher la fermeture d'une application

Version imprimable

25/05/2013, 18h04
ChPr

Empêcher la fermeture d'une application

Bonjour à toutes et à tous,

Pour fermer une application, j'appuie sur le bouton "retour" de mon smartphone.

J'aimerais, lorsqu’on appuie sur ce bouton, qu'on propose à l'utilisateur, via un alertDialog de continuer ou stopper l'application ; dans le genre : "Voulez-vous réellement quitter l'application : OUI, NON".

Où placer cet alertDialog ? dans le onStop() ?

et dans le cas où l'utilisateur veut poursuivre l'application, quel code va éviter sa fermeture ?

Merci de votre aide.

Pierre

Il faut créer un évenement lors du clic sur le bouton

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
 
Override
public boolean onKeyDown(int keyCode, KeyEvent event)  {
      if (keyCode == KeyEvent.KEYCODE_BACK) {
 
 
// Creation de l'AlertDialog
 
//=> Si Quitter finish(); + return true;
//=> Sinon return false;
 
 
      }
 
   return super.onKeyDown(keyCode, event);
}

25/05/2013, 20h33
Hizin

À savoir que ce genre de procédé est mal vu par un bon nombre d'utilisateurs, cassant la logique de navigation standard permettant de revenir en arrière et de quitter via le bouton "back".
Il y a aussi le cas du bouton "home", qui rend ce genre de comportement incohérent (l'utilisateur doit passer par une confirmation via le bouton retour, mais pas via le home).
26/05/2013, 03h47
nicroman

Alors en fait, c'est une très mauvaise idée... d'ailleurs contraire à l'esprit Android.

Non, l'appui sur le bouton back ne ferme pas une application, cela ne fait que revenir à l'activité précédente.
Il se peut que cette activité soit le launcher, mais peu importe... Back ne ferme pas une application.
D'ailleurs Home non plus (il ne fait que faire passer le launcher à l'avant plan).

Ceci est d'autant plus vrai pour les "petites" applications en Java. Il n'y a aucun intérêt à "quitter" une application. Tout est fait dans le système pour que l'utilisateur ne "voie" les applications que comme des activités additionnelles et je trouve dommage de proposer un joli "exit" (dans un menu) qui va alourdir l'expérience utilisateur, et ralentir le re-lancement de l'application (ben oui menu "last application", clic sur la dernière activité par exemple, ce devrait être instantané...).

Le système s'occupe de tout: envoyer les onPause/onStop/onDestroy aux activités pour rendre les ressources que celles-ci utilisent au système....
Et même l'objet "Application" reçoit les évenement de fermeture / ouverture.

http://android.nextapp.com/site/fx/doc/exit

Au fait, même windows (avec windows 8) commence à ne plus proposer d'option pour "quitter" ... fini la croix rouge !
26/05/2013, 12h15
ChPr

Je vous remercie pour vos propositions et mises en garde vis à vis du principe même d' Androïd.

Pourquoi je souhaite faire cela : tout bonnement parce que mon bouton "retour" est d'une sensibilité et susceptibilité extrême et cela me gêne énormément dans mon application de navigation où je "casse" le relevé d'un tracé en cours si par mégarde mon doigt passe sur ce bouton.

Cordialement.

Pierre
26/05/2013, 19h16
nicroman

Ha ben ça veut dire qu'il y a un soucis de conception... Si une application doit faire des choses pendant un certain temps, elle ne doit pas se baser sur l'activité. Celle-ci peut être détruite dans plein de cas: reception d'un appel, passage en veille, etc....

Je m'explique.... L'application devrait avoir 2 parties:
* Une activité, qui permet de voir un tracé en cours (si il y en a un), et deux boutons:
- Arrêter: coupe le tracé en cours (et arrête le service d'enregistrement)
- Démarrer: affiche le tracé en cours (et démarre le service d'enregistrement).
* Un service (d'avant-plan en général), qui, si actif, affiche une notification android. Cette notification permet de lancer l'activité. Pendant qu'il tourne le service enregistre ce qui doit être enregistré.

Voilà....
Pas besoin de bouton "quit".
26/05/2013, 20h56
ChPr

Citation:

Envoyé par nicroman

... L'application devrait avoir 2 parties:
* Une activité, qui permet de voir un tracé en cours (si il y en a un), et deux boutons:
- Arrêter: coupe le tracé en cours (et arrête le service d'enregistrement)
- Démarrer: affiche le tracé en cours (et démarre le service d'enregistrement). ...

J'ai.

Citation:

Envoyé par nicroman

... * Un service (d'avant-plan en général), qui, si actif, affiche une notification android. Cette notification permet de lancer l'activité. Pendant qu'il tourne le service enregistre ce qui doit être enregistré. ...

Désolé, je n'ai pas compris :(.

Ce que j'ai remarqué est que, lorsque j'appuie sur le bouton "retour", onDestroy est appelé. Je suppose qu'après cela, il ne reste pas grand chose de mon activité et des enregistrements qui étaient en cours. Je profite d'ailleurs de cet évènement pour enregistrer mes paramètres en cours et stopper les enregistrements que j'aurais oubliés de faire avant de quitter mon application (ma méconnaissance d'Android m'incite à fermer correctement tout ce qui doit l'être avant que l'application soit définitivement fermée).

Cordialement.

Pierre.

Oui, c'est bien ce que je crains...

Il y a un mix entre le service lui-même (enregistrer des positions si j'ai bien compris), l'objet "Activity" au sens de Java, et l'activité au sens de l'utilisateur (qui est une interface de pilotage / représentation du service)...

Citation:

Ce que j'ai remarqué est que, lorsque j'appuie sur le bouton "retour", onDestroy est appelé.

onDestroy est appelé à chaque fois que l'objet java représentant l'activité va être détruit... Cela ne veut pas dire que l'activité n'existe plus pour l'utilisateur, le système pouvant la réveiller par un onCreate (avec un Bundle correct) un peu plus tard.

Prenons un exemple:

L'utilisateur lance l'activité:
Code:

1 2 3 4 5 6 Le système va créer l'application nécessaire (si pas déjà en mémoire): application.onCreate() Puis l'activité (grace au manifest): activity1 activity1.onCreate() activity1.onStart() activity1.onResume()
L'utilisateur clique sur démarrer.

Code:

activity1.onClick()

L'utilisateur reçoit un appel, la fenêtre d'appel overlap l'activité:

Code:

activity1.onPause()

L'utilisateur accepte l'appel (et donc switch d'application)

Code:

activity1.onStop()

Le système a besoin de mémoire
Code:

1 2 activity1.onSaveInstanceState() activity1.onDestroy()
L'utilisateur quitte l'appel
Code:

1 2 3 4 Le système ramène l'utilisateur sur l'activité précédente, et va donc instancier un nouvel objet activity2 activity2.onCreate(bundle) activity2.onStart() activity2.onResume()
Voilà: activity1 et activity2 sont deux instances différentes de la même classe... mais pour l'utilisateur, c'est la MÊME activité ! et rien ne doit être modifié entre les deux, et si il y a eu enregistrement de quelque chose, celui ci doit avoir continué en arrière-plan...

D'où le passage par un Service celui-ci se charge de l'action demandée par l'utilisateur (par le onClick()), même si l'activité n'est plus en avant-plan !
Au retour de l'utilisateur sur l'activité, le service est toujours là, bien actif, et a continué de réaliser ce pour quoi il est fait.

26/05/2013, 22h46
ChPr

Merci pour ces explications.

Je m'aperçois bien que si mon application est interrompue par un coup de téléphone, quand je reviens à elle, est est toujours active dans le même état.

Pour autant. Si je stoppe mon application par le bouton "retour" et que je la relance, je ne la retrouve pas dans l'état dans laquelle elle était, mais dans son état d'initialisation tel que je l'ai défini. C'est par ailleurs, ce que je souhaite.

Donc, l'appui intempestif sur le bouton "retour" me gêne, et c'est pour cela que je souhaite demander une confirmation.

Mais peut-être que je n'ai strictement rien compris et que je ne fais pas ce qu'il faut ; que faire ?

Mais pour l'instant, l'appui sur le bouton "retour" me stoppe mon application et si je la relance, je la trouve dans son état initial : c'est ce que je veux.

Cordialement.

Pierre