Activity "propre"

[freemaul]

En suivant pas mal de tutoriel sur des sites français (frandroid, android france) mais aussi sur le site officiel d'android j'ai remarqué que la façon de programmer une "Activity" n'est pas trés bien explicitée.

Je m'explique, beaucoup (trop) d'application installer via le market laisse tourner en tache de fond un processus une fois la fenêtre fermée, alors qu'un petit System.exit(0); permet de tuer une bonne fois pour toute le thread principal, et donc libérer de l'espace mémoire et du temps pour le CPU.

D'autre applications ouvre des fenêtre à foison, (App Organizer par exemple, si on switch entre "libélé" et "application" on se retrouve avec des doublons).

J'ai donc essayer de me faire un code de base d'une "Activity" qui permet de gérer ce genre de problème, mais étant nouveau dans la programmation java et android je me demande si il n'y a pas beaucoup plus simple. Et j'aimerais avoir votre avis la dessus, pour essayer d'obtenir une base "propre" qui pourra être réutilisable pour d'autre et ainsi arréter de trouver des applications codés avec les pieds ! (désoler du mini coup de gu***** ^^)

-Déclarer l'activity en "Single Instance" dans le manifest

-Créer une fonction quitter qui sauvegarde dans un fichier les données, apelle la fonction Activity.Finish(), puis System.exit(0)

public class MyGame implements Serializable{
   private static final long serialVersionUID = 3305815528208328454L;

   private class MyData implements Serializable{
       private static final long serialVersionUID = -3622772357274762189L;
       public int score;
   }
   private MyData mydata=new MyData();

};

public class GFGame extends Activity

   private MyGame mygame;


   /* gestion des touches */
   @Override
   public boolean onKeyDown(int keyCode, KeyEvent event)
   {
       switch(keyCode)
       {
       /* empécher de quitter brutalement avec la touche retour */
       case KeyEvent.KEYCODE_BACK:
           this.quitter();
           return true;
       /* pour les autres touches, actions par defaut */
       default:
           return super.onKeyDown(keyCode, event);
       }
   }

   public void quitter()
   {
       if(mygame == null)
           quitter2();
       else
       {
           AlertDialog.Builder builder = new AlertDialog.Builder(this);
           builder.setMessage("Etes vous sûr de vouloir quitter ?\\nLes données seront sauvegardées")
                  .setCancelable(false)
                  .setPositiveButton("Oui", new DialogInterface.OnClickListener() {
                  public void onClick(DialogInterface dialog, int id) {
                       quitter2();
                  }
                  })
                  .setNegativeButton("Non", new DialogInterface.OnClickListener() {
                  public void onClick(DialogInterface dialog, int id) {
                       dialog.cancel();
                  }
                  });
           AlertDialog alert = builder.create();
           alert.show();
       }
   }

   private void quitter2()
   {
       try {
           if(mygame != null)
           {
               FileOutputStream fil_out = this.openFileOutput("mygame",MODE_PRIVATE);
               ObjectOutputStream obj_out = new ObjectOutputStream(fil_out);
               obj_out.writeObject(mygame);
           }
           this.finish();
           mNotificationManager.cancelAll();
           System.exit(0);
       } catch (FileNotFoundException e) {
           e.printStackTrace();
           showDialog(DIALOG_NOSAVE);
       } catch (IOException e) {
           e.printStackTrace();
           showDialog(DIALOG_NOSAVE2);
       }
       mygame = null;

   }

[Alocaly]

Dans le fond, je trouve plutot ca bien comme idée, d'expliquer comment quitter notre appli ainsi, mais je tiens à noter que - au moins au début -, les ingé de Google n'étaient pas trop friands de cette idée : pour eux le modèle des activités d'Android se tient tout seul, et quand on manque de ressources, l'OS décide tout seul de tuer des applis qui sont en tache de fond.

Dans les faits... C'est un peu plus compliqué :)

Cela dit, moi je ne fais rien, comme préconisé par Android, et le 'Back' sur mon menu principal marche bien !

Sinon j'aime bien le nettoyage du notification Manager, c'est le genre de détail qu'on peut oublier ( avec les messages )

Emmanuel

Ps : d'ailleurs si quelqu'un peut m'expliquer comment on doit faire pour quitter Retro Defense sans le tuer sauvagement, ca m'interesse !!!

Modifié 12 octobre 2009 par Alocaly

[freemaul]

"pour eux le modèle des activités d'Android se tient tout seul, et quand on manque de ressources, l'OS décide tout seul de tuer des applications qui sont en tache de fond."

Ça me parait bizarre comme solution, comment choisir quelle application tuer ? Et si justement on veut faire une application qui tourne en fond quoi qu'il arrive ? ...

Enfin, sinon personne n'a déjà étudier la solution ? ou à une autre façon de gérer ce problème ? ou bien vous ne vous en préoccupé pas, vous estimer que ça marche très bien comme ça ?

[arnouf]

"pour eux le modèle des activités d'Android se tient tout seul, et quand on manque de ressources, l'OS décide tout seul de tuer des applications qui sont en tache de fond."

Ça me parait bizarre comme solution, comment choisir quelle application tuer ? Et si justement on veut faire une application qui tourne en fond quoi qu'il arrive ? ...

Enfin, sinon personne n'a déjà étudier la solution ? ou à une autre façon de gérer ce problème ? ou bien vous ne vous en préoccupé pas, vous estimer que ça marche très bien comme ça ?

Une application qui tourne en fond ne s'appelle pas une Activity, mais un service

L'application qui a été ouverte mais qui est la plus anciennement non activée parmi toutes les applications qui ont été ouvertes.

[freemaul]

Une activity est elle lancée par un service alors ?

Car quand une activity est fermée, il reste toujours un processus en fond.

Peut on programmer nous même ce service pour gérer nous meme celui ci ?

Ps : je n'ai pas compris ta dernière phrase.

[arnouf]

Une activity est elle lancée par un service alors ?

Car quand une activity est fermée, il reste toujours un processus en fond.

Peut on programmer nous même ce service pour gérer nous meme celui ci ?

Ps : je n'ai pas compris ta dernière phrase.

Une activity peut lancer un service, mais tu peux également implémenter un service qui sera lancé par exemple au boot du device sans qu'une activity quelconque soit lancée.

Ma dernière phrase concerné ta demande d'information sur le fait qu'Android kill une application

pour eux le modèle des activités d'Android se tient tout seul, et quand on manque de ressources, l'OS décide tout seul de tuer des applications qui sont en tache de fond."

Ça me parait bizarre comme solution, comment choisir quelle application tuer ? Et si justement on veut faire une application qui tourne en fond quoi qu'il arrive ? ..

Le choix de l'application se fait sur non utilisation...malgré le fait qu'il soit lancé.

Si tu veux créer quelque chose qui tourne toujours en fond et qui peut lancer un programme on utilisera un service

[freemaul]

Merci pour ces précisions, je vais donc me documenter un peu sur la doc google au sujet des services.