Jak działa i co to jest Xamarin?

poniedziałek, lutego 20, 2017   Development

Platforma Xamarin to relatywnie nowa technologia programowania aplikacji mobilnych. Używam określenia "relatywnie nowa" z przyczyny, że bez większych kłopotów da się jej używać od sierpnia 2013 roku. Można powiedzieć, że 3 lata w informatyce to olbrzymi przeskok technologiczny, jednak nie jest tak, że każdą świeżą technologię wykorzystuje się z miejsca. Wszystko musi dojrzeć.

Xamarin służy do tworzenia aplikacji działających natywnie w smartfonach z dominującymi systemami operacyjnymi takimi jak: Android (udział w rynku, stan na listopad 2016: 86.8%), iOS (12.5%), Windows Phone (0.3%) (źródło) czy też desktopowy Windows.

W (nazwijmy to) standardowym trybie tworzenia oprogramowania, na każdy z tych systemów, tworzy się osobne aplikacje, w osobnych IDE, w osobnych językach. Xamarin łączy to wszystko razem i za pomocą jednego kodu C# oraz XAML (Front-end aplikacji) i jednego IDE - Visual Studio (Xamarin Studio w wypadku macOS) tworzymy jedną aplikację, którą da się uruchomić na każdym z docelowych systemów.

Połączenie różnic między Google, Apple oraz Microsoft nie może odbyć się bez ofiar (zazwyczaj wśród programistów). Nie zaprogramujemy wszystkiego idealnie, ponieważ idziemy na kompromis.

Najprostszy przykład: w iOS nie istnieje coś takiego jak CheckBox - więc jeżeli chcemy użyć opcji wielokrotnego zaznaczania (co jest możliwe w Windows i Android) musimy: albo obejść to w jakiś sprytny sposób używając kontrolki switch, albo zaprojektować inaczej interfejs, albo dla każdego systemu zaprojektować dane okno inaczej (Xamarin zapewnia możliwości programowania osobno na dane systemy), albo pisać Custom Rendery imitujące zachowanie CheckBoxów albo rzucić to wszystko w diabły i dać sobie spokój.

A idź Pan z tym w...

To właśnie główna przyczyna niewielkiego przekonania do tej technologii w środowisku programistów. Kolejną jest to, że żeby dobrze kodzić w Xamarinie i tak trzeba mieć podstawy "czystych" SDK i zależności jakie są w tych systemach. Co prowadzi do wniosku, że skoro taki gość wie jak pisać "czysty" kod na daną platformę, to po co ma się męczyć z niedorobionymi technologiami "hybrydowymi"? Przy każdej dyskusji na forach na ten temat, padną te dwie (i wiele innych) zarzutów. Często od programistów, którzy się zrazili, bo coś im nie zadziałało, a nie zagłębili się w temat. Przywiera stereotyp i potem zaczynają się nawet krzyki kolesi, którzy nie mieli styczności z aplikacjami mobilnymi.

Wcześniej napisałem "hybrydowymi" w cudzysłowie ponieważ wielu programistów myśli, że skoro coś nie powstało w dedykowanym IDE to znaczy, że już coś jest nie tak i to na bank jest hybryda.

Well, how about no.

Aplikacja hybrydowa to aplikacja stworzona przy pomocy technologii webowych takich jak HTML, CSS oraz JavaScript. Zwyczajowo mają gorsze wykonanie, nie wszystko chodzi jak trzeba i są wolniejsze, ale uruchamiają się bez problemu na wszystkich urządzeniach. Zwyczajowo, bo każdy kod jeżeli jest wykonany dobrze, będzie chodził dobrze. Oczywiście kosztem łez programisty, któremu będzie brakować dostępu do pewnych elementów API, ale klient ma w poważaniu te łzy. W zasadzie tworzy się zwykłe strony internetowe dopasowane do pracy na telefonach. To najtańsze rozwiązanie.

Aplikacja natywna ma być szybsza, wykorzystywać pełne możliwości danego systemu i łatwiej rozwiązać pewne problemy, ale generalnie działa tylko na tym na co ją się stworzy. Więc jeżeli chcesz mieć ten sam kod na trzech systemach, musisz zatrudnić trzy zespoły, po jednym na platformę. Czyli dużo pieniędzy. Sami programiści będą płakać nad tym, że nie mają współdzielenia kodu, a każda nowa funkcjonalność w późniejszych etapach dystrybucji aplikacji musi być wprowadzona w trzech miejscach. Czyli jeszcze więcej monet.

