Jaką technologię wybrać do stworzenia aplikacji mobilnej cross-platform? DevDebata cz.2

Przedstawiamy drugą część devdebaty, której celem jest poznanie różnych opinii developerów na jeden temat. Tym razem „pod młotek” wzięliśmy tworzenie aplikacji mobilnych, a dokładniej to, jaką technologię wybrać do stworzenia aplikacji cross-platform.

W pierwszej części devdebaty, którą opublikowaliśmy w ubiegłym tygodniu, zapytaliśmy naszych rozmówców o to, dlaczego tworzą aplikacje mobilne w podejściu cross-platform, w jakich przypadkach decydują się na tworzenie aplikacji natywnie oraz z jakich narzędzi korzystają podczas pracy. Dziś zapytaliśmy developerów m.in. o to, w jaki sposób testują aplikacje stworzone w modelu cross-platform.

O odpowiedź na pytania poprosiliśmy Damiana Antonowicza (Xamarin), Luuka van Venrooija (Cordova) oraz Michała Pierzchałę (React Native). Pytania przygotował Łukasz Olbromski.

Pytania zadaje:

Łukasz Olbromski. Ambitny programista, projektant, architekt z pasją i ponad dziesięcioletnim doświadczeniem zawodowym. Od 2015 roku pracuje jako freelancer. Obecnie związany z Omada A/S, gdzie rozwija system z obszaru Identity Governance and Administration. Swoje doświadczenie zdobywał w firmach takich jak: Capgemini, Credit Suisse, czy Microsoft. Specjalizuje się w tworzeniu aplikacji full stack na platformie .NET, legacy code, accessibility i testowaniem oprogramowania. Dzieli się swoją pasją i doświadczeniem jako promotor idei Make SENSE in IT.

Odpowiedzi udzielają:

Damian Antonowicz. Certyfikowany programista Xamarin tworzący aplikacje mobilne na platformy Android oraz iOS. Związany od wielu lat z platformą .NET i ekosystemem Microsoft, a szczególnie z systemem Windows Phone, na który tworzył aplikacje jeszcze przed jego premierą. Podczas swojej kariery zawodowej pracował nad różnorodnymi aplikacjami związanymi z bankowością, finansami, zdrowiem publicznym, motoryzacją. Pasjonat nowych technologii, bloger, prelegent i fan whisky.

Michał Pierzchała. Programista JavaScript, który pasjonuje się tworzeniem aplikacji webowych i mobilnych. Uwielbia poprawiać narzędzia i jakość kodu, dzielić się wiedzą. Jest jednym z głównych kontrybutorów frameworka do testowania Jest.

Luuk van Venrooij. Lider techniczny w firmie ABB Enterprise Software. Obecnie zajmuje się tworzeniem aplikacji hybrydowych w oparciu o Cordova/ReactJS/ASP.Net Core do zarządzania elektrowniami. Miłośnik otwartych standardów webowych, minimalizmu i prostoty. W wolnych chwilach gra, bawi się technologiami AR/VR oraz delektuje piwami rzemieślniczymi typu IPA.

Pytanie #5. Z jakich wzorców projektowych korzystasz?

Odpowiada Damian Antonowicz, Xamarin Certified Mobile Developer & Consultant:

W przypadku aplikacji tworzonych w Xamarinie najczęściej korzysta się ze wzorca MVVM, czyli Model-View-ViewModel. View określa jak dane powinny zostać wyświetlone, ViewModel określa co powinno zostać wyświetlone, jak i manipuluje modelem (odczyt z bazy danych, dostęp do zasobów sieciowych, wywołanie logiki biznesowej, itp.). View używa tzw. bindowania do danych dostarczanych przez ViewModel. Jeśli dane we VM się zmienią to ten fakt jest oznajmiany dla View przy pomocy interfejsu INotifyPropertyChanged.

W celu ułatwienia tworzenia aplikacji zgodnie ze wzorcem MVVM powstało wiele różnych bibliotek. Do najbardziej popularnych mogę zaliczyć MvvmCross, MvvmLight, Prism, ReactiveUI czy Caliburn.Micro. Jednak należy pamiętać, żeby przypadkiem nie wyciągnąć armaty na muchę. Niektóre frameworki są naprawdę rozbudowane i trzeba go dostosować w zależności od potrzeb aplikacji jaką tworzymy. MVVM to nie jest rocket science i w części przypadków może się okazać, że tak naprawdę możemy wszystko napisać sami (jeśli wymagania aplikacji nie są rozbudowane). Wszystko zależy jednak od konkretnego przypadku.

