React Native – czym jest Expo i czy warto go użwać?

Wielu programistów na pewno kojarzy Reacta. Z nazwy to może nawet i wszyscy. Jego młodszy brat, React Native, nie jest na razie aż tak znany, chociaż widać, że zyskuje na popularności.

 

Czym jest React Native?

Jest to technologia stworzona przez Facebooka i używamy jej do tworzenia wieloplatformowych aplikacji mobilnych. Piszemy tutaj kod w JavaScript – i mam tu na myśli wszystko, zarówno logikę, jak i widoki. Cały kod jest wspólny dla wszystkich platform. Obecnie są to Android oraz iOS. Microsoft zbudował też własne rozwiązanie, które umożliwia tworzenie aplikacji UWP za pomocą React Native’a.

Jak zacząć pierwszy projekt?

Rozpoczęcie jest teoretycznie bardzo proste, wystarczy podążać za oficjalnym poradnikiem. Praktycznie nie zawsze jest tak różowo, bo nawet nowo stworzony projekt potrafi się nie zbudować 🙂 Najczęściej to jednak kwestia ustawienia pewnych rzeczy w naszym środowisku. Niestety nie wszystko jest wspomniane w oficjalnym poradniku. Nie będę jednak rozpisywał się tu o błędach, które napotkałem, bo można by stworzyć o tym oddzielny tekst.

Możemy zacząć na 2 sposoby. Wiele osób nie zwraca na to uwagi, ale w oficjalnym poradniku jest druga zakładka, która pokazuje jak zacząć w inny sposób. Czym są te 2 sposoby? Pierwszy to projekt z Expo – teoretycznie prostszy i polecany przez Facebooka. Drugi to czysty React Native, bez Expo. Przyjrzyjmy się temu bliżej.

Czym jest Expo?

Expo to w zasadzie całe środowisko ułatwiające pracę z React Native. Mamy do dyspozycji kilka rzeczy:

• Expo IDE (XDE) – aplikacja, która pomaga w budowaniu aplikacji, wrzucaniu jej na urządzenie oraz debugowaniu,
• exp – aplikacja linii poleceń, alternatywa dla XDE
• Aplikacja mobilna – instalujemy ją na urządzeniu z iOS lub Androidem i odpalamy przez nią naszą aplikację w trakcie developmentu. Naszą aplikację i zmiany w niej można przesyłać lokalnie lub poprzez serwery Expo. Na emulatorze/symulatorze XDE zainstaluje aplikację mobilną Expo automatycznie.
• Biblioteki – Expo oferuje dużo pomocniczych bibliotek, które znacznie ułatwiają tworzenie aplikacji, np. logowanie przez Facebooka, obsługa powiadomień, kamery, czy lokalizacji.
• Serwery do budowania aplikacji
• Konto Expo – możemy stworzyć darmowe konto, wtedy proces odpalania naszej aplikacji w mobilnej aplikacji Expo jest jeszcze łatwiejszy, ponieważ widzimy listę naszych projektów.

Zalety Expo

Po powyższej liście widać, że Expo daje nam dużo i powinien ułatwić tworzenie aplikacji. Niektóre korzyści są widoczne na pierwszy rzut oka, o innych trzeba jeszcze powiedzieć:

• Dzięki dodatkowym bibliotekom możemy o wiele szybciej zaimplementować niektóre funkcjonalności. Bez nich mielibyśmy po prostu więcej pisania. Pewne popularne rzeczy najczęściej robi się w ten sam sposób i Expo w większości robi to już za nas.
• Serwery do budowania aplikacji są szczególnie przydatne dla osób, które nie mają maszyny z MacOS. Aplikacje na iOS można budować tylko na MacOS. Mając do dyspozycji serwery Expo możemy tworzyć na iOS z dowolnego systemu.
• Proces startowania i debugowania aplikacji jest trochę ułatwiony. Nie jest to wielkie ułatwienie, bo i tak nie jest z tym źle, ale zawsze to jeden krok mniej.
• Nie musimy pisać nic w Javie czy Objective-C, a więc natywnych językach Androida i iOSa. W czystym React Native czasami trzeba coś tam pozmieniać, np. numer wersji, czy pozwolenia do lokalizacji w manifeście albo dodać kod inicjalizujący jakąś bibliotekę. Expo udostępnia swoje biblioteki, które nie wymagają już takiej inicjalizacji. Posiada także swój manifest, gdzie dodajemy wszystkie ustawienia związane z obiema platformami.

Wady Expo

Expo jest super! Sami widzicie. Ale może ma jakieś wady? Hmm, zobaczmy.

• Expo jest tworzone przez firmę trzecią, a nie przez Facebooka. Na razie jest darmowe, ale nie zawsze tak musi być.
• Nie mamy dostępu do natywnego kodu. To była zaleta, ale jest to też wada. W czystym React Native mamy foldery android oraz ios, gdzie znajdują się natywne projekty w Javie i Objective-C. Expo ukrywa przed nami te foldery i nie możemy tam nic zmieniać. Oznacza to, że jeśli biblioteka wymaga incjalizacji w kodzie natywnym i nie ma jej wersji dla Expo, to nie będziemy w stanie użyć tej biblioteki.
  • Dobrym przykładem, gdy będzie to problemem jest sytuacja z mojego ostatniego projektu. Expo ma własną kontrolkę mapy. Musiałem dodać do niej grupowanie markerów. Znalazłem odpowiedni przykład, ale nie działał. Jedyną alternatywą było użycie innej biblioteki, która wymagała zainicjalizowania w folderach android oraz ios. Musiałem więc zrezygnować z Expo w projekcie.
  • Kolejnym przykładem może być biblioteka do lokalizacji. Z jakiegoś powodu wersja tej biblioteki od Expo nie działa na emulatorze Androida, musimy mieć fizyczne urządzenie. Do tego dokładność raportowanych danych wynosi minimalnie 10 metrów. Czy jest to jakiś błąd w bibliotece? Być może. Jeśli więc potrzebowalibyśmy większej dokładności, Expo mogłoby nie zdać egzaminu.
• Kod w tle nie działa na razie w Expo. Takie rzeczy jak lokalizacja w tle, czy odtwarzanie muzyki w tle na razie jest niemożliwe do zrealizowania z Expo.
• Nie wszystkie natywne API są dostępne z Expo, jak np. dostęp do bluetooth.
• Rozmiar aplikacji będzie większy niż bez Expo. Jeśli zależy nam na małej paczce, to warto na bieżąco monitorować jej rozmiar.

Używać więc Expo, czy nie? ExpoKit ratunkiem?

Być może po przeczytaniu powyższych informacji zadajesz sobie to pytanie. Ja przed projektem staram się zanalizować, czy wszystko co chcę osiągnąć będzie możliwe z Expo. Nie zawsze da się to zrobić, bo możemy nie znać wszystkich wymagań klienta, czy mogą się one zmienić z czasem. Istnieje jednak pewne rozwiązanie tej sytuacji i nazywa się ExpoKit. Jest to natywna biblioteka, która pozwala nam na używanie Expo w czystym projekcie React Native. Do projektu zostaną wtedy dodane projekty android oraz ios  i będziemy mogli dopisywać natywny kod w razie potrzeby, a także dalej korzystać z bibliotek Expo… ale tylko z części z nich. Kolejny minus jest taki, że jest to na razie eksperymentalna funkcja i nie wszystko może działać poprawnie. Jeśli jednak uznamy później, że zmiana ta nie była nam potrzebna, możemy wrócić z ExpoKit do normalnego Expo, zgodnie z tym poradnikiem.

A może pisać bez Expo?

Istnieje też taka możliwość. Powiedziałbym, że wybór sprowadza się do wymagań projektu oraz naszego doświadczenia w natywnych technologiach. Jeśli znamy dokładnie wymagania, przeanalizujemy je i będziemy pewni, że jest to możliwe do zrobienia z Expo, to możemy je wybrać. Dla początkujących taka analiza może zająć trochę czasu, ale z drugiej strony Expo uprości też wiele procesów i pozwoli łagodniej wejść w świat tworzenia aplikacji mobilnych. Jest to dobre zwłaszcza dla osób znających już technologie webowe. Jednak jeśli zauważymy, że Expo nie wystarczy, to może nie ma sensu zaczynać z nim projektu. Konfiguracja bibliotek dla React Native zazwyczaj jest dobrze opisana i wiemy co trzeba dodać w natywnym kodzie, więc nie jest to bardzo trudne. Gorzej, jeśli musimy sami napisać jakiś natywny moduł, ale jeżeli taka funkcjonalność nie jest dostępna w React Native, czy Expo, to i tak nie mamy wyboru. Osoby przychodzące ze świata technologii natywnych (Java/Objective-C) mają mniejszy problem, bo świetnie poradzą sobie i bez Expo.

Podsumowanie

React Native to dosyć młoda technologia, ale rozwija się bardzo dynamicznie i z tego co widzę, jest lubiana przez wielu deweloperów. Niewątpliwym jej plusem dla programistów webowych jest wykorzystywana technologia (JavaScript), mogą oni bowiem bez większych problemów zacząć z niej korzystać. Expo to jeszcze większe ułatwienie i osoby dopiero wchodzące w świat aplikacji mobilnych na pewno chętniej z tego skorzystają. Ma niski próg wejścia, ale nie jest pozbawione wad, więc z czasem może zaistnieć potrzeba porzucenia tego rozwiązania na rzecz czystego React Native.