Artykuł

freeimages.com freeimages.com
cze 28 2016
0

Xamarin - wprowadzenie teoretyczne

Xamarin nie jest gwarantem trzykrotnie szybszego developmentu. Nie zachodzi tutaj żadna równość typu, że niezależnie ile platform docelowych będziemy chcieli obsłużyć, to w praktyce i tak piszemy jedną aplikację. Xamarin tak nie działa. Nawet w sytuacji gdy korzystamy z Formsów to i tak nie jesteśmy w stanie skrócić developmentu na inne platformy do zera. Na ten temat szerzej pisałem we wpisie w ubiegłym tygodniu.

Czy zatem warto się w ogóle zainteresować tą technologią? Czy oferuje ona jakieś sensowne benefity? Na jakim systemie możemy programować? Jak to wszystko w praktyce działa? Na te i inne odpowiedzi postaram się odpowiedzieć w dzisiejszym tekście, który jest swego rodzaju wprowadzeniem do tej technologii na łamach mojego bloga.

Czy warto?

Na początku warto się w ogóle zastanowić - czy gra jest warta świeczki? Tak naprawdę odpowiedź na to pytanie jest złożona i wielu przypadkach zależy od Was samych oraz od sytuacji w której się znajdujecie zawodowo. Poniżej lista kilku punktów, którą mogą być argumentem za tą technologią:

  • Xamarin bazowo unifikuje przede wszystkim backendową część aplikacji. Jeśli tworzysz aplikacje z rozbudowaną logiką biznesową, to warto ją pisać tylko raz. Xamarin na pewno w tym pomoże
  • Jeśli layout aplikacji opiera się o standardowe elementy i wzorce, to warto pokusić się o użycie Xamarin.Forms, który obsługuje kilkadziesiąt kontrolek, które później mapowane są na natywne rozwiązania
  • Jeśli martwi Cię konieczność posiadania osobnego zestawu programistów na każdą platformę, to również warto dać szansę Xamarinowi. Nawet podejście native można w całości ograć w języku C#. Xamarin mapuje 100% API z Androida oraz iOS
  • Jeśli lubisz C# tak jak ja, to z pewnością ucieszy Cię fakt, że za pomocą tego języka będziesz w stanie utworzyć aplikacje na wszystkie liczące się platformy
  • Nawet jeśli znasz rozwiązania natywne, wciąż możesz poczuć się jak w domu, używając Xamarina. Dla przykładu, w Androidzie wciąż można używać Activity, kod layoutu pisać w plikach AXML, a aplikację konfigurować w Manifeście. Jednocześnie przy okazji łatwo jest napisać kawał kodu, który można użyć na dowolnej inne platformie. Bajka? Niekoniecznie. Xamarin
  • Jeśli pracowałeś z jakąkolwiek technologią operującą na XAMLu (WPF, Silverlight, Universal Apps, UWP), to również w tej sytuacji nie powinieneś mieć problemów by się odnaleźć w temacie
  • Pod Xamarina można programować w Visual Studio [Community] dla Windows lub Xamarin Studio dla OS X
  • Kod źródłowy całego rozwiązania dostępny jest na GitHubie!

Oczywiście Xamarin nie jest idealny. Są też minusy:

  • Podejście Forms zazwyczaj nie pozwala na napisanie całej aplikacji. Część kodu i tak musi być pisania z użyciem dedykowanych konstrukcji warunkowych, a w przypadku złożonych interfejsów, może to być większa część kodu
  • Do pracy z Xamarinem wymagana jest również przynajmniej bazowa znajomość C#. W podejściu Xamarin.Forms, trzeba się również nauczyć XAMLa.
  • Ponadto przy wydaniu każdej nowej wersji wspieranych systemów, musimy czekać na wrappery. Oczywiście w chwili obecnej pojawiają się one praktycznie natychmiast, ale pytanie czy tak będzie zawsze?
  • Xamarin bywa również niestabilny. Zdarzają się wersje lepsze i gorsze. Czasami pojawiają się problemy w sytuacji gdy odpalamy solucję przygotowaną w Visual Studio na Macu i odwrotnie. Zdarzają się również inne błędy.
  • Ta technologia ma jeszcze jedno ryzyko. Obecnie jej właścicielem jest Microsoft, który czasem bywa nieprzewidywalny. Na szczęście tak jak pisałem wcześniej kod źródłowy Xamarina jest otwarty i można go znaleźć na GitHubie

