Discussion :

[poussinphp]

Bonjour,

Je cherche à remplir une gridview groupé lors du chargement de la page.

Dans le constructeur de mon viewmodel, je lance une méthode d'initialisation qui appel chaque méthode pour remplir catégorie par catégorie.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
        public async void Init()
        {
            HomeCategory cat = new HomeCategory("Mes Fichiers", new List<HomeItemModel>());
            GroupedItems.Add(cat);
            await FillFileData(cat);
        }
 
        private async Task FillFileData(HomeCategory cat)
        {
            //await Task.Delay(200);
            List<ItemInfo> sqlItems = await SqlManager.Instance.GetFilesAsync();
            foreach (Item item in sqlItems)
            {
                cat.Items.Add(new HomeItemModel(item));
              //  await Task.Delay(200);
            }
       }

Vous constaterez que j'ai mis des Delas commentés. J ne comprend pas pourquoi mais si je les met, la page s'affiche, je peux scroller tranquillement et ça remplit 1 à 1 les éléments. Si je ne les mets pas, je constate que l'UI fige, pourtant, c'est une méthode asynchrone.

Je comprend pas ce qu'il se passe et je suis bloqué dessus, auriez-vous une idée d’où peux bien provenir le problème?

[GuruuMeditation]

HomeCategory c'est quoi? Un contrôle ? Il y a combien d'éléments dans sqlItems ?

Même si la méthode est asynchrone, elle ne sera asynchrone que pour les méthodes qui sont awaitable, c'est à dire le GetFileAsync. Le reste tourne en synchrone.

A mon avis ce qui se passe c'est qu'il y a un traitement qui se fait quelque part dans le Items.Add dans la boucle (Probablement un datatemplate XAML qui doit être crée). Quand tu mets le Delay, vu que c'est asynchrone, le thread UI a bien le temps de faire ce traitement. Quand le Delay n'est pas là, la boucle tourne très vite et le thread UI passe tout son à ajouter les éléments et donc n'a plus le temps de rafraîchir l'écran.

[john-thiriet]

Je confirme la réponse ci-dessus.

En fonction du nombre d'objets à ajouter dans la liste tu auras plusieurs solutions :
- Tu peux faire un AddRange de tout tes objets si tu n'en a pas trop
- Tu peux les ajouter 20 par 20 et mettre à Delay après sinon si tu en a beaucoup

D'autres variantes sont possibles comme le fait de ne requêter que ce que tu as besoins et de l'ajouter à la liste.

[Invité]

Bonjour,

En effet, Olivier a totalement raison.

Et puis il faudrait que l'on sache : que sont les objets "HomeCategory", "HomeItemModel" et "GroupedItems"? Sont-ils liés à des éléments d'IHM? Cela est important pour savoir comment faire cette optimisation...

[I_Pnose]

HomeCategory est très certainement un control utilisateur, le fait de remplir sa propriété Items (qui doit certainement être bindée quelque part) dans une méthode asynchrone va faire appel au Dispatcher (qui est en charge de la gestion des évènements de mise à jour de l’UI). Faire appel à ce Dispatcher de manière "bourrin" (à de nombreuses reprises dans un très court laps de temps) va le noyer littéralement ; va en résulter un blocage de l’UI le temps qu’il dépile tous les évènements de mise à jour qu’il a reçus. C’est d’ailleurs la raison pour laquelle le Task.Sleep() dans ta boucle fluidifie l’affichage ; Le Dispatcher profite de ce laps de temps pour dépiler les notifications en attente, et évite ainsi la saturation, et donc le blocage de l’UI.

Noyer le Dispatcher, dans le meilleurs des cas ça fait ramer l’UI (tu en fais les frais), dans le pire des cas, tu obtiens une surconsommation de mémoire qui fait tout planter.

Idéalement il faut limiter le plus possible les appels au Dispatcher (pagination, temporisation, etc...).