Odpowiada Michał Pierzchała, JavaScript Developer:

Zwykło mówić się, że React to tylko V w MVC. Programowanie w React (a więc i React Native) opiera się na jednokierunkowym przepływie danych pomiędzy komponentami, a cała reszta zależy od nas.

Komponenty są podstawową jednostką budowania aplikacji, na wejściu otrzymują argumenty, tzw. „propsy”, a na wyjściu renderują (albo i nie) jakiś widok, co pozwala myśleć o nich jak o funkcjach. Naturalne staje się pisanie deklaratywnego kodu poprzez kompozycję, która może zostać osiągnięta na kilka sposobów, np. poprzez Higher-order Functions (w świecie React nazywa się to HoC – Higher-order Copmonent).

Popularnym wzorcem, szeroko rozpowszechnionym w całym community, jest Flux (co nie powinno dziwić znając założenia Reacta), implementowany na wiele sposobów, w zależności od potrzeb.

Odpowiada Luuk van Venrooij, Lider techniczny:

With Cordova it depends on the frontend framework you choose. We currently have projects with:

• Sencha which would be MVC.
• AngularJS which can be MVC or MVVM depending on how you use it.
• ReactJS with Redux which I would consider to be Reactive with Command pattern.

Zobacz też

DevDebata Co sprawia, że nowy język programowania jest warty uwagi? Devdebata (cz. 2)

Pytanie #6. Jak testujesz aplikacje mobilne?

Odpowiada Damian Antonowicz, Xamarin Certified Mobile Developer & Consultant:

Aplikacje warto testować przede wszystkim na fizycznym urządzeniu, żeby sprawdzić jak będzie się ona zachowywać na docelowym sprzęcie. Jednak podczas codziennej pracy zdecydowanie góruje testowanie aplikacji na emulatorach. W przypadku Apple nie mamy wyboru i musimy korzystać z oficjalnych emulatorów bezpośrednio na Macu. Z kolei w przypadku Androida korzystam z emulatorów dostarczanych razem z SDK. Te emulatory kiedyś działały bardzo wolno, ale jakiś czas temu Google poprawiło ich działanie.

Do testów jednostkowych zazwyczaj używaliśmy połączenia NUnit oraz Moq. Chociaż w ostatnim projekcie skierowaliśmy się w stronę xUnit oraz NSubstitute. Osobiście nie jestem fanem mierzenia ilości pokrycia kodu testami jednostkowymi. Taka miara mówi nam jedynie, ile procent kodu jest uruchamianego podczas wykonywania testów. Z kolei nie wiemy czy testy jednostkowe są napisane poprawnie oraz czy napisaliśmy już wszystkie wymagane testy. Dążenie do jakiejś określonej ilości procentowego pokrycia może doprowadzić do sytuacji, gdzie będziemy pokrywać testami klasy dla samego ich pokrycia. Z tego powodu wolę zdefiniować te obszary aplikacji, które pokrycie testami jednostkowymi przyniesie najwięcej korzyści w perspektywie czasu.

Z kolei testy UI tworzymy w C#. Same testy UI powinny według mnie testować konkretne przypadki użycia aplikacji. Same testy uruchamiamy automatycznie każdej nocy na emulatorach, żeby sprawdzić poprawność założeń biznesowych. Testy uruchamiane są w nocy, ponieważ wykonują się one po prostu długo.

Testy UI nadają się lepiej np. do sprawdzenia poprawności nawigacji w aplikacji. Jeśli chcielibyśmy pokryć tą funkcjonalność testami jednostkowymi to musielibyśmy użyć mockowania i w ten sposób uzależnilibyśmy się od konkretnej implementacji sposobu nawigacji w aplikacji. Jeśli chcielibyśmy zmienić framework do MVVM to również musielibyśmy zmieniać nasze testy jednostkowe. Testy UI są pod tym względem lepsze, że operują na interfejsie graficznym i nie są zależne od wewnętrznych mechanizmów aplikacji. W ostatnim projekcie testy UI przydały się do zweryfikowania poprawności aplikacji po tym jak usunęliśmy z projektu framework MvvmCross.