Takie porównania często przy opisywaniu trzech podejść do tworzenia wieloplatformowych aplikacji, które obejmują koszta wytworzenia, sposoby utrzymania i supportu na samej jakości końcowej kończąc.

Gdzie w tym wszystkim jest Xamarin?

Xamarin wbrew pierwszemu założeniu, że skoro pisany jest w C#, to jest hybrydą, jest technologią natywną - zapewnia dostęp SDK dla Androida, iOS i Windowsa, czego nie ma w przypadku tworzenia z użyciem HTML i JavaScript. W Xamarin jest dostęp do natywnego API, nie ma żadnego pośrednika utrudniającego pracę z wyglądem. Ujednolicona warstwa backendowa działająca na wszystkich systemach to najmocniejsza zaleta tej platformy.

Kompilator danego systemu kompiluje aplikacje w Androidzie do IL, a w iOS do ARM. API systemów jest odpowiednio mapowane dzięki czemu wszystko jest natywne. W przypadku części Windowsowej Xamarin właściwie nie bierze udziału, z racji, że C# dla Windowsa jest językiem "naturalnym". Dzięki takiemu rozwiązaniu Xamarin jest przejrzysty, ale jak to mało to zawsze można przejrzeć dokładnie całe rozwiązanie na GitHub za darmo.

