Xamarin Forms okiem początkującego – wprowadzenie

Tak jak ostatnio obiecałem, dzisiejszy wpis będzie poświęcony technologii Xamarin. Wspominałem już jakiś czas temu na łamach bloga, że w mojej szkole ruszył projekt związany z programowaniem. Pisałem również, że w jego ramach będę miał za zadanie stworzenie aplikacji mobilnej (z pomocą kilku innych osób, jednak one zajmują się pisaniem w PHP/grafiką). Ma to być szkolna aplikacja służąca do sprawdzania zastępstw, planu lekcji i ogłoszeń. Kiedy dostałem te zadanie (właściwie chciałem je dostać :)) miałem lekkie obawy, że nie uda mi się pogodzić udziału w konkursie DSP i nauki Xamarina po godzinach. W końcu obydwie rzeczy pochłaniają całą masę czasu. Jednak Xamarin okazał się na tyle przyjazną technologią, dla osoby mającej już jakieś tam doświadczenie w pisaniu w C# i XAML’u, że ogarnięcie go nie zajęło mi tak wiele czasu, jak na początku zakładałem. Oczywiście jest jeszcze na pewno masa rzeczy, których nie wiem(ba, nawet wspominanej aplikacji pisać nie skończyłem). Jednak myślę, że warto będzie podzielić się tutaj tym, czego zdążyłem się już nauczyć 😉

Na co pozwala Xamarin i czym właściwie jest?

Xamarin to technologia pozwalająca na pisanie aplikacji mobilnych przy użyciu C# dla trzech dużych platform (Windows, Android, iOS). Możliwe są dwa podejścia pisania aplikacji, przy jego użyciu:

  • Aplikacje natywne – Są to aplikacje, które pisze się z przeznaczeniem tylko na jedną konkretną platformę. Dzięki temu, że Xamarin mapuje całe API Androida i iOS’a programowanie takich aplikacji zasadniczo nie różni się od zwykłego podejścia dla danej platformy. Oczywiście poza tym, że tutaj używa się C#, a nie Javy, czy Objective-C. Jego zaletą jest dostęp do bardzo specyficznych funkcji każdego z systemów.
  • Aplikacje cross-platformowe oparte o Xamarin.Forms – Aplikacje przeznaczone na kilka różnych platform jednocześnie, co umożliwia biblioteka Xamarin.Forms. W teorii większość kodu odpowiedzialnego za wygląd i logikę powinna być współdzielona pomiędzy wszystkimi projektami w ramach jednego rozwiązania. Dzięki Xamarin.Forms wygląd aplikacji piszemy w XAML’u, który z kolei jest konwertowany na natywne kontrolki każdej z platform podczas kompilacji. Skoro mowa już o XAML’u, to… tak można zastosować tu wzorzec MVVM 🙂 Należy jednak dodać, że Xamarin.Forms pozwala na współdzielenie kodu na dwa różne sposoby, o czym powiem w dalszej części wpisu.

Które podejście jest lepsze? To wszystko zależy od tego, co właściwie chcemy stworzyć. Jeżeli ma być to aplikacja, która stawia na multiplatformowość i będzie głównie operować na danych (jak na przykład moja ;)) to Xamarin.Forms wydaje się najlepszą opcją. Pozwoli nam bowiem współdzielić jeden kod pomiędzy wszystkimi platformami, co ułatwia konserwację aplikacji, jak i zaoszczędza masę czasu podczas jej pisania. W końcu tworzymy jeden projekt w jednej technologii, a nie trzy w trzech różnych technologiach. Sytuacja ma się inaczej jeżeli nasza aplikacja będzie operować na czymś ściśle związanym z danym systemem operacyjnym (no nie wiem… na przykład apka do tworzenia swap’a dla Androida). Tutaj Xamarin.Forms na niewiele się zda, a wręcz może utrudnić sprawę, bo logikę projektu dla każdego systemu trzeba będzie napisać inaczej – ba może się zdarzyć, że niektórych rzeczy nie da się zrobić na jednym systemie, chociaż drugi na to pozwoli.

Xamarin.Forms PCL vs Shared Project