Odpowiada Michał Pierzchała, JavaScript Developer:

React Native pozwala na jednoczesne podpięcie wielu urządzeń, więc normą jest rozwijanie projektu renderując go w symulatorze iOS i emulatorze Android w tym samym czasie. Niewątpliwą zaletą RN jest niesamowita szybkość, z jaką jesteśmy w stanie wprowadzać zmiany w aplikacji – po zapisaniu pliku, aplikacja zostanie całkowicie lub jedynie częściowo (np. z zachowaniem stanu aplikacji) przeładowania w czasie poniżej sekundy. Bardzo ważne jest jednak testowanie na prawdziwych urządzeniach, więc warto mieć przynajmniej po jednym pod ręką.

Jeśli chodzi o automatyzację, do testowania kodu JS używamy naszej ulubionej platformy do testowania Jest. Pozwala nam na testowanie logiki biznesowej, działania i współdziałania komponentów, modułów, nawigacji. Plusem jest wykonywanie się tych testów tylko poprzez JavaScript, więc uruchomimy je na każdej maszynie, jednak wiele natywnych API zostaje zamockowanych.

Pisanie wszystkiego w JavaScripcie (lub pochodnych) staje się po pewnym czasie całkiem wygodne, dlatego do klikania po aplikacji w symulatorach i na CI używamy Detox. Takie testy wykonują się zwykle w czasie kilku-kilkunastu minut, w zależności od ilości, więc z powodzeniem możemy uruchamiać je przy każdym „pull requescie”. W przypadku testowania na większej ilości urządzeń, musimy opuścić JS-ową strefę komfortu i zdać się na rozwiązania natywne, np. Appium uruchamiane na wielu urządzeniach w AppCenter (vide wypowiedź Damiana).

Odpowiada Luuk van Venrooij, Lider techniczny:

Besides unit tests to cover core functionality we also have end to end testing suites for most of the applications to test the general flow and processes. We use a few different libraries to facilitate the unit end e2e tests depending on the frontend stack used.

Both sets of tests are run on a browser level on each build. Additionally, the end to end tests are also run on Android and iOS devices using Appium. Windows UWP is not supported unfortunately.

Finally there is the manual testing on actual devices. We do this to validate the layouts across platforms and to make sure all interaction with physical hardware (camera, GPS, flashlight etc) are working properly across devices.

Oferty pracy z

Pytanie #7. Jak wygląda społeczność skupiona wokół technologii?

Odpowiada Damian Antonowicz, Xamarin Certified Mobile Developer & Consultant:

W Polsce mamy bardzo fajną grupę offline XaMarines spotykającą się w Krakowie. Na spotkaniach są poruszane ciekawe tematy i przychodzi zawsze sporo osób. Można wymienić się doświadczeniem i poznać nowe zagadnienia. Zdecydowanie polecam, szczególnie jeśli mieszka się w Krakowie. Z kolei osoby z trójmiasta i okolic może zainteresować niedawno powstała grupa Xamarin Meetup Gdańsk.

Jeśli chodzi o społeczność online to wydaje mi się ona bardzo prężnie działającą społecznością. Z ciekawy inicjatyw mogę wymienić np. cotygodniowy newsletter z nowościami: Weekly Xamarin, agregator blogów: Planet Xamarin, Xamarin Chat na Slacku, gdzie zawsze można zadać pytanie, blog Xamarin Help z ciekawymi i przydatnymi wpisami. Warto również wspomnieć o GitHubie Jamesa Montemagno, w którym znajdziemy wiele przydatnych bibliotek.

Oczywiście to nie jedyne ciekawe miejsca w sieci i na pewno można by jeszcze do tej listy dodać wiele innych. Na samym GitHubie jest sporo różnych projektów związanych z Xamarinem. Jeśli zabrakło nam czegoś przy tworzeniu projektu to właśnie na GitHubie znajdowaliśmy potrzebne nam komponenty. Jest tego naprawdę mnóstwo. Zawsze możemy też zwrócić się w stronę komercyjnych rozwiązań np. od Telerika czy DevExpress.

Odpowiada Michał Pierzchała, JavaScript Developer:

Społeczność React Native jest dosyć młoda (sam framework dostępny jest dopiero 3 lata) i bardzo dynamiczna. Większość zainteresowanych pochodzi z ogromnej społeczności sympatyków React. Istnieje oficjalny kanał wsparcia na Discordzie Reactiflux, forum na Discuss oraz oczywiście cała masa wiedzy na ulubionym portalu programistów – Stack Overflow.

