Ionic a iOS, czyli aplikacje hybrydowe nie zawsze między-platformowe

Ionic to framework do tworzenia hybrydowych aplikacji mobilnych, wykorzystujący silnik Cordova i oparty na frameworku Angular JS. Tutaj nie będziemy jednak szczegółowo omawiać aspektów związanych z jego wykorzystaniem, a jedynie przedstawię zbiór kilku luźnych obserwacji i problemów, z którymi można się spotkać, tworząc aplikacje z wykorzystaniem Ionic 2 na platformy iOS i Android. Będzie więc o kilku różnicach w działaniu aplikacji Ionic na tych dwóch platformach.

# View lifecycle

To dość ważna sprawa, bo związana z cyklem życia aplikacji. Ionic definiuje kilka stanów w cyklu życia pojedynczego widoku, a właściwie event’ów z nim związanych:

• ionViewCanEnter – wywoływany przed wejściem do widoku (zanim jeszcze to wejście jest możliwe)
• ionViewWillEnter – wywoływany tuż przed wejściem do widoku, na późniejszym etapie, tuż przed tym gdy widok stanie się aktywny
• ionViewDidEnter – po wejściu do widoku
• ionViewDidLoad – po całkowitym załadowaniu widoku (uwaga – nie zostanie wywołany, gdy powtórnie otworzymy zcache’owany widok)
• ionViewCanLeave – wywoływany przed wyjściem z widoku, analogicznie jak CanEnter
• ionViewWillLeave – przed wyjściem z widoku, tuż przed tym gdy widok przestanie być aktywny
• ionViewDidLeave – po wyjściu z widoku, gdy widok już przestał być aktywny
• ionViewWillUnload – tuż przed całkowitym usunięciem widoku

O ile na Androidzie wszystkie event’y cyklu życia są wywoływane tak jakbyśmy się tego spodziewali, o tyle na iOS okazuje się, że nie wszystkie i nie zawsze. W moim przypadku istotny fragment kodu miał być wykonywany w momencie opuszczania widoku. Problemem okazał się fakt, że podczas gdy Android w momencie wyjścia z widoku faktycznie go usuwa, iOS pozostawia go w pamięci, a tym samym eventy:

• ionViewCanLeave
• ionViewWillLeave
• ionViewDidLeave

nigdy nie zostają wywołane. W rzeczywistości jest to nie tyle błąd Ionic’a, co raczej pewne niedopatrzenie koncepcyjne (okazuje się, że dyskusja związana m.in. z tym problemem pojawiła się również na GitHub Ionic). Warto jednak mieć świadomość, że cykl życia aplikacji może być znacząco różny zależnie od platformy i lepiej zawsze upewnić się, że aplikacja zadziała w przewidywalny sposób pod każdym z systemów.

#iFrame a dostęp do hardware’u

Wydawałoby się, że to raczej dość nietypowy problem, jednak w praktyce okazuje się on zaskakująco powszechny. Załóżmy, że z jakiegoś powodu potrzebujemy umieścić jakiś element naszej aplikacji wewnątrz ramki iFrame (to najprostszy sposób, żeby wyświetlić np. zewnętrzny zasób). Tak uruchomiony kod nie będzie miał dostępu do funkcji hardware’owych systemu, np. do żyroskopu (dotyczy to iOS w wersji od 9.2 w górę) i nie ma tu znaczenia czy będzie to zasób zdalny czy lokalny. Przykład z życia wzięty? Wyświetlenie wirtualnego spaceru wewnątrz aplikacji. Taki spacer najczęściej sam w sobie jest osobną, małą aplikacją webową. Włączenie jego kodu bezpośrednio do kodu naszej aplikacji hybrydowej może okazać się kłopotliwe, dlatego często spotykanym rozwiązaniem jest umieszczenie go zdalnie (na serwerze) lub lokalnie (w zasobach aplikacji) i wywołanie niejako niezależnie, właśnie wewnątrz ramki. Jeśli wspomniany spacer posiada funkcje związane z wykorzystaniem żyroskopu (co w tym przypadku jest raczej częste), to niestety te funkcje nie będą działać pod iOS (pod Androidem nie ma tego problemu). Rozwiązanie? In App Browser, ale to już raczej temat na osobny wpis.

#Urządzenie a emulator

Chociaż emulatory iOS na macOS to jedne z lepszych emulatorów z jakimi możemy się spotkać, to jednak wciąż są tylko emulatorami i ich działanie nie zawsze w pełni pokrywa się z działaniem aplikacji na fizycznym urządzeniu. Przykładem może być polityka bezpieczeństwa, a konkretnie zezwolenie aplikacji na dostęp do określonych adresów URL. Okazuje się, że w niektórych przypadkach emulator jest bardziej restrykcyjny niż fizyczny iPhone i w przypadku dostępu do zewnętrznych adresów wymaga dodatkowych definicji w konfiguracji. Jeśli więc na emulatorze lub urządzeniu nie możemy uzyskać dostępu do zewnętrznych adresów URL, sprawdźmy czy w pliku konfiguracyjnym mamy zdefiniowane:

<access origin="*"/>
<allow-intent href="*"/>
<allow-navigation href="*"/>

Przy czym wildcard *  są dobre na potrzeby developmentu. Dla wersji produkcyjnej zamiast *  lepiej zdefiniować adresy dokładniej, choćby tak: http://example.com/* lub nawet bardziej ogólnie: *://*.example.com/*.