W jakiego typu projektach mobilnych wybrać Xamarin.Native?

O Xamarinie słyszał z pewnością nie jeden programista, a już na pewno Ci wywodzący się ze stacku Microsoftu. Firma z Redmont silnie przykłada się do promowania tej technologii cross-platform na rynku aplikacji mobilnych. Sto procent API dostępnego na obu platformach można wykorzystać w Xamarinie. Świetne w tej technologii jest to, że używamy jednego języka do rozwoju aplikacji na obie platformy, ale nie to jest największą przewagą Xamarina nad podejściem natywnym. Jest nim wspólny rdzeń.

Krzysztof Baranowski. Senior Tools Developer (Mobile Applications) w Capgemini. Programista aplikacji mobilnych, pracujący na co dzień w krakowskim oddziale Capgemini. Pasjonat, który nieustannie pogłębia wiedzę wokół tematu aplikacji mobilnych. Autor bloga Programistą Być, gdzie dzieli się wiedzą i pomysłami z obszaru programowania. Amator fotografii i podróżnik w jednym.

Rdzeń, czyli kod, który może być wykorzystany na obu platformach. Wszelkiej maści dostępy do API backendu, obliczenia, nawigacja, możemy napisać raz i bez problemów korzystać w aplikacjach wynikowych. Do tego dochodzi API .NET Standard, które daje ogromną bazę gotowych do użycia rozwiązań.

Xamarin to naprawdę świetna technologia

Xamarin świetnie sprawdza się w tworzeniu aplikacji biznesowych, czyli takich, które ponad doświadczenia użytkownika, stawiają na przedstawienie użytkownikowi potrzebnej mu informacji. W tego typu aplikacjach najczęściej warstwa UI jest zazwyczaj uproszczona i ma za zadanie tylko w czytelny sposób przedstawić konkretne dane. Xamarin świetnie się tu sprawdzi ze względu na warstwę Core. Z dużą dozą prawdopodobieństwa znajdzie się tu spora ilość kodu, co znacząco ułatwi utrzymanie aplikacji i pozwoli na jej szybszy i tańszy rozwój.

Wielokrotnie słyszałem z ust innych programistów mobilnych, że Xamarin to kompletne dno, że pisać się w tym nie da, że wolne to i że rok, dwa i będzie pozamiatane. I nie są to słowa wyssane z palca. Rzeczywiście z takimi opiniami się spotkałem. Moim subiektywnym zdaniem, opinie te były poparte brakiem zrozumienia przeznaczenia tej technologii i dużą
dozą ignorancji. Do tego dochodziło wąskie spektrum doświadczenia zawodowego i opinia, że technologie natywne po wieki wieków rządzić będą i cross-platform nie ma sensu się zajmować.

Jestem zdania, że podejście cross-platform to przyszłość i to wcale nie mocno oddalona. To dzieje się już dzisiaj na naszych oczach. Dowodem tego jest choćby Flutter, który staje się coraz popularniejszy. Często mam wrażenie, że technologie natywne i cross-platform to odpowiednik dawnego przejścia na fotografię cyfrową – ci, którzy zostali na kliszy (kompletna natywność) w pewien sposób przegrali.

Nie jestem rycerzem w lśniącej zbroi, który uparcie będzie bronić tej technologii, ale uważam, że jest to świetne narzędzie, choć nie idealne, ale użyte mądrze może zdziałać bardzo wiele. Dlatego przedstawię, w jakiego rodzaju projektach Xamarin jest świetną alternatywą dla podejścia natywnego, ale nie obejdzie się też bez krytycznych uwag i przestróg.

Jakie elementy możemy współdzielić?

Odpowiedź jest prosta. Wszystko to, co możemy napisać za pomocą API .NET Core Standard. W ogólności będzie to logika biznesowa oraz operacje na danych. Dane są integralną częścią każdego systemu. W typowej aplikacji mobilnej dane te uzyskujemy poprzez pobranie ich z jakiegoś źródła. Dlatego właśnie dostęp do API serwera jest tym, co znajdzie się w projekcie Core naszej aplikacji. Dodatkowo znajdą się tam wszelkiej maści serwisy, które na tych danych operują i przygotowują je do użycia w innych częściach systemu.

Czego nie możemy współdzielić? Oczywiście API Androida oraz iOS. Te znajdą się w dedykowanych dla nich projektach, a każdy z nich skorzysta z projektu współdzielonego.

Co pomoże nam usprawnić development?