U mnie plusy przeważyły nad minusami. A jak jest u Was?

Xamarin Platform

Projekt Xamarin rozpoczął się od tzw. Xamarin Platform, który funkcjonuje obecnie dla Androida, iOS oraz Maca. Dzięki temu rozwiązaniu, możemy pisać programy na wszystkie te systemy z wykorzystaniem języka C#. Z wiadomych względów brakuje tutaj rozwiązań Microsoftu, ponieważ one domyślnie wykorzystują C#, więc nie jako są już na miejscu.

Xamarin Platform nazywany jest również często podejściem Native (w sieci znajdziecie porównania Xamarin Native vs Xamarin Forms), ponieważ dla Androida oraz iOS ma 100% odzwierciedlenie API tych systemów. Wykorzystując Xamarin.Android możecie tworzyć Activity dokładnie tak samo jak robilibyście to Javie z tym, że należy tutaj uwzględnić syntax z C#. Poniżej przykład deklaracji metody onCreate w Javie:

@Override
protected void onCreate(Bundle savedInstanceState) {
    // 
}

A teraz analogiczna metoda z Xamarin.Android w C#

protected override void OnCreate (Bundle bundle)
{
    //
}

Zapewniam, że kod w środku może wyglądać również bardzo podobnie. W Xamarin.Android również możemy tworzyć pliki layout AXML. Zapewniam, że w przypadku Xamarin.iOS sytuacja wygląda bardzo podobnie.

Spójrzcie również na grafikę ze strony Xamarina:

Ukazuje ona dwie niezaprzeczalne zalety Xamarina i tego podejścia. Po pierwsze - wszędzie mamy C# , po drugie - możemy współdzielić kod logiki biznesowej pomiędzy wszystkimi platformami za pomocą bibliotek portable lub projektów współdzielonych (shared).

Oczywiście należy pamiętać, że wykorzystując biblioteki Portable, powinniśmy ograniczyć ich docelowy zakres do absolutnego minimum. Im więcej technologi na raz będziemy chcieli obsłużyć, tym mniejszy zakres interfejsów będzie dostępny. W ciekawy sposób zostało to zaprezentowane na grafice, która pierwotnie pojawiła się na blogu Hanselmana przy okazji wpisu o ASP.NET Core 1.0 RC2 i uwzględnia tzw. .Net Standard.

Więcej o tym rozwiązaniu możecie przeczytać na oficjalnej stronie.

Xamarin.Forms

Xamarin.Forms jest stosunkowo nowym podejściem do tworzenia aplikacji mobilnych, ponieważ zostało ono wprowadzone w roku 2014 i jest cały czas udoskonalane. Istotnym nowum tego podejścia jest umożliwienie tworzenia wspólnego interfejsu dla kilku różnych platform. W obecnej wersji wspierane są następujące rozwiązania:

  • Android
  • iOS
  • Windows Phone 8.1
  • Windows 8.1
  • Windows UWP

W idealnym przypadku aplikacja typu Xamarin.Forms, może współdzielić nawet ponad 95% kodu. Taki współczynnik udało się uzyskać m.in. w aplikacji CRM.

Przy podejściu Forms, wciąż możemy korzystać z ogólnych zalet/rozwiązań Xamarina i jednocześnie możemy spróbować zunifikować nasz interfejs.

