Restitution d'une "view" en remettant en avant-plan une appli qui était en arrière-plan

Bonjour,

J'ai écrit une appli qui permet de passer des commandes, en tant que "client", via socket TCP/IP à une autre appli (le serveur) qui tourne sur un PC.
Cette appli prend la forme d'un clavier avec des touches particulières, dédiées aux commandes à envoyer.

La première chose à faire est évidemment d'établir la connexion TCP/IP, en appuyant que un bouton "CONNECT".
Lorsque la connexion est établie ce bouton prend l'inscription "DISCONNECT".

Jusque là OK.

Maintenant, lorsque j'appuie sur l'icône "retour" du portable ou de la tablette, l'appli passe en arrière-plan.
Et lorsque que je réactive l'appli en cliquant dessus (depuis le "pool" d'applis en arrière-plan), mon bouton CONNECT/DISCONNECT est repassé en mode "CONNECT", bien que je réactualise son état en fonction d'une variable qui mémorise l'état de connexion, dans la méthode onStart(), qui est rappelée lors de la restitution en avant-plan.

Autrement dit, tout se comporte comme si les variables étaient réinitialisées, alors qu'apparemment, le socket TCP/IP fonctionne toujours correctement.

Désolé: pas très commode à expliquer.
Quelqu'un peut m'indiquer ce que je rate ?

Et surtout, la grosse question: est-ce qu'une appli mise en arrière-plan conserve l'état de ses variables, ou non?

Je soupçonne que la solution tourne autour de onSaveInstanceState(), mais, habitué aux environnements d'OS classiques, je trouve ça très déroutant.
Un exemple simple serait bienvenu.

Merci d'avance.

Jean-Pierre

[QUOTE=jppillou;8064383]Bonjour,[QUOTE]
Bonsoir !

Citation:

J'ai écrit une appli qui permet de passer des commandes, en tant que "client", via socket TCP/IP à une autre appli (le serveur) qui tourne sur un PC.
Cette appli prend la forme d'un clavier avec des touches particulières, dédiées aux commandes à envoyer.

La première chose à faire est évidemment d'établir la connexion TCP/IP, en appuyant que un bouton "CONNECT".
Lorsque la connexion est établie ce bouton prend l'inscription "DISCONNECT".

Jusque là OK.

En fait pas sur que ce soit OK... l'interêt d'un mobile (et donc des applications qui tournent dessus) est justement d'être mobiles... les connexions TCP/IP sont très souvent interrompues / de nouvelles adresses IP données... bref, une connexion "permanente" n'est pas forcément un bon choix.
En général dans une communication client / serveur, on préfère passer par des protocoles "connexion-less" comme HTTP (enfin, c'est pas tout à fait vrai, puisque HTTP permet de conserver une connexion ouverte si besoin, et de la recréer à la demande). D'autant que le système offre tout un tas d'outils pour cela, et que debugger une requete HTTP est souvent plus simple que de debugger un stream...

Citation:

Maintenant, lorsque j'appuie sur l'icône "retour" du portable ou de la tablette, l'appli passe en arrière-plan.

En fait pas vraiment... on revient à l'activité (ou l'état de fragment) précédent. Le bouton "back" indique textuellement: je veux quitter cette activité (et donc ne pas y revenir), et voir l'activité précédente (ce qui peut être le launcher). A ne pas confondre avec le bouton "home" qui est un raccourci pour afficher le launcher. L'activité est alors effectivement placée en arrière plan, et l'activité "launcher" affichée.

Citation:

Et lorsque que je réactive l'appli en cliquant dessus (depuis le "pool" d'applis en arrière-plan), mon bouton CONNECT/DISCONNECT est repassé en mode "CONNECT", bien que je réactualise son état en fonction d'une variable qui mémorise l'état de connexion, dans la méthode onStart(), qui est rappelée lors de la restitution en avant-plan.

Oui... en fait une nouvelle activité est crée, puisque l'ancienne ne sert plus à rien: on l'a quitté !

Citation:

Autrement dit, tout se comporte comme si les variables étaient réinitialisées, alors qu'apparemment, le socket TCP/IP fonctionne toujours correctement.

C'est normal, sauf pour le socket. A moins que tu n'aies oublié de le fermer dans onDestroy ?
Attention aussi à la rotation de l'écran qui "refait" une nouvelle activité (à partir du même intent), donc appel de onCreate/onDestroy

Citation:

Et surtout, la grosse question: est-ce qu'une appli mise en arrière-plan conserve l'état de ses variables, ou non?

Pas toujours... Une application en "arrière-plan" peut à tout moment être détruite par le système pour récupérer de la mémoire ou des ressources.

Citation:

Je soupçonne que la solution tourne autour de onSaveInstanceState(), mais, habitué aux environnements d'OS classiques, je trouve ça très déroutant.

Effectivement le système va, avant de détruire précipitament une activité sauver son état par onSaveInstanceState(). Lors de la re-création de celle-ci (quand l'utilisateur reviendra sur l'appli), onRestoreInstanceState() sera appelé. Ce comportement est aussi utilisé lors de la rotation d'écran.

A noter que les activités ont une implémentation par défaut, qui va stocker le contenu de tous les "choix" utilisateurs (état d'un bouton, contenu d'un TextEdit, choix d'un Spinner, etc...).

Citation:

Un exemple simple serait bienvenu.

Pas vraiment d'exemple...

Cas de l'activité non détruite:

onCreate(null) est d'abord appelé
onStart()
onResume()
=> une autre application doit arriver devant <=
onPause()
onStop()
=> le système rappelle l'activité (même instance) <=
onStart()
onResume()

Cas de l'activité détruite:

onCreate(null) est d'abord appelé
onStart()
onResume()
=> une autre application doit arriver devant <=
onPause()
onStop()
=> le système a besoin de mémoire <=
onSaveInstanceState(bundle)
onDestroy()
=> le système recréel'activité (nouvelle instance) <=
onCreate(bundle) <= oui le même "bundle" que celui passé à onSaveInstanceState
onRestoreInstanceState(bundle)
onStart()
onResume()

Cas de la rotation d'écran:
onCreate(null) est d'abord appelé
onStart()
onResume()
=> rotation d'écran <=
onPause()
onStop()
onSaveInstanceState(bundle)
onDestroy()
=> le système recréel'activité (nouvelle instance) <=
onCreate(bundle) <= oui le même "bundle" que celui passé à onSaveInstanceState
onRestoreInstanceState(bundle)
onStart()
onResume()

Bonjour,

Merci pour toutes ces précisions. Ca éclaire bien.
Il faut vraiment que je laisse tomber mes habitudes liés aux OS classiques, et que je comprenne mieux comment Android fonctionne.
Mais dans l'immédiat, j'ai les réponses à mes questions.

Encore merci.