Tak jak wcześniej wspominałem, Xamarin.Forms pozwala pisać aplikacje cross-platformowe na dwa różne sposoby:

  • Portable Class Library (PCL) – W wolnym tłumaczeniu „Przenośna biblioteka klas”. Jest to moje ulubione podejście do sprawy współdzielenia kodu między wszystkimi platformami. Polega ono na tym, że w ramach jednego rozwiązania tworzone są projekty dla każdego systemu z osobna + jeden projekt przenośny (portable). Do tego projektu wszystkie pozostałe posiadają referencję. Podczas kompilacji kod tego projektu jest kopiowany do wszystkich innych i kompilowany. Z tego też powodu zasób klas, z jakich możemy w nim korzystać jest „ucinany” do najmniejszego wspólnego mianownika wszystkich projektów. To wada tego rozwiązania… jednak chyba jedyna bardziej znacząca. Co to oznacza? Dobrym przykładem może być klasa WebClient, która pozwala na pobieranie plików. Jest ona dostępna zarówno dla platformy iOS, jak i Android, jednak nie dla aplikacji uniwersalnych Windows… w rezultacie nie możemy jej użyć w naszym projekcie przenośnym. Bowiem taki kod po skopiowaniu do projektu UWP, po prostu by nie działał (bo taka klasa dla tej platformy nie istnieje). Po usunięciu projektu UWP z solucji nie będzie z tym problemu. Takich przykładów można by wymienić całą masę, jednak i temu da się zaradzić. W sieci można znaleźć masę bibliotek, które przywracają zagubione funkcjonalności – np. PCL Storage, do obsługi plików. W razie potrzeby możemy też sami stworzyć osobny specyficzny kod/klasę dla każdej z platform, który będziemy wywoływać z projektu głównego. W praktyce wygląda to tak, że w każdym z projektów stworzymy sobie przykładowo klasę Download, z metodą DownloadFile(string url) – przy czym jej wnętrze będzie wyglądało inaczej w przypadku każdej platformy (używamy różnych dostępnych dla platform klas), ale wynik jej działania w każdym przypadku będzie taki sam. Ta z kolei będzie wywoływana z poziomu naszego projektu portable (który pozostanie ładny i przejrzysty). Zresztą… to temat na osobny wpis.
  • Shared Project – To drugi rodzaj podejścia. Pozwala na tworzenie w ramach projektu współdzielonego kodu specyficznego dla każdej z platform przy użyciu bloków tego typu:

    Następnie kompilator kopiuje do każdego projektu kod, który zamknęliśmy w tych blokach. Może takie podejście ma też zalety, ale mi osobiście się nie podoba. Być może sprawdza się przy pisaniu małych projektów, ale w przypadku większych w kodzie zrobi się zwyczajny bałagan… Nie próbowałem nic pisać w ten sposób, więc ciężko mi się w tym temacie jakoś jaśniej wypowiedzieć. Dodać mogę tylko, że obecnie zaleca się jednak korzystanie z opcji numer jeden 😉

Nie ważne, który typ podejścia wybierzesz Xamarin.Forms przypadnie Ci do gustu, jeżeli masz już doświadczenie w pisaniu aplikacji przy użyciu C# i XAML’a. Powodem takiego stanu rzeczy jest fakt, o którym już wspominałem: w Xamarin.Forms’ach layout piszę się w XAML’u – mi osobiście dzięki temu przestawienie się na pisanie layoutu w Forms’ach zajęło raptem godzinę. Natomiast próba ogarnięcia tego, jak pisze się layout w xml’u dla androida… zakończyła się fiaskiem po kilkunastu minutach. Po prostu odechciało mi się, skoro mogę z powodzeniem używać XAML’a, którego dobrze znam i który wydaje mi się bardziej intuicyjny, a do tego pozwala… pisać design na kilka platform jednocześnie. Za to właśnie lubię Xamarina, nigdy nie uczyłem się javy, nigdy nie napisałem nic natywnego na Androida – a z jego pomocą(bez tej wiedzy) mogę pisać aplikacje cross-platformowe. Do tego od czasu, kiedy został przejęty przez Microsoft jest zupełnie darmowy! 🙂

Cóż, na początek chyba tyle wystarczy. W kolejnym wpisie myślę, że zajmę się już kodem. Jak zwykle zachęcam do zgłaszania swoich uwag w komentarzach, nie jestem alfą i omegą, jeżeli czegoś nie dopowiedziałem lub gdzieś się pomyliłem, to będę wdzięczny za wszelkie uwagi. Do zobaczenia!

Jedno przemyślenie nt. „Xamarin Forms okiem początkującego – wprowadzenie

Dodaj komentarz