W pierwszej połowie 2016 roku Microsoft dokonał oficjalnego przejęcia Xamarina. Dzięki temu posunięciu stał się właścicielem firmy, która dostarcza technologię pozwalającą na pisanie aplikacji mobilnych na systemy Google, Apple oraz własne. Pewnym ciekawym aspektem tej sytuacji jest opcja Xamarin.Forms. Przy pewnych założeniach zaoferuje nam ona multiplatformowe rozwiązanie, w którym współdzielona część może stanowić nawet ponad 95% całego kodu na każdej z platform docelowych.
Na papierze to wszystko brzmi pięknie, a jak w rzeczywistości wygląda praca z tym rozwiązaniem? Czy rzeczywiście jest tak kolorowo? Na te i inne pytania postaram się odpowiedzieć w dzisiejszym tekście.
Mobilny development — realia
Realia mobilnego developmentu są takie, że do oprogramowania mamy kilka systemów wykorzystujących różne języki programowania. Choć w praktyce dziś głównie liczą się Android (prawie 88% udziału w rynku według ostatnich badań) oraz iOS, to zdarzają się sytuacje, w których pojawiają się klienci zainteresowani systemem ze stajni Microsoftu. Rynek dąży jednak do duopolu, w którym możemy dość jednoznacznie wskazać lidera — niewątpliwie jest nim system od Google.
W związku z tym, jeśli chcemy wystartować na poważnie z nowym projektem wykorzystującym aplikacje mobilne jako część strategii, to wariantem minimum jest przygotowanie programów w wersji zarówno pod Androida, jak i iOS (opcjonalnie również pod Windows). Przygotowanie projektu pod dwa-trzy różne systemy niesie ze sobą oczywiście konieczność posiadania dwóch (trzech) równorzędnych zespołów deweloperskich, z których każdy zadba o inny system. Nie muszę chyba mówić, jak bardzo może to być kłopotliwe. Oprócz tego, że ponosimy koszty takiego rozwiązania, musimy utrzymywać dwie aplikacje w różnych językach, które powinny mieć w miarę możliwości wspólną logikę biznesową.
Właśnie w sferę takich problemów wchodzi Xamarin, który dostarcza wspomniane w tytule rozwiązanie Xamarin.Forms, a także alternatywne — Xamarin.Platform, pozwalające na współdzielenie kodu, głównie w sferze backendowej. Zaletą obu rozwiązań jest to, że używamy jednego języka do wszystkich systemów — C#. Każde z nich ma poza tym plusy i minusy, szerzej na ten temat pisałem na swoim blogu. W mojej pracy zdecydowaliśmy się skorzystać z tej pierwszej opcji — poniżej znajdziecie kilka konkluzji, do których doszedłem po prawie pół roku kodowania w Xamarin.Forms.
Na papierze — idealnie
„Na papierze” (na stronie produktu) Xamarin.Forms wygląda wręcz idealnie. Kilkadziesiąt wspólnych kontrolek, XAML, C# oraz ogólna szybkość i prostota w tworzeniu aplikacji. Twórcy są przed nami szczerzy tak naprawdę tylko w kwestii jednego problemu — bardziej natywne doświadczenie uzyskamy, stosując rozwiązania z Xamarin.Platform.
W praktyce ta technologia serwuje nam większą liczbę problemów.
W sytuacji gdy mamy konkretny projekt i nie możemy sobie pozwolić na kompromisy, prawdopodobnie okaże się, że i tak będziemy musieli skorzystać z natywnych elementów oferowanych przez Xamarin.Platform. Oczywiście będziemy mogli skorzystać z C#, ale może się okazać, że odsetek współdzielonego kodu spadnie z zakładanych ponad 90% do poziomu 70 – 80%. Konieczna w tym przypadku może być większa znajomość natywnych rozwiązań.
Nawet jeśli będziemy chcieli wycisnąć maksymalnie dużo z części wspólnej, to i tak nie obędzie się przynajmniej bez podstawowej znajomości rozwiązań systemowych. Wariantem minimum jest choćby konieczność konfiguracji obrazków per system, manifestu z Androida czy pliku Info.plist z iOS.
Sporym problemem jest również kontrolka listy. Standardowe XAML-owe ListView jest bardzo powolne i działa tylko wertykalnie. Brakuje mu układu horyzontalnego. Na NuGecie dostępna jest paczka z CarouselView, która potencjalnie mogłaby rozwiązać ten problem, ale na razie jest ona dość niestabilna, zawiera sporą liczbę błędów, a ponadto nie do końca spełnia założenia horyzontalnej listy jako takiej (CarouselView zakłada jeden element na całą szerokość ekranu). Dlatego też w sytuacji, gdybyście chcieli mieć w swojej aplikacji szybkie i wszechstronne listy, to prawdopodobnie będziecie musieli również sięgnąć po elementy natywne.
Indywidualnego podejścia będą wymagały także różne elementy charakterystyczne dla wspieranych systemów, których twórcom Xamarina nie udało się uwspólnić. Do takiego grona należy zaliczyć np. pływające przyciski na Androidzie.
Problemem mogą być też błędy po stronie Xamarin.Forms — czasem po prostu trzeba poczekać na kolejną wersję paczki nugetowej.
Mimo wspomnianych wyżej problemów da się, po pokonaniu kilku przeciwności losu, dość przyjemnie korzystać z tej technologii. Pisanie w XAML-u rzeczywiście jest szybkie. Warto również pomyśleć o MVVM, który pozwala na odpowiednią separację warstw aplikacji.
Xamarin.Forms po dwóch latach od uruchomienia wciąż ma swoje problemy, ale każda kolejna wersja przynosi coraz więcej nowych możliwości, optymalizację, stabilizację, a także poprawki powstałych wcześniej błędów. Rozwiązanie coraz bardziej nadaje się również do komercyjnych zastosowań, o ile klient nie wymaga bardzo natywnych layoutów.
Warto pamiętać, że programowanie pod Xamarin.Forms nie spowoduje, że nie będziemy musieli martwić się tym, że tworzymy oprogramowanie pod różne systemy. Wynikowo wciąż będziemy uzyskiwać paczki pod różne platformy, które mają swoją specyfikę.
