Cykl życia aplikacji Android, iOS, Xamarin.Forms

Cykl życia aplikacji. Jedno z podstawowych pytań rekrutacyjnych. Nie zależnie od technologii w której piszemy to jedna z podstawowych rzeczy do zrozumienia.
W świecie aplikacji mobilnych pytanie jest jeszcze bardziej skomplikowane niż zwykle bo mamy co najmniej trzy podejścia, przynajmniej w przypadku który rozważam czyli  Xamarin.Form. Ponieważ aby zrozumieć jak działa Xamarin.Forms i dlaczego potrzebujemy jeszcze wiedzę na temat Androida i iOSa. (dodatkowo na diagramach dodałam również nazwy metod Xamarin.iOS)


Cykl życia aplikacji określa jak aplikacja może się zachowywać i do jakich zasobów ma dostęp. Dla aplikacji mobilnych najważniejszy jest użytkownik, to co użytkownik widzi i z czym może wejść w interakcję. Dlatego też aktywne aplikacje maj priorytet w przydziale zasobów rozdawanych przez system operacyjny. Natomiast aplikacje które działają w tle (nie są widoczne dla użytkownika)  mają ograniczony czas działania i system może zdecydować o zwolnieniu zasobów takiej aplikacji czyli zamknięciu aplikacji. Aplikacja powinna być przygotowana na 'zwolnienie zasobów' zanim system o tym postanowi.

Wszystkie systemy operacyjne działają podobnie:

1. Użytkownik podejmuje akcję aby uruchomić aplikację, system operacyjny wykonuje to życzenie i uruchamia aplikację
   Startowanie aplikacji
2. Aplikacja po serii zdarzeń zostaje uruchomiona i jest gotowa odpowiadać na akcje użytkownika
   Aplikacja aktywna i widoczna
3. W wyniku wykonania akcji przez użytkownika jak na przykład odebranie nadchodzącej rozmowy telefonicznej aplikacja przestaje być aktywna i ląduje w tle
   Aplikacja nieaktywna w tle
4. Jeśli system potrzebuje zasobów może zdecydować o zabiciu aplikacji
   Aplikacja zamknięta

Te cztery elementy będą uwzględnione na moich diagramach.
Diagramy to prawie główna treść tych rozważań, więc proszę o dłuższe zawieszenie oka.

Cykl życia Androidowej aplikacji Google opisało dokładnie tutaj.

W Androidzie aplikacja jest reprezentowana przez Activity. Wszystkie zdarzenia cyklu życia trafiają najpierw do Activity które jest w aplikacji zarazem aplikacją i reprezentacją aktywnego widoku użytkownika.

A teraz spojrzenie na aplikacje iOS.
W ekosystemie Apple jest troszkę inaczej. Zdarzenia cyklu życia aplikacji (opisany tutaj)
są specyficzne dla aplikacji, natomiast kontroler i widok mają swój zestaw metod cyklu życia.

Android i iOS są bardzo podobne. Jedną różnicę podkreśliłam na poniższym diagramie. A różnica jest taka że gdy aplikacja iOS startuje od zera iOS pomija metodę WillEnterForeground.

Tworząc Framework zawsze jest sporo decyzji do podjęcia. Gdy mamy dwa zestawy metod które są podobne ale nie identyczne możemy zrobić podzbiór wybierając tylko wspólne metody lub super zbiór, który nie zawsze ma pełną implementację.
Xamarin.Forms wybiera podzbiór.
Możemy to zobaczyć na GitHubie w implementacji metody OnStateChanged w Androidzie: (github repo)
Oraz w iOS. (github repo).

Czy to dobrze czy źle? Tak po prostu jest. Tak działa Xamarin.Forms.
Na pewno jest to miała strukturyzacja stanu aplikacji.
Ale aplikacja musi być przygotowana na zabicie w chwili przechodzenia w tło ponieważ nie mamy rozróżnienia pomiędzy tymi dwoma zdarzeniami mamy tylko OnStop.

Pamiętajmy że najważniejszy jest użytkownik i jego interakcja z aplikacją oraz systemem operacyjnym i innymi aplikacjami. Dlatego ważny jest nie tylko cykl życia aplikacji ale również samego widoku.
W Androidzie widok reprezentowany jest przez Activity, albo Fragment (po prawej stronie diagramu androidowego). W iOS widok ma swój całkowicie osobny zestaw metod cyklu życia. W obu przypadkach widok dostaje informacje o tym co dzieję się z aplikacją -  czy jest aktywna czy została przełączona i wylądowała w tle. Widok ma bardzo podobny cykl życia do tego aplikacyjnego.

W Xamarin.Form widok reprezentowany jest przez Page. Niestety Page ma tylko dwa zdarzenia PageAppearing oraz PageDisappearing które powiązane są z nawigacją wewnątrz aplikacji a nie cyklem życia aplikacji. Konsekwencją tego jest niewiedza Page o jakichkolwiek interakcjach z systemem - przejście w tło, ponowna aktywacja widoku.

Dlaczego by to miało być problemem? Jeśli użytkownik odbiera tylko przychodzące połączenie telefoniczne to nic się nie stanie jeśli od razu wróci do aplikacji a dane w aplikacji pewnie będą aktualne. Jednak jeśli użytkownik wchodzi na Facebooka może tam trochę spędzić i raczej  dane nie będą już aktualne i warto było by je odświeżyć po powrocie do aplikacji.

Ten problem może być bardzo łatwo rozwiązany przekazaniem zdarzeń cyklu życia aplikacji do Page. Xamarin.Forms posiada wbodowany MessegingCenter który umożliwia komunikację widoków i innych komponentów bez bezpośredniego połączenia tylko na podstawie kontraktu wiadomości i samej wiadomości
Aplikacja może wysłać wiadomość o zdarzeniu cyklu życia a każdy widok które potrzebuje tych informacji może zasubskrybować się do MessagingCenter i obsłużyć wysłaną wiadomość a przy okazji zdarzenie cyklu życia aplikacji.

In App.cs we add MessagingCenter.Send

In BaseContentPage we subscribe and unsubscribe for reqired message type.

Po tej małej zmianie cykl życia Xamarin.Forms zaczyna przypominać ten z Androida i iOSa i jest tak skomplikowany i pełny jak chieliśmy.