Kod Formsów pisany jest w znanym i lubianym XAMLu. Oczywiście na potrzeby Xamarina powstała jego specjalna implementacja. Na zapotrzebowanie deweloperów zostało przygotowanych ponad 20 kontrolek, które w zależności od platformy docelowej, zostają zmapowane na kontrolki używane w danym systemie. Poniższy obrazek ze strony oficjalnej dobrze pokazuje o co tu chodzi:

Oczywiście z przyczyn technicznych, Formsy oferują tylko podstawowy zestaw kontrolek. Wybrano powszechne kontrolki oraz takie, które mają swój odpowiednik na każdym systemów. Dlatego też jeśli będziecie chcieli zrobić np. odtwarzacz video, to będziecie musieli skorzystać z kodów w wersji native. Na szczęście oba podejścia można swobodnie mieszać.

Ze względu na ograniczony zestaw kontrolek, Xamarin.Forms sprawdzi się dobrze w aplikacjach, które nie sięgają zbyt głęboko do natywnych rozwiązań graficznych określonych systemów.

Więcej na temat tego rozwiązania, możecie przeczytać na stronie oficjalnej projektu.

Oprogramowanie

Z Xamarina korzystać można zarówno na Windowsie, jak również na OS X. Jednak w kontekście budowania aplikacji zachodzą pewne zależności. Rozwiązania Microsoftu można budować tylko i wyłącznie w systemie Windows, Android może być budowany wszędzie, natomiast iOS budowany jest na Macu (wykorzystanie XCode), ale można to robić w sieci lokalnej również z poziomu Windows. Poniższa tabelka prezentuje spektrum naszych możliwości:

System/IDE Android iOS Windows Phone 8.1 Windows 8.1 Windows 10 UWP
Windows (Visual Studio) Tak Tak - przez MacAgenta Tak Tak Tak
OS X (Xamarin Studio) Tak Tak Nie Nie Nie

Do odpalania emulatorów wymagane jest wsparcie dla wirtualizacji. W przypadku Windows w większości przypadków konieczne jest użycie Hyper-V - w związku z tym automatycznie niezbędny staje się Windows w wersji 8+ Pro. Obecnie najlepszą opcją będzie Windows 10 Pro, który oferuje pełne wsparcie dla UWP i jednocześnie wspiera Universal Apps.

W każdym bądź razie, by ogarnąć wszystkie dostępne opcje, potrzebny będzie Windows i OS X. By ogarnąć iOS, zawsze potrzebny będzie system od Apple. W pozostałych przypadkach wystarczą okienka.

Podsumowanie

Mam nadzieję, że dzisiejszy mój tekst trochę Wam rozjaśnił o co w tym Xamarinie naprawdę chodzi. Celowo pominąłem tutaj tak niskopoziomowe kwestie jak sam proces budowania. Na ten moment wystarczy wspomnieć, że wszystko co piszemy w C#, ma swoje odzwierciedlenie w natywnym kodzie. Przy budowaniu Androida wykorzystujemy standardowe SDK zielonego robota. Podobnie sprawa wygląda przy iOS. Koniec końców, finalny build odbywa się tam przez XCode (dla zainteresowanych - zachęcam do przeczytania tekstów Under the hood dla interesującej Was platformy).

Wracając do głównego wątku. Xamarin z pewnością ma sporo wad, ale w moim odczuciu liczba zalet mocno przewyższa te negatywne aspekty tego rozwiązania (raz jeszcze odsyłam do akapitu Czy warto?). Do plusów w ostatnim czasie doszły trzy istotne rzeczy:

  • Xamarin rozwijany jest od teraz przez Microsoft
  • Kod źródłowy rozwiązania jest otwarty
  • Rozwiązanie jest dostępne za darmo

Wszystko to powyższe sprawia, że naprawdę warto jest dać szansę temu rozwiązaniu - co też sam zamierzam uczynić w najbliższych tygodniach ;-)

Podoba Ci się ten wpis? Powiedz o tym innym!

Send to Kindle

Komentarze

blog comments powered by Disqus