Activity et IHM

[Clorish]

Bonjour,

J'ai pour habitude de developper des application sur PC a base de "Form" ou "Frame" selon les langages.

Sous android j'ai encore un peu de mal a me familiariser avec le systeme d'activity et layout.

Pour faire simple, j'ai une application avec un ecran de connection et plusieurs ecran de gestions, selon l'action désiré.

J'ai opté pour une activity, avec un layout principal de type RelativeLayout composé de plusieurs layout en mode fill_parent superposé.

Je joue ensuite sur les parametres visibility pour affichier/masquer mes layouts (ie ecran).

Par souci de clarté, j'ai utilise un fichier XML par layout secondaite (pages) que j'ai intégré a mon layout principal a l'aide de la balise "include".

Est correcte comme vision des choses ? ou bien est ce un peu tordu ?

Quel est la philosophie de codage d'une IHM multi ecran Android ?

Merci.

[neoakira]

iop,

la philosophie de codage d'une IHM multi écran Android est une activity par écran :)

et maintenant Google conseille de faire un dashboard (cf l'application twitter) pour accéder aux diffèrent écrans...

[Clorish]

iop,

la philosophie de codage d'une IHM multi écran Android est une activity par écran :)

et maintenant Google conseille de faire un dashboard (cf l'application twitter) pour accéder aux diffèrent écrans...

Ok merci. Je vais regarder du coté des dashboard. Si cela correspond a ce que je pense c'est en effet ce que je cherche.

Coté Activity, ce qui me freine c'est la gestion du "OnCreate".

comment detecter si l'application est lancé pour la premiere fois ou "restaurée". J'ai remarqué qu'apres une mise en veille, l'application est figée, et le on create se redeclanche, tout comme lorsque l'on change d'orientation du telephone.

Cela me fait planter certains traitements ....

Sinon quel logique appliquer pour masquer/afficher une activity ? Peut etre n'est ce pas la bonne methode, mais j'ai une classe metier qui est mon moteur applicatif et je me sert des activyty comme interface d'affichage, saise. Du coup, le code associé aux activité n'est pas independant ....

Je vois mes ecrant plutot comme des onglet d'une fenêtre a la différence que ce n'est pas gérable par onglet justement (trop nombreux)

[neoakira]

aurais tu sauté la case d.android.com par hasard et surtout http://d.android.com/guide/topics/fundamentals.html ?

sur ce site il y a tout ce qu'il te faut pour le dev android,

après pour une aide plus poussée, moi je te conseil de venir faire tour sur l'irc #android-fr sur freenode

[Clorish]

Oui j'ai en effet un peu zappé cette etape :)

Je suis deja passé par ce site mais par un lien google sur des cas precis.

Je vais voir ca et je reviens vers vous si j'ai encore des questions ;)

[Pierre87]

une application Android est très différente d'une application "desktop"

on ne peut pas savoir si elle "tourne", puisque ça n'a pas de sens :P

masquer des layouts n'est pas vraiment recommandé, si tu veux changer d'écran -> nouvelle Activity (comme neoakira)

[Clorish]

Bonsoir !

Me revoici apres avoir parcourus le site présenté plus haut.

Il est en effet tres interessant et instructif quand a la "logique" des applications Android.

Cependant j'ai une question qui reste en suspends ...

J'ai bien compris le role et le cycle de vie des activity mais j'ai encore un peu de mal a voir comment ils s'integrent dans une application.

Exemple :

Sur PC, j'ai pour habitude de creer plusieurs fenetre pour gerer l'interaction avec l'utilisateur.

La partie "Metier" de mon application (ie les traitements, calculs, telechargements, ...) sont supportés par un ensemble de classe, dont la classe principale representant mon application est un singleton. les Fentetre me servent donc a afficher et saisir les informations de ma classe metier.

Dans le cadre d'un developpement Android, je concoit qu'il faille creer autant d'activity que "fenetre" dont le role est d'interagir avec l'utilisateur. A ce nivreau cela ne change pas vraiement d'une application standard. Par contre comment peuvent elles partager les données, les traitements, etc .... Ma couche metier peut elle persister comme dans une application standard ? ou bien doit elle faire l'objet d'un "service"

J'ai comme l'impression que Android fonctionne un peu coté logique comme bon nombre d'applications Linux : Un appli console (ie les services) et une application graphique (ie activities) qui se contente d'offrir une interface ergonomique de saisie des informations avant d'executer l'application en ligne de commande en jouant sur les arguments ....

[Edit] Petite precision :

Sans que mon application soit un "service" au sens "application de surveillance" qui doit etre executé en permanance, certains traitement sont assez longs et j'aimerais qu'ils persistent apres la mise en veille du telephone. actuelement je suis contraint de surveiller l'ecran et effectuer des actions regulieres pour eviter qu'il se mette en veille et bloque mon traitement.

[Pierre87]

Pour faire simple, je te conseille de tester plus d'applications Android.

Chaque fois que tu vois un changement d'écran, il s'agit d'un changement d'Activity.

Pour partager des données, c'est très simple :)

Si tu veux passer des données "simple", je te conseille de regarder la classe Intent.

C'est un peu la classe à tout faire dans Android :P

Elle permet de déclarer une "intention" de :

- ouvrir une Activity

- faire un broadcast

- démarrer un service

Elle dispose de ce que l'on appelle les "extras", qui sont des paramètres à transmettre.

Ils peuvent être de plusieurs types :

- simple java : bool, int, float, String (oui, String c'est particulier)

- Parcelable

Parcelable est un peu l'équivalent de Serializable, sauf que l'encodage et le décodage est à ta charge.

Tu peux donc maintenant très simplement passer des informations d'un écran à un autre.

Si tu as besoin de garder des infos pendant la durée d'exécution de ton application, tu peux utiliser des variables static.

Mais attention, il ne faut surtout pas que celles ci soient liées à un Context.

Donc ne "sauve" pas des objets de classes telle que : Context, Activity, View, Intent, etc...

Sauf si le Context lié est ton objet Application (dont je vais te parler)

Quand une application Android est exécutée, un objet de la classe Application est instancié, et récupérable grâce à getApplication() dans tes Activity.

Tu as la possibilité de définir ta propre classe héritant de Application.

Il faut pour cela la déclarer dans ton fichier AndroidManifest.xml, dans l'objet <Application>, c'est le champ "android:name".

Ce que je fais (mais qui n'est pas forcément "bien") est d'utiliser un pattern "singleton" avec cet objet.

Ainsi, je peux très facilement le récupérer grâce à une méthode static.

Pour ce qui est des classes métier, tout dépend de si ton code est réutilisé :P

Si tu as des traitements identiques d'une Activity à une autre, je te conseille d'en utiliser.

Toutefois, comme tu as pu le voir avec les Intent, tu ne vas pas pouvoir passer directement des références d'une Activity à une autre...

Tu peux par exemple essayer de les garder dans ta classe Application :P

Mais comme je ne connais pas ton application... je ne peux pas plus te conseiller :(

Pour les traitements, tout dépend de leurs types...

Si c'est une action qui bloque l'utilisateur (chargement d'une info, avant de l'afficher), je te conseille d'utiliser la classe ProgressDialog.

Toutefois, il s'agit juste de l'affichage.

Si tu veux faire une action en tâche de fond, tu est "obligé" d'utiliser la classe AsyncTask dans ce cas.

Si il s'agit d'une action à exécuter en tâche de fond, mais que l'utilisateur a la possibilité de "laisser/quitter" ton application, il faut utiliser un Service.

En gros, ça permet d'obliger le système à ne pas tuer ton application, pour laisser une tâche de fond s'exécuter.

Il me semble qu'il ne faut pas exécuter le traitement directement dans la classe Service, mais le déléguer à une AsyncTask.

Je te conseille aussi d'afficher qu'il y a un traitement en cours à l'aide d'une Notification persistante.

Le principe d'AsyncTask est assez particulier, mais une connaissance m'a dit qu'on retrouve quasiment la même classe dans Swing.

Dans Android, il y a 2 choses FORMELLEMENT INTERDITES au niveau de l'utilisation de thread main/UI/graphique :

- on ne doit pas "bloquer" ce thread, sinon ton application "freeze", puis plante

- on ne doit pas toucher à l'interface graphique en dehors de ce thread, sinon ton application plante

C'est là qu'intervient la classe AsyncTask.

Elle permet d'effectuer un traitement dans un thread distinct (qui sera recyclé), et d'effectuer des action avant et après ton traitement avec le thread main/UI

C'est très pratique pour afficher/masquer un ProgressDialog avant/après une tâche.

[Clorish]

Je te remercie énormément pour cet exposé très détaillé. C'est tout a fait ce que je recherche.

Pour information, je suis développeur de métier depuis plus de 10 ans et amateur depuis environ 20 ans :D

Cependant, la "logique" Android est un peu particuliere il et faut que je fasse le lien avec la programation dite "classique".

Pour ce qui concerne la classe "Application", je connait bien ce type d'objet. Il existe dans de nombreux langages et je l'utilise souvent.

Quand je parle de "classe metier" c'est un peu a ca dont je parle : Un objet "Application", racine de mes traitement.

Dans le PAttern MVC, je lui attribue le role de controleur principal de l'application. Il est responsable de l'initialisation de l'IHM et des fonctionalités principales (Demarrer, initialiser, fermer des taches applicatiques). C'est un peu le Noyeau de mon application.

Comme toi cette classe implemente généralement le pattern Singleton. Ainsi chacun de mes objets (metier ou IHM) peuvent y acceder simplement.

En ce qui concerne les Activity, je ne suis pas pour placer le code metier dedans. Pour moi leur role est de gerer l'interactivité. Donc le but est par exemple de proposer des boutons ayant pour action de lancer une methode de mon objet "Application". Le resultat du traitement sera donc fourni via un "Modele" et affiché dans l'activity.

Pour en revenir au type d'application, j'ai dont une classe principale qui gere la partie metier.

Pour faire le parallele avec une application existante, prenons Facebook : L'applciation gere un "compte utilisateur" auquel il faut se connecter et qui possede plusieurs ecrans d'informations.

Au chargement de l'application, l'utilisateur s'identifie, puis accede a un ecran d'acceuil qui lui donne le choix entre plusieurs "Pages".

Pour moi, j'ai donc une activity pour la connection, une pour l'acceuil, et une par page. Mais derriere, j'ai un objet "Application" qui implemente des methodes du genre : Connect, Disconnect, LoadAccount, LoadMessages, FindUser, .... (je reprends des exemples type "Facebook")

Chacune de ces methodes peuvent etre assez longues a traiter selon la volumetrie des données et la qualité de la connection.

Donc pour en revenir a la structure de l'application, je definie mon activity d'acceuil comme "principale" et lorsqu'elle est chargée (on create, on resume ...) un test sur le statu de la connection est effectué et selon le resultat affiche l'ecran de connection.

Une fois sur la page d'acceuil, la selection d'une "page" lance l'activity qui s'occupe de charger les données dans la classe application puis de les afficher.

Ces données peuvent ainsi etre affichée ou utilisé dans des traitements associés a d'autres activity.

Apres mon souci principal c'est le statut meme d'une "tache" Android. Elle est mise en pause losque l'ecran passe en veille.

Donc si mon traitement n'est pas terminé (par exemple un chargement de donnée prenant 1 minute), le traitement est mis en pause, meme si ce dernier s'execute dans un thread secondaire (a confirmer).

Mon but serait donc que l'utilisateur lance un traitement, un ecrant type "prorgressDialog" lui indique le statut de chargement, puis il laisse son mobile sur le coté et reviens un moment apres pour consulter les donées chargées. Entre temps, le mobile est passé en mode "Veille" mais le traitement s'est poursuivi.

Je pensait donc passer par un service qui implemente donc ma partie metier avec des activity qui se connectent a se service pour lancer les traitement est afficher les resultats.

Cependant cela me fait plutot penser a une application type "Client/Server" avec 2 processus dont il faut gerer les communications. J'aurait aimer que cela s'execute au sein du meme processus avec bien sur des thread secondaires pour effectuer les traitements longs.

Voila un peu plus de details concernant mes objectifs, bien que ce que je recherceh avant tout est plus de comprendre la logique Android et dans quel cas utiliser plutot un service, plutot une activity, etc ....

En tout cas, merci pour toutes ces infos, et celles a venir :)

[Pierre87]

Dans Android, la classe application ne s'occupe pas d'initialiser l'IHM.

On utilise plutôt les fichiers xml qui servent à définir l'organisation des vues.

Ensuite, l'Activity défini à son initialisation la vue qu'elle veut utiliser.

Attention à l'objet application : il n'est pas détruit lorsque l'application est "quittée" (mise en arrière plan), car justement, l'application n'est jamais réellement quittée :P (sauf si le processus est tué).

Je suis d'accord sur le fait que "trop de métier" dans une Activity est nuisible.

Mais si le code n'est réutilisé nul part, je ne m'en prive pas (sans en abuser).

Les AsyncTask ne sont pas mises en pause lorsque l'application n'est plus visible à l'écran.

Une application peut tout à fait continuer de faire tourner des threads en arrière plan.

Mais si elle n'a pas déclaré de Service actif, il y a un risque que l'application soit tuée à n'importe quel moment par le système.

Si une application continue de faire tourner des threads alors qu'elle est en arrière plan et qu'elle n'a pas déclaré de Service actif, c'est une "mauvaise" appli :P

Si j'ai bien compris ce que tu veux faire, voilà ce que je te conseille:

- Un service que tu lances lorsque tu veux effectuer ta tâche

- Une Notification persistante (dans la barre en haut) qui informe l'utilisateur qu'il y a une tâche en cours

- Une AsyncTask qui est lancée au moment où le Service démarre, et qui reporte à la Notification son avancement

- Une Activity qui renseigne sur l'état d'avancement de ta tâche (mais tu peux tout à fait quitter/fermer cette Activity sans affecter le Service)

Il n'est pas utile ici de faire 2 processus (je pense...).

Pas de ProgressDialog, car ça "bloque" l'interface

Je te conseille vivement de lire la doc Android :P

[Clorish]

Oui j'ai bien compris que l'objet Application n'a pas pour but d'initialiser l'IHM, mais bien le role des layout XML.

Je parlais des variable applications d'autres languages, plutot dans le sens "Controleur". Car contrairement a Android, dans la programation PC, l'IHM est lancée par le point d'entree unique de l'application : "Main".

Le fait que la variable application periste tout au long du cycle de vie de l'application est ideal. Ca en fait l'objet parfait pour contenir les references à mes controlleurs metiers.

Si en plus elle est accessible de partout a l'aide de "GetApplication" c'est parfait.

Je vais me renseigner un peu plus sur les AsyncTask car ca corresponds plus a mes besoins que la classe Thread, qui me demande de developper une sorte de classe generique de traitements assynchrone ..... ;)

Le fait que les AsyncTask ne persistent pas, cela m'importe peu. Le but n'est pas de lancer un taitement recurent et permanant, ou de tres longue durée .... d'ou ma reticence a utiliser un Service. dans la plupart des cas c'est rapide, mais parfois, juste assez long pour depasser le temps de mise en veille ....

Le tout est que le traitement soit arreté proprement quand Android libere la memoire en tuant le processus.

Juste une derniere petite question : Supposons que mon application possede une classe singleton d'acces aux données. Les activity recuperent ce singleton et manipulent les données.

Le service peux il acceder au meme singleton et renseigner des données qui seront affiché dans les activity ou bien cela s'execute t il dans 2 process totalement differents comme c'est le cas sur PC ?

Sinon j'ai passé pas mal de temps a lire la doc mais j'avais besoin de quelques eclaircissements ;)

Avec ces infos je vais pouvoir m'y replonger dedans avec une meilleur vision du systeme :)

Merci.

[Pierre87]

Un Service est indispensable du moment que tu essaye de faire tourner une tâche alors que ton application n'est plus visible à l'écran.

Si tu ne le fais pas, ton application peut être détruite par le système alors que ta tâche est en cours!

Ton Application, tes Activities et tes Services partagent la même "jvm", donc les variables static sont partagées.

Il n'y a pas de processus distinct pour un Service.

Il n'a même pas de Thread distinct! (je crois bien).

Les diverses méthodes de Service sont exécutées par le main/ui thread.

C'est pour ça qu'il faut créer une AsyncTask liée à ton Service

[Clorish]

Ok, super .... en fait si je comprends bien, ce n'est pas un "Service" au sens traditionel mais juste un type d'objet possedant un comportement specifique ...

Bon ben je vais me replonger dans la doc avec ces infos :=)

[Pierre87]

Quand je parle de Service, je parle bien sûr de la classe Android :P

Rien à voir avec la notion de "service" dans Windows :/

Tout est dans la doc :D

[Clorish]

Oui ca j'avais bien compris ^^

Mais pour moi la notion de service est autre : Service Windows, WebService, etc .... des application independantes :)

Et le fait que les "Services" Android sont persistant et s'apparentent a un service windows, j'ai effectué un rapprochement peut etre un peu trop direct ^^

Merci encore pour tous ces details :)