Frameworki i odpowiednia architektura. Jeżeli chodzi o Xamarina mamy kilka dostępnych frameworków m.in. MvvmCross, Prism, MvvmLight. Sądząc po nazwach, można wywnioskować, że pomagają w implementacji wzorca MVVM. I tak jest w istocie. To dzięki niemu i wynikającemu z niego podziale architektury, frameworki te mogą udostępniać gotowe komponenty, które znacząco usprawniają i przyspieszają rozwój aplikacji. Ze wszystkich dostępnych najbardziej rozbudowanym jest chyba MvvmCross. Daje on nam dostęp do gotowego mechanizmu data bindingu, serwisów do tworzenia nawigacji czy kontenera IoC. I to wszystko do wykorzystania w projekcie Core. Jeżeli wszystko odpowiednio rozplanujemy, wystarczy, że dodamy widoki korzystające z modeli widoków, dodamy wymagane serwisy platformowe, a MvvmCross zrobi wszystko za nas. Oczywiście jest to spore uproszczenia, ale obrazuje ilość pracy zaoszczędzonej dzięki użyciu tego narzędzia.

Wybór technologii

Przychodzi moment wyceny czasu developmentu przyszłej aplikacji mobilnej. Mamy w zamiarze stworzyć dwie aplikacje: Android oraz iOS. Oprócz podejścia natywnego rozważamy użycie Xamarina. W takim przypadku musimy konkretnie zaplanować, czym ma być aplikacja, z czym powinna się integrować (zewnętrzne SDK), czy jest to aplikacja biznesowa czy skierowana do typowego konsumenta. Jakie jest jej zastosowanie? Jak dużo wspólnej logiki biznesowej dla obu platform możemy wyodrębnić? Czy nasza aplikacja w przeważającej część będzie korzystać z API platformowego?

To są jedne z podstawowych pytań, które powinno się zadać przed wyborem odpowiedniej technologii. Niektóre z nich są zależne od siebie, a każde z nich ma odpowiedź z odpowiednim priorytetem. Przejdźmy do ustalenia, jakie odpowiedzi dla konkretnych pytań definiują użycie Xamarina oraz co dodatkowo wiąże się z wybraniem odpowiedniej technologii.

Jak dużo możemy wyodrębnić?

Jak wspomniałem wcześniej, istnieje spory worek logiki, który z pewnością możemy wyodrębnić do warstwy wspólnej. W zasadzie każda większa aplikacja produkcyjna posiada swój dedykowany backend, więc obsługa żądań do niego, przetwarzania danych i ich udostępnienia, z pewnością zostanie napisana tylko raz. Jest to ogromna przewaga względem podejścia natywnego, gdzie taki kod musimy napisać dla każdej platformy, co przekłada się na wyższe koszty utrzymania projektu. Tutaj raz i korzystasz na każdej platformie.

Czy aplikacja ma integrować się zewnętrznymi SDK?

To jest jedno z kluczowych pytań, które może przechylić szalę zwycięstwa na jedną ze stron. Zdarza się, że aplikacja mobilna ma korzystać z rozwiązań firm zewnętrznych. Chodzi mi tu o SDK przez nie przygotowane. Xamarin ma to do siebie, że nie jest w stanie skorzystać z bibliotek natywnych bez ich poprzedniego przygotowania. Proces ten nazywany jest wrappowaniem lub bindowaniem bibliotek. Jego zadaniem jest przekonwertowanie biblioteki napisanej w Javie (Android), Swift/C (iOS) na kod .NET. Tak przygotowaną paczkę możemy użyć jako komponent w naszym projekcie. O ile biblioteka nie jest duża i skomplikowania bindowanie przechodzi w zasadzie bez większych problemów.

Kłopot jest wtedy, gdy biblioteka jest naprawdę dużych rozmiarów. Wtedy proces ten może naprawdę trwać tygodniami, ze względu na mnóstwo problemów, które napotyka się podczas prac. Za każdym razem, gdy pojawi się nowa wersja biblioteki, prace należy przeprowadzić ponownie.

Miałem okazję bindować kilka bibliotek napisanych w Swift czy Javie i nie wspominam tego jako przyjemnie spędzony czas. Należy jednak zaznaczyć, że radość była niesamowita, kiedy udało mi się otrzymać prawidłowo zbindowaną bibliotekę.

Jeżeli w planach jest użycie konkretnej biblioteki zewnętrznej, warto przeprowadzić R&D, które stwierdzi jak bardzo problematyczne będzie przygotowanie takiego bindingu. Jak mawiają programiści, którzy się tym zajmowali: „Estymacja czasu bindowania to od tygodnia do plus nieskończoności”.

Ilość kodu platformowego

Jak dużo API systemowego znajdzie się w wynikowej aplikacji? Jeżeli nasza aplikacja wymaga dużej ilości kodu platformowego, który obsłuży wymagane mechanizmy, a jednocześnie ilość kodu współdzielonego jest niewielka, to użycie Xamarina prawdopodobnie mija się z celem.