Rozwiązanie to kompromis na płaszczyźnie klient - programista, gdzie programista jest zadowolony z danych mu narzędzi (o ile zna i lubi C#), dzięki którym może tworzyć łatwe w utrzymaniu, skalowalne aplikacje, nie tylko na mało popularny Windows Phone, a klient, że dostanie dobry produkt nie płacąc kupy pieniędzy jak w przypadku tworzenia klasycznie aplikacji natywnych.

Xamarin.Forms, Xamarin.Android, Xamarin.iOS, Xamarin.Windows - Co się dzieje w tym projekcie?

Rozpoczynając pierwszy projekt można dostać zawrotu głowy - co jest co? Generalnie jednak zasada jest prosta, każda z powyższych odmian jest dedykowana pod konkretny system. Nad wszystkim jest Xamarin.Forms, który jest uniwersalny i obsługiwany wszędzie. W teorii, tutaj powinno się najwięcej pisać kodu, tylko odnosząc się do pozostałych odnóg w momentach gdy rozwiązujemy problem charakterystyczny dla danego systemu (jak np. zapis plików). W optymistycznych przypadkach zmieści się tutaj ponad 90% kodu.

Oczywiście wydaje się, że skoro piszemy kod cross-platformowy to powinniśmy oszczędzić czas i pieniądze pisząc 3 razy szybciej. Niestety tak nie będzie, ponieważ pewne rzeczy jak baza danych, zapis plików, lub bardziej zaawansowane elementy graficzne będzie trzeba rozwiązać z użyciem dedykowanych konstrukcji warunkowych - może na tym zejść dużo kodu i dużo czasu.

Największe wady.

Problemem Xamarina są aktualizacje - każdy system ma swoje aktualizacje wersji, defragmentacje wypuszczone w określonym czasie. Twórcy Xamarina dwoją się i troją żeby wszystko działało jak należy, ale jedna aktualizacja będzie lepsza, druga gorsza - coś dodadzą, coś zniknie. Aktualnie wszystko działa stabilnie, bez kłopotów, ale nie daję gwarancji na to, że Visual Studio wraz z projektem nie staną w ogniu.

Oczywiście jeszcze największe problemy stanowi programowanie aplikacji pod iOS z Windowsa. Niby jest to rozwiązane, bo wystarczy żeby w sieci było podpięte urządzenie Apple z macOS, jednak trzeba to urządzenie posiadać fizycznie bo połączenie z maszyną wirtualną nie zadziało. A z drugiej strony korzystając z Xamarin Studio na iMacach nie mamy możliwości tworzenia aplikacji pod Windowsa (thanks, XCode). Pewnie programiści iOS ogarnęliby ten temat lepiej i wszystko bym im ruszyło - ja tu miałem największe problemy.

Ostatnią wadą jest Preview Designer dla XAMLa, który wyświetla w przystępnej formie podgląd napisanego przez nas układu kontrolek dla każdego z systemów, jednak uruchomienie go wymaga macOS, a z tym jak napisałem w poprzednim akapicie miałem problemy. Aczkolwiek, praktyka pokazuje, że nie jest to narzędzie niezbędne do pracy, ponieważ po samodzielnym zaprojektowaniu i napisaniu 3, 4 okienek można stać się w tym biegłym i nie potrzebować podglądu. Jednak jakby ktoś był uparty to jest narzędzie, które zastępuje Preview Designer - Gorilla Player. Kolejnym problemem z którym da się żyć jest beznadziejny debbuger w Visualu. Ciężko wyczaić dlaczego kod który miał działać nie działa. Wtedy zazwyczaj jest jazda na forum i przeglądanie dokumentacji. Jednak tutaj również jedyne co mogę powiedzieć to praktyka, praktyka i praktyka.

Poniżej prosta tabela zależności co zakodzisz na czym:

IDE	Android	iOS	Windows UWP
Visual Studio na Windows	TAK	TAK (Jeżeli masz w sieci urządzenie z macOS)	OWSZEM
Xamarin Studio na macOS	TAK	OWSZEM	ZAPOMNIJ

Jaka praca - taka płaca.

Utopijne i cudne opisy, wynoszenie tej technologii pod niebiosa, a także określanie pewnych poważnych błędów "przejściowymi drobnostkami" nie sprawi, że z dnia na dzień zrobi się boom na zapotrzebowanie programistów Xamarina. Nie znajdziecie na LinkedIn czy portalach z ogłoszeniami pracy zatrzęsienia ofert dla Xamarin Developer. Tak nigdy nie będzie nigdy z powodu ortodoksyjnego podejścia do tworzenia mobilnego softu. Zamiast pracy na etat, znacznie łatwiej znajdzie się zlecenie na wykonanie całego projektu za nie małe pieniądze, ponieważ jak pada w firmie pytanie: "Ktoś coś kodził w Xamarinie?", to wszyscy robią oczy jak pięciozłotówki. I wtedy firma szuka kogoś outsourcingowego. Jest to nisza którą .NET-owcy i programiści C# mogą łatwo wypełnić i łatwo zarobić, bo bez problemu z znajomością języka idzie ogarnąć temat i programować mobilne apki.

Dać szansę Xamarinowi czy sobie spokój?

Oczywiście, że dać szansę. Wady opisane w poprzednich akapitach, chociaż brzmią źle, są niczym z frajdy jaką daje tworzenie aplikacji w C#, którą możemy uruchomić wszędzie na wszystkim. Zwłaszcza jak komuś nie siedzi programowanie Androida czy iOS. Sądzę, iż kilka wad nie przeważa nad plusami.

A już nawet nie będę mówił, że programista sam od siebie winien wymagać nieustającego rozwoju i to już jest wystarczający powód, żeby napisać przynajmniej jedną aplikację na tej platformie.

Uważam, że Xamarin to super rozwiązanie do małych i średnich aplikacji, gdzie klient chciałby, żeby mu działało wszystko i wszędzie, a z góry wiadomo, że nie będzie tam dodawane mnóstwo nowych ficzerów. Na przykład aplikacja kilkudniowego festiwalu, cytat dnia, kalkulatory (przeliczniki, rejestratory smogu), aplikacje pogodowe, odtwarzacz muzyczny czy przeglądarka zdjęć idealnie tu się wpasują. Jak się śmieją programiści: do napisania Hello World wystarczy.

Nie zastosowałbym go w dużym biznesowym programowym kombajnie. Poważne, zaawansowane programy objęte codziennym supportem, powinny być rozwijane czysto natywnie. Ale to moje zdanie, programiści ze znacznie większą wiedzą i doświadczeniem w takiej materii, mogą powiedzieć co innego.

To technologia przyszłości i spora szansa na polepszenie żałosnej sytuacji Microsoftu w rynku mobilnym. Zwłaszcza w momencie w którym tworzony jest jeden kod, a chodzi on wszędzie. Takie rozwiązania unifikacji programowania to przyszłość. Technologia ma być rozwijana szybko i łatwo. Xamarin może stanowić na to odpowiedź.

Do rozpoczęcia nauki polecam Houssem Dellai (Facebook i YouTube). Całkiem fajnie i klarownie tłumaczy zagadnienia związane z tą technologią.

ShareShare on Facebook

TweetShare on Twitter

Pin ItShare on Pinterest