Od 2017 roku powstają pierwsze konferencje poświęcone w całości temu frameworkowi, jak amerykańskie Chain React czy europejskie React Native EU (organizowane przez Callstack). Organizujemy również okazjonalnie meetupy we Wrocławiu oraz innych europejskich miastach. Z racji sporego powiązania z JS-em, sympatycy React Native spotykają się również na meet.js oraz grupach związanych z Reactem.

Odpowiada Luuk van Venrooij, Lider techniczny:

Cordova is probably one of the oldest and still most widely used cross-platform development technology and I would consider it just after its peak. The community is huge, and the various supported platforms and plugins are well maintained and regularly updated. Lots of other cross-platform development frameworks like Ionic, PhoneGap and Framework7 are based on Cordova making the community even larger.

Zobacz też

DevDebata Lepiej pracuje się w 100% zdalnym zespole? Devdebata

Pytanie #8. Którą technologię byś wybrał?

Odpowiada Damian Antonowicz, Xamarin Certified Mobile Developer & Consultant:

Chyba nie będzie niespodzianki jeśli powiem, że Xamarin? Każda technologia ma swoje wady i zalety. Na pewnym poziomie w każdej technologii będziemy robić to samo tylko przy pomocy innych narzędzi oraz metod. Ostatecznie sprowadza się to po prostu do stworzenia aplikacji mobilnej. Na pewno przy wyborze technologii ważne jest doświadczenie/upodobania jakie mamy. Osobiście od zawsze byłem związany z .NET i to jest technologia, w której dalej chce działać i się rozwijać. Wszystkiego można się nauczyć, ale pamiętajmy, że doba ma tylko 24h, a z wiekiem ilość wolnego czasu coraz bardziej maleje.

Odpowiada Michał Pierzchała, JavaScript Developer:

Z racji swojego doświadczenia, oczywistym wyborem będzie React Native. Jeśli będzie to mała aplikacja, do jej rozwijania użyłbym Expo (zestaw narzędzi upraszczających pracę z RN). Jeśli coś większego, zdecydowałbym się na czysty React Native. Nie jest natomiast oczywiste w jakim języku pisałbym swój kod. Wcale nie musi być to JavaScript. Na fali języków kompilowanych do JS, powstały ciekawe propozycje jak ReasonML – czyli niestandardowa składnia i zestaw narzędzi do silnie typowanego OCamla z świetnym systemem typów, co zaowocowało biblioteką ReasonReact, w pełni wspierającą RN.

Dodatkowo, Google wydał ostatnio w miarę stabilną (kto śledzi rozwój produktów Google, ten wie o czym mówię) wersję beta Flutter, o którym wspomniałem wcześniej. W podobnym kierunku może pójść open-sourcowy rozwój React Native i np. w niedalekiej przyszłości być może pojawi się biblioteka kompilująca ReasonML bezpośrednio do kodu natywnego, pomijając całkowicie wątek JavaScriptowy.

Odpowiada Luuk van Venrooij, Lider techniczny:

When Cordova was introduced it was designed to fill the gap to give web applications the ability to interact with the various hardware and software features. With the HTML5 spec this gap is getting smaller and smaller every year (https://whatwebcando.today/). Lots of things we used to need Cordova and some plugin for we can now do in plain HTML5.

Then there is the push of several big companies like Google, Apple and Microsoft to properly support Progressive Web Apps on their various platforms. This gives web applications the ability to be installed like native applications without the need for a wrapper like Cordova.

Finally, there is the appearance of new technologies like web-assembly which will give a huge boost in performance and the use of other languages besides JavaScript to create PWAs. With all these developments I think that HTML5 based PWAs will be one of the easiest ways in the future to create cross-platform applications. Until that time I’m sticking with Cordova.

Przeczytaliście właśnie drugą część devdebaty, mamy nadzieję, że znaleźliście w niej odpowiedzi na nurtujące Was pytania. Już pracujemy nad następną devdebatą, ale jesteśmy ciekawi, jak odpowiedzielibyście na postawione wyżej pytania. Dajcie znać w komentarzach, kiedy Wy decydujecie się na tworzenie aplikacji w podejściu cross-platform, a kiedy natywnie.