Weźmy jako przykład aplikację, gdzie istnieje dosłownie kilka odwołań do API backendu, a warstwa UI jest skomplikowana i istnieją 2/3 widoki.

Moim zdaniem w takim przypadku znacznie lepiej jest skorzystać z podejścia natywnego. I tak musimy pisać i utrzymywać oddzielnie kod platformowy. Nie ma co kryć, podejście natywne w takim przypadku znacznie przyspieszy proces tworzenia aplikacji. Przede wszystkim biorąc pod uwagę to, że możemy skorzystać z mnogości dostępnych bibliotek. Co więcej warstwa Core będzie niewielka, więc benefit wynikający ze współdzielonego kodu jest nikły.

Czas rozwoju aplikacji

Wbrew pozorom, jeżeli czas poświęcony na development przy użyciu Xamarina zrówna się z estymacją podejścia natywnego to świetnie! Czas developmentu to nie jedyny czas, kiedy programiści pracują nad aplikacją. Kolejnym krokiem jest jej utrzymanie, od poprawy błędów, aż po nowe mechanizmy. Z dużym prawdopodobieństwem Xamarin lepiej poradzi sobie przy utrzymywaniu aplikacji, względem podejścia natywnego. W takim przypadku niekoniecznie musimy pilnować logiki dwóch oddzielnych projektów aplikacji jak w podejściu natywnym. Jeżeli błąd pojawi się w logice warstwy wspólnej to wspaniale, upieczemy dwie pieczenie na jednym ogniu, natomiast jeżeli pojawił się tylko na jednej platformie, to niczego nie tracimy – w podejściu natywnym poświęcilibyśmy prawdopodobnie tyle samo czasu na jego poprawę.

Bolączki Xamarina

Do tej pory oberwało się problematycznemu mechanizmowi bindowania bibliotek i braku możliwości bezpośredniego użycia już dostępnych. To co boli w drugiej kolejności to czas budowania rozwiązania i udostępniania go na urządzenie. W zależności od platformy docelowej czas jest różny i w tym przypadku przoduje iOS względem Androida. Od czasu rozpoczęcia budowania, do zobaczenia ekranu początkowego, w najgorszym przypadku może minąć nawet kilka minut. Choć zazwyczaj jest to kilkanaście/kilkadziesiąt sekund.

Innym problemem jest rozwój aplikacji Androidowej i chodzi tu o problem przebudowywania zasobów. Problemy z brakiem jakiegoś zasobu, który fizycznie istnieje i ma się dobrze, jest w zasadzie chlebem powszednim. W takim przypadku pomaga następujący ciąg instrukcji: „rebuild, deploy, clean, remove bin/obj, rebuild, deploy”. Po kilku próbach wszystko wraca do normy. W przypadku iOS wszystko raczej przebiega poprawnie. Raz na jakiś czas pojawi się jakiś problem przy budowania, ale prawie zawsze pomaga najzwyklejsze przebudowanie solucji.

Jeżeli pojawią się nowe wersje SDK dla iOS oraz Android musi minąć trochę czasu, zanim zostaną przygotowane i będzie dostępne do użycia w Xamarin. Warto o tym pamiętać.

Kiedy zwrócisz uwagę na rozmiar paczki z aplikacją, to okaże się, że w stosunku do analogicznej aplikacji napisanej natywnie jest od niej nawet kilkukrotnie większa. Produkcyjna aplikacja dostępna w sklepie może ważyć nawet kilkadziesiąt megabajtów. Xamarin dorzuca do paczki środowisko uruchomieniowe Mono, które zwiększa na stałe rozmiar o kilka dodatkowych megabajtów. Swoje pięć groszy dorzucają dodatkowe biblioteki użyte w projekcie.

Podumowanie

„Weźcie Xamarina, czas developmentu skróci się o połowę”. Liczę na to, że po przeczytaniu tego artykułu będziesz wiedział, że to dość popularne powiedzenie jest mitem. Na to, ile czasu zajmie development przy użyciu Xamarina składa się wiele czynników, o których wspomniałem i starałem się wyjaśnić w artykule. Jak wspomniałem wcześniej, Xamarin jest naprawdę potężnym narzędziem, które użyte mądrze i w odpowiedniego rodzaju projekcie może zaoszczędzić mnóstwo pracy, co naturalnie przekłada się na budżet. Należy mieć jednak na uwadze, że pomimo stałego rozwoju nadal jest to technologia kapryśna, problematyczna na wielu płaszczyznach i często wymagająca dużej dawki cierpliwości.

Mimo to uważam, że jest to narzędzie, które zapewne nie będzie wspierane przez dziesięciolecia, ale w najbliższych latach nadal z sukcesami będzie wspomagać tworzenie mobilnych aplikacji cross-platform.

Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z