In einer MvvmCross-Lösung habe ich eine Singleton-Service-Klasse, die Elemente von einem Webdienst abruft und eine öffentliche ObservableCollection aktualisiert. Dies geschieht alle fünf Sekunden und Elemente können hinzugefügt oder entfernt oder ihre Eigenschaften geändert werden.

Ich habe auch ein ViewModel mit einer öffentlichen Eigenschaft, die auf ObservableCollection des Dienstes festgelegt ist. Die Ansicht ist an die ObservableCollection gebunden, sodass beim Hinzufügen, Entfernen oder Ändern von Elementen die Ansicht aktualisiert wird, um dies anzuzeigen.

Wie erwartet wird jedoch eine Threading-Ausnahme angezeigt, da die ObservableCollection von einem anderen Thread als dem der Haupt- / Benutzeroberfläche aktualisiert wird und die Bindung daher die Benutzeroberfläche nicht aktualisieren kann.

Innerhalb des Dienstes habe ich das nichtInvokeOnMainThread Aufruf sofort verfügbar, sodass es keine offensichtliche plattformübergreifende Möglichkeit gibt, beim Aktualisieren der ObservableCollection wieder zum Haupt-Thread zurückzukehren. Dies scheint auch falsch zu sein - ein Service sollte sich nicht mit UI-Angelegenheiten befassen (wohingegen ein ViewModel dies kann).

Ich bin auch ein bisschen nervös, wenn ich Ereignisse von einem Service enthülle, die dazu führen, dass ViewModels nicht vom Müll gesammelt werden. Ich stelle fest, dass in @ Slodge N + 1-Seriehttp://mvvmcross.wordpress.com/ Vermutlich nutzt er einen Nachrichtendienst, um genau dies zu vermeiden.

Eine mögliche Lösung besteht darin, eine Nachricht mit der neuesten Elementliste zu veröffentlichen und das ViewModel die Nachricht zu abonnieren und seine eigene ObservableCollection im UI-Thread zu aktualisieren, indem der Nachrichteninhalt mit ihr verglichen wird. Aber das scheint ein bisschen klobig.

Für Vorschläge zur bestmöglichen Umsetzung wäre ich dankbar - danke.