Xamarin Forms MessagingCenter

0
9

Kilka tygodni temu pisałem o Messengerze w MVVM Light i jego wykorzystaniu do komunikacji pomiędzy obiektami, przy czym w przypadku np. WPF wykorzystujemy go przede wszystkim do przesyłania danych pomiędzy viewmodelami.

Wzorzec mediator, którego implementacją jest wyżej wspomniany mechanizm bardzo pomaga w zachowaniu Single Responsibility Principle, jakkolwiek interpretowalibyśmy tę zasadę. W przypadku MVVM, viewmodele nie mają potrzeby wiedzieć o sobie tak na prawdę niczego.

Po ostatnich doświadczeniach i przemyśleniach dochodzę do wniosku, że kwestie związane z przełączaniem formy czy strony po akcji wciśnięcia przycisku czy podobnej należało by z premedytacją wstawiać w code behind. Jest to przecież część kodu, dla której nie będziemy raczej pisać testów jednostkowych a więc separacja tej części kodu od samego UI nie ma specjalnie sensu a produkuje mnóstwo nadmiarowego kodu lub zmusza do wymyślania skomplikowanych hacków. W ViewModelu powinna być logika związana z obsługą modelu, odseparowana tam tak, aby można ją było dobrze przetestować.

Przez ostatnie dni bawię się Xamarinem na potrzeby mojej aplikacji mobilnej dla robota. I muszę przyznać, że jest to naprawdę fajna zabawa. Pomimo tego, że pewne rzeczy są nadal jeszcze dla mnie trochę dziwne i trzeba trochę walczyć ze specyfiką narzędzi (np. Xaml Previewer For Xamarin Forms zachowuje się momentami niewco dziwnie). Świetnie, że nareszcie zdecydowano się na rozwiązanie znane np. z Basic For Android, czyli podgląd na żywo na urządzeniu. Na razie Xamarin Live Player jest w wersji preview i nie testowałem go jeszcze, ale zamierzam to wkrótce zrobić i oczywiście tutaj opisać.

Wróćmy jednak do tematu postu. Okazuje się, że Xamarin FORMS oferuje nam funkcjonalność niemalże identyczną jak Messenger z MVVMLight. Tutaj nazywa się to MessagingCenter, ale niewątpliwie jest to funkcjonująca na identycznej zasadzie implementacja wzorca mediator.

Podobnie jak w przypadku Messengera w MVVM Light mamy tutaj dwie części kontraktu dla danej wiadomości:

Subscribe – wywoływane najczęściej w konstruktorze klasy, które pozwala na nasłuchiwanie wiadomości o danej sygnaturze i podjęcie odpowiedniej akcji w momencie jej otrzymania. Oczywiście wiadomość danego rodzaju może mieć więcej niż jednego subksrybenta.

Send – czyli publikowanie wiadomości, którą mają odebrać dani subskrybenci. Jeżeli w danej chwili nie ma subskrybenta oczekującego na wiadomość danego typu to jest ona ignorowana.

Szczegółową specyfikację można oczywiście znaleźć w dokumentacji Xamarin Forms, ja natomiast przedstawię najprostszy przykład.

W mojej aplikacji dla robota zaimplementowałem stronę modalną, która służy do ustawienia parametrów połączenia sieciowego robota. Pozwala na podłączenie robota do jednej z dostępnych dla niego sieci WiFi, lub na wyczyszczenie ustawień zapisanych w EEPROM, a co za tym idzie przełączenie robota w tryb Access Point.

Ponieważ po wykonaniu takiej operacji konieczne jest zresetowanie układu ESP8266, trzeba fizycznie wyłączyć a następnie ponownie włączyć robota. Przełączenie sieci wiąże się też zwykle z zalogowaniem urządzenia z aplikacją do innej sieci WiFi. Wskazane jest więc, aby po zmianie parametrów główny ViewModel wiedział, że należy rozłączyć połączenie.

Zrobiłem to w prosty sposób. W konstruktorze głównego modelu nasłuchuję wiadomości z sygnaturą disconnect i wykonuję operacje rozłączające połączenie:

Natomiast w viewmodelu strony konfiguracyjnej wysyłam odpowiednią wiadomość w reakcji na zdarzenie zmiany parametrów:

Istnieje oczywiście możliwość przesłania w samej wiadomości dowolnej liczby parametrów wybranego typu.
Proste ? Bardzo proste 🙂

 

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here