Discussion :

[greedo01]

Bonjour à tous,

Je suis donc un débutant niveau 2, c'est à dire que j'arrive à faire un certains nombres de choses relativement basique mais dès ma première application je me retrouve confronté à la possibilité de faire cette application de différente manière mais pour ne pas prendre de mauvaises habitudes, je me tourne vers vous les expérimentés pour savoir quelle est la meilleure architecture selon vous.

Pour illustrer mon propos, voici ce que fait mon application (dans les grandes lignes) :
- Je me connecte à un serveur distant pour récupérer un flux d'information
- Je traite le flux de différents types
- J'affiche dans un gridview le résultat (titre, image)
- Je permet d'avoir le détail (présentation détaillé différente en fonction du type d'info)

J'ai donc trouvé 3 façons de faire ça :
1 - La manière linéaire : mais pour cela il faut désactiver l'accès réseau en tache d'arrière plan.
2 - La manière synchrone : en utilisant un thread (run , start, join) mais le temps d'aller chercher les éléments, l'application se lance avec l'écran "moche" pré paramétrer (puisque le oncreate se finit une fois les données traitées)
3 - La manière asynchrone : AsyncTask (pour simplifier) mais cela implique cette fois de gérer des rafraichissements des écrans puisque les données arrivent après le premier affichage de l'écran

Voilà ce qui m'intéresserait et probablement tous les débutants aussi c'est de savoir comment vous feriez vous par exemple sur ce type d'application.

En espérant avoir été clair, je vous remercie par avance.

[Hizin]

La 3ème méthode est la seule valable.

La 1ère et la 2ème ont le même problème : elles gèlent l'interface, ce qui est à proscrire le plus possible.
De plus, sur Android, elles déclencheront une exception : NetworkOnMainThreadException, qui porte bien son nom.

Dans un premier temps, afficher des placeholder, ou une vue complète d'attente (éviter la popup "chargement" si possible), et afficher les données au fur et à mesure qu'elles arrivent, ou tout en un coup, dépendant de ce qui est le plus joli.

[greedo01]

@Hizin : pourrais tu être un peu plus précis dans ton architecture (c'est justement là où j'ai un peu de mal avec la compronête).
Je veux dire, le choix serait donc d'utiliser AsyncTask :
Tu récupères donc les données dans l'AsyncTask.
Tu met le Gridview où ? (dans le mainactivity quand même ? si oui comment gères tu le rafraîchissement ?)
Gères tu de manière particulière la navigation (retour à l'écran précédent par exemple) => fais tu appel à des services systématiquement si oui y a t il une façon de faire particulière ?

[Hizin]

Ca va dépendre justement de tes vues.

De ce que je comprends : tu as une gridview composée de multiples éléments complexes. Chaque éléments complexes est un agrégat d'un texte et d'une image.
Pour se faire, je passerai plutôt par une ListView, car ça y ressemble beaucoup (verticale ou horizontale).

Je n'ai pas de "MainActivity". J'évite le plus possible les noms trop générique ou trop couplant. Chaque activité peut être lancée de n'importe où, il n'y en a donc pas une de "principale", elles le sont toutes.

La vue sera gérée par une Activity, celle-ci se chargeant ensuite de lancer les AsyncTask.

Dépendant de ce que tu désirs : soit une AsyncTask par élément complexe en notifiant la vue dans le onPostExecute retournant un POJO String/URL (ou String/Bitmap), la vue se débrouillant ensuite pour mettre ça où il faut (un pattern observer en somme, l'utilisation prévue pour une AsyncTask).
Soit une AsyncTask générale, téléchargeant toutes les données puis notifiant la vue de se mettre à jour en créant les widgets qui vont bien et les mettant où il faut.

Pour le "retour", je ne peux pas vraiment te répondre. Tu n'as présenté que le cas d'une vue statique sans interaction comportant textes et images.

J'imagine qu'un toucher ouvre une autre activité, c'est bien ça ?
Dans ce cas, il faut faire attention aux erreurs OutOfMemory à cause des images. Les données doivent être stockées pour ne pas avoir à refaire les requêtes (il faut penser au forfait data des utilisateurs), mais plus dans un système de cache locale que gardées en mémoire vive si elles sont "volumineuses".

[hotcryx]

La 3ème méthode est la seule valable.

La 1ère et la 2ème ont le même problème : elles gèlent l'interface, ce qui est à proscrire le plus possible.
De plus, sur Android, elles déclencheront une exception : NetworkOnMainThreadException, qui porte bien son nom.

Dans un premier temps, afficher des placeholder, ou une vue complète d'attente (éviter la popup "chargement" si possible), et afficher les données au fur et à mesure qu'elles arrivent, ou tout en un coup, dépendant de ce qui est le plus joli.

Concernant la méthode 2 (Thread):
Si tu lances ton thread dans un Service ça ne gèle pas l'interface
Ce qui veut dire que tu as une 4eme option (les services).

[greedo01]

C'est exactement ça merci. Disons qu'en l'état de mes connaissances, ce qui me bloque ("bloquait ?"), c'est la notion de "widget qui va bien" que je ne dois pas maitriser comme il faut car je me retrouve toujours dans le cas où j'affiche d'abord la view puis j'obtiens les données (normal je suis en asynchrone) et puis après ... je met à jour et donc pendant ce laps de temps, j'ai une vue à gérer.

J'ai remarqué que sur des applis type sport24, ils avaient choisi d'afficher pendant ce laps de temps les données anciennement conservées (ce que je peux faire puisque que je les sauvegarde en local). Est ce un choix qui te semble valable ?

Sinon, oui je passe d'une activity (dites main parce que c'est la première) qui gère mon gridview (donc toi tu me conseilles de sortir le gridview et le mettre dans une autre activity) puis j'appelle une autre view (detail) dans une autre activity qui est appelé sur le fait de toucher l'image. Maintenant, je ne sais pas encore retourner sur le gridview quand l'utilisateur touche au retour de son smartphone (c'est pour ça que je parlais de navigatoin).

Merci j'y vois plus clair.

@hotcryx : dans ce cas quelle est la différence entre lancer un async et un thread lancé dans un service ? (je sais je suis un peu boulet) ça évite de lancer une autre activity ?

[Hizin]

J'ai remarqué que sur des applis type sport24, ils avaient choisi d'afficher pendant ce laps de temps les données anciennement conservées (ce que je peux faire puisque que je les sauvegarde en local). Est ce un choix qui te semble valable ?

Oui, avec un retour utilisateur indiquant que les données sont en train de se rafraîchir.

(donc toi tu me conseilles de sortir le gridview et le mettre dans une autre activity)

Non, absolument pas. Ton Activity gère la gridview... mais la laisse vide tant qu'elle n'a aucune données à afficher. Ensuite, quand tu reçois un jeu texte+image, tu l'affiches, selon le design pattern observer ( https://en.wikipedia.org/wiki/Observer_pattern ).

Pour le retour : Android le gère nativement.

[hotcryx]

Greedo1 => si la tâche est uniquement du background (pas d'interaction avec l'UI thread), je crois que je ne prends pas trop de risque en disant haut et fort que l'utilisation d'un Thread est le plus adapté

Et pourquoi les encapsuler dans un service?
l'un des avantage du service est qu'il démarre/stoppe tout seul et que c'est effectivement une tâche pouvant être utilisée de multiples fois et en même temps.

On peut également partager le service avec d'autres applications
(pas encore testé)