Pourquoi créer des Activity sans les déclarer dans AndroidManifest ?

bonjour,

je fais des erreurs de débutant (que je suis) en tapant tout à la main car Eclipse fait peu de chose à ma place (en tout cas il faiut pas tout le travail minimal).

Voilà, je crée une nouvelle activity, donc le fichier xml, et le fichier .java correspondant, avecl e code qui va bien dedans sans souci.

Ensuite (débutant android que je suis), j'oublie de déclarer cette activity dans le AndroidManifest et je compile et lance mon application pour la tester.

ça ne plante pas à la compilation ni au lancement de l'app dans le device, pas d'erreur notifiée nullepart (sauf si j'utilise le code qui a besoin de ma nouvelle activity dans mon application).?

Donc je me dis "mais le compilateur est fou ou quoi , il a oublié de m'alerter que j'ai des activity non déclarées".

Soit il me laisse faire car il y a une raison (une raison pour avoir des activity non déclarée ?)
Soit le compilateur n'est pas parfait sur ce point là (j'en doute sérieusement).

qu'en pensez-vous ?

Je me dis que peut-être (comme en php), on peut déclarer des Activity dynamaiquement plutôt que les déclarer dès le départ dans le manifest.
peut-on ?
si oui, est-ce (comme en php) par un souci de mémoire utilisée au départ (moindre) ?

A mon avis c'est juste que le compilateur ne vérifie pas.
En même temps c'est chaud a vérifier, une Activity c'est juste une classe qu'extends Activity...
En plus des fois dans un package tu peux avoir une Activity qui traine là et qui sert à rien, que t'as juste oublié de supprimer.

Et aussi bien tu finiras toujours pas faire planter le programme, puisque tu va bien essayer d'afficher au moins une fois l'Activity.

Quand tu seras un peu moins débutant, tu penseras a déclarer tes Activity dans le Manifest.

Citation:

---

Envoyé par thierrybenji

A mon avis c'est juste que le compilateur ne vérifie pas..

---

c'est bien dommage car Eclipse vérifie même les variables que tu déclares mais n'utilise pas!

Arf, qui peut le plus ne peut pas le moins !

C'est plus simple de vérifier des variables que de vérifier si toutes les Activity sont déclaré dans le Manifest...

Citation:

---

Envoyé par thierrybenji

C'est plus simple de vérifier des variables que de vérifier si toutes les Activity sont déclaré dans le Manifest...

---

Je suis de l'avis contraire car des variables ont en déclare un peu partout dans chaque fichier .java alors que les Activity, les xml sont tous centralisés dans layout.
(mode débutant), sauf erreur chaque .xml de activity doit être référencé dans le manifest. Donc facile à compter ou voir si il en manque une.

Ce que tu mentionnes n'est pas du ressort d'un compilateur, mais par contre le serait du plugin ADT.

Détecter a partir de l'héritage ?
Rien ne dit qu'un objet de cette classe est instancié dans le code...
La déclaration d'une classe "Activity" n'est pas suffisante (on peut surcharger cette classe, même dans un autre projet !)

Détecter à partir de 'startActivity' ?
Le lancement d'une activité se fait toujours par startActivity(class). Hors cette classe peut très bien être dynamique...
par exemple:

Code:

---

1 2 3

Class<?> activityClass = Class.forName(getString(R.string.destActivity)); startActivity(activityClass,this);

---

Déjà ça devient plus difficile pour le compilateur de traquer ça non ?

Mais Eclipse/ADT/IDE/... pourrait proposer un wizard de création (ou ajouter à son wizard de création de classe la détection de) un truc "create activity" qui pourrait le rajouter dans le manifest au bon endroit.
Même si je pense que la notion de "bon endroit" peut être nébuleuse dans le cas d'une application avec plusieurs noeud "application" (euh ... est-ce que c'est possible au moins ?).

Quand on créer un projet Android, ça créer une classe qu'extends Activity et elle est déclaré dans le manifest, ce serait réalisable que quand on créer une classe : new -> class -> superclass : android.app.Activity il devrait l'ajouter dans le manifest.

Et tu confonds fichier de layout en XML et Activity :

Code:

---

sauf erreur chaque .xml de activity doit être référencé dans le manifest.

---

Il ni a aucune référence à des fichiers xml dans le manifest.
Enfin si les ressources : android:resource="@xml... @string etc...

Mais les activity c'est le nom d'une classe.

je reviens ici car je donne l'une des réponses à ma question.


je suis en train d'apprendre (je suis un tutoriel) et j'ai donc eu la réponse à ma question "pourquoi ne pas déclarer chaque vue-activity dans le manifest"
ou plutôt pourquoi eclipse ne le fait pas systématiquement.


réponse simple :
je suis en train d'apprendre à faire des listview personnalisées et une liste personnalisée est faîte à partir un layout xml de format Activity et donc ce dernier n'a pas besoin d'être déclaré car ce n'est pas une vue active en soit (à ce niveau de mon tutoriel en tout cas...).

Citation:

---

Envoyé par Michael REMY

... est faîte à partir un layout xml de format Activity

---

Je ne comprends pas le sens de la phrase....
Il n'y aucun rapport entre layout xml et Activity (mis à part le fait qu'une activity a une vue de base généralement générée à partir d'une ressource layout).

Citation:

---

et donc ce dernier n'a pas besoin d'être déclaré car ce n'est pas une vue active en soit (à ce niveau de mon tutoriel en tout cas...).

---

Ce dernier quoi ? fichier XML ? mais il est déclaré ! comme ressource de layout...

"Une Activité" regroupe l'instance d'une classe (qui hérite de Activity directement ou non), quelques filtres et attributs applicatif...
Sa déclaration/définition se fait *uniquement* dans le manifest, à aucun moment une "Activité" n'est définie par le code java...
Par contre, le code java définit le support "code" à l'activité par le biais d'une classe qui doit hériter de Activity.

je vais parler globalement en faisant abstraction du language android:

ma question était : pourquoi n'étons pas obliger de déclarer un nom d'écran dans le fichier manifest et surtout pourquoi eclipse ne nous avertis pas de cette erreur. Je considère un écran comme le trio .java, .xml et la déclaration dans le manifest.

Or , apprenant le concept de Listitem personnalisé (concept identique au ItemRenderer de Flex), je viens de comprendre qu'on peut créer un fichier resource layout toto.xml et aussi un fichier toto.java (soit 2 des 3 briques d'une activity) et qu'on a pas besoin d'aller le mettre la 3ème brique dans le Manifest car le toto.layout et le toto.java serviront à l'Adapter (le rendered de flex..).

En gros, on ne met dans le manifest que les Activity qui seront des écrans intégrals.

Je dis "intégral", car j'ai compris que le contenu du adapter (construisant la liste personnalisée) est ensemble de "mini-activity " (...extends ListActivity ...etc).

à mon avis, ya que les "Flxeeur" qui vont me comprendre... je ne sais pas comment l'expliquer sans faire analogie à Flex.

Citation:

---

Envoyé par Michael REMY

ma question était : pourquoi n'étons pas obliger de déclarer un nom d'écran dans le fichier manifest et surtout pourquoi eclipse ne nous avertis pas de cette erreur. Je considère un écran comme le trio .java, .xml et la déclaration dans le manifest.

---

Ok... donc pour toi Activity = Ecran... si tu veux... mais bon, ici tout le monde parle d'activity ;)

Citation:

---

En gros, on ne met dans le manifest que les Activity qui seront des écrans intégrals.

---

Exactement, on ne met que les choses visibles depuis le système, en général d'ailleurs, démarrées par un Intent.

Citation:

---

Or , apprenant le concept de Listitem personnalisé (concept identique au ItemRenderer de Flex), je viens de comprendre qu'on peut créer un fichier resource layout toto.xml et aussi un fichier toto.java (soit 2 des 3 briques d'une activity) et qu'on a pas besoin d'aller le mettre la 3ème brique dans le Manifest car le toto.layout et le toto.java serviront à l'Adapter (le rendered de flex..).
Je dis "intégral", car j'ai compris que le contenu du adapter (construisant la liste personnalisée) est ensemble de "mini-activity " (...extends ListActivity ...etc).

---

Ah ben non.... ListActivity n'est un 'helper' qui s'occupe de gérer une ListView de manière globale à l'activité... De ce fait, il ne sert pas d'adapter... (d'ailleurs il faut surcharger cette classe justement pour fournir l'adapter). L'adapter c'est l'interface entre des données, et la représentation de ces données. Utilisée par ListView (ou tout autre AdapterView).
Le fichier layout associé pourrait très bien être utilisé totalement indépendamment...

Il faut vraiment comprendre que tout est orthogonal:
* Les ressources d'un coté, dont un type (layout) permet de construire une arborescence de "views" quasi-automatiquement (on peut d'ailleure directement dans le XML inclure un autre layout sans passer par du code).
* Le code java, dont une classe (Activity) permet l’interfaçage entre les "écrans" créés par le système et son propre code.
* Le manifest qui permet à dire au système: Si tu recois tel ou tel intent, tu crée cette activité qui utilise cette classe là...

Je vais prendre un exemple....
J'ai une application qui en mode layout affiche à gauche une liste, a droite le détail de ce qui est selectionné, et en mode portrait fait un effet de sliding au moment de la selection pour afficher ce détail...
Comme j'ai plusieurs activité qui partagent ce fonctionnement, j'ai créé une ListDetailsActivity qui gère tous les cas, avec 3 layout de base: landscape, portrait_list, portrait_details....
Apres, j'ai 8 activitées (déclarées dans le manifest) qui utilisent une classe dérivée de celle-ci...
Au bout du compte:
* 12 layouts (un layout de list-item, 3 layouts d'activité, 8 layouts de details)
* 6 classes qui héritent d'Activity (le ListDetailsActivity + 5... en effet 3 activités ne sont différenciées que par l'intent qui les lance)
* 8 activity dans le manifest.