[TechOT] Xamarin.Forms

W tygodniu kończymy z kolegami pisanie aplikacji mobilnej w Xamarin i postanowiłem napisać trochę przemyśleń.

 

Dlaczego Xamarin Forms?


Jesteśmy w większości .NET’owcami. Na tym można byłoby skończyć argumentację, ale jest więcej. Aplikacja z założenia miała powstać na trzy systemy: Android, iOS i Windows Phone. Z tego ostatniego ostatecznie zrezygnowaliśmy, ale mimo wszystko pisanie dwóch oddzielnych aplikacji robiących zupełnie to samo nie było zachęcające. Dodatkowo w objectiveC/Swift pisaliśmy tyle co nic, bo jedną aplikację na zaliczenie przedmiotu. Dla większości z nas do Javy też daleko. Padł pomysł również z Cordovą, która wygląda fajnie, ale znowu, z javascriptem u nas słabo, a aplikacja miała powstać, a nie powstawać w nieskończoność. Padło więc na Xamarin.Forms. Entuzjazm był spory, bo to w końcu .NET więc co może pójść źle.

 

 

Pozytywy


Pozytywy są oczywiste. Jeden kod na wiele aplikacji oraz C#. Teoretycznie zaletą jest też XAML, ale o tym może nieco później. I to faktycznie działa. Piszemy w ukochanym C#, nie ma z tym większego problemu. Z tym kodem, który pisałem ja(a mało go pisałem z pewnych względów), nie miałem przygód, wszystko co chciałem to działało.

Aplikacja iOS również działa, mimo, że nie zwracaliśmy na nią w ogóle uwagi. Był jedynie jakiś problem z Google Maps, ale całkiem szybko został rozwiązany. 

Nie ma co się rozpisywać. Pod względem kodu jest dobrze.

 

Wady


XAML

Może łagodnie zacznijmy od XAML’a. Jest od bardzo podobny do tego z np. WPF. Nie jest jednak identyczny. Trochę to irytuje, bo niektóre elementy nazywają się inaczej. Przykładowo w Xamarinie jest StackLayout, a w WPF StackPanel. Inny przykład: nie każde kontrolki posiadają właściwość “padding”. A w zasadzie żadna. Wszystko, co chcemy żeby miało paddingi musimy opakować w element grupujący inne elementy, np. StackLayout albo ContentView. Powoduje to, że każdy przycisk czy label(label, a nie textblock) jest opakowany, przez co kod nie wygląda zbyt ładnie.

 

Xamarin Studio

Aplikację pisałem w Xamarin Studio na macOS. Nie instalowałem Xamarina na Windowsie, gdyż zajmuje on strasznie dużo miejsca (25GB minimum) a mój SSD jest na to zbyt mały 😉 Pierwsze co rzuca się w oczy: Xamarin Studio oraz Visual Studio for mac to dokładnie to samo. Dlaczego więc zainstalowałem w ogóle Xamarin Studio mając już wcześniej VS? Po pierwsze, myślałem, że może błędy jakie miałem początkowo po pobraniu repozytorium są winą VS będącego jeszcze w becie. Po drugie, miałem nadzieję na coś bardziej dostosowanego do Xamarina. Niestety ani jedno ani drugie nie miało miejsca.

Podpowiedzi w XAML’u działają FATALNIE. Można wręcz powiedzieć, że ich prawie nie ma. Pisanie XAML’a ręcznie nie należy do przyjemnych, szczególnie ze zmienionym nazewnictwem. Dodatkowo przez Realm nie posiadałem podglądu na żywo, przez co każdą zmianę musiałem wgrywać na telefon aby zobaczyć rezultat. Koszmar. Jeżeli chodzi o kod to nie jest lepiej. Podpowiedzi są, dopóki wpisujemy idealnie nazwę metody/zmiennej/etc. Jak tylko coś przekręcimy to już nie mamy nic, a żeby ponownie zobaczyć podpowiedzi musimy zacząć pisać wszystko od nowa.

Z całego serca nie polecam Xamarin Studio na macOS, chyba, że istnieje jakiś sensowny plugin.

Jeszcze taki mały tip: jak Wam coś nie działa w projekcie a jeszcze niedawno działało/ powinno działać po pobraniu repozytorium, zróbcie clean projektu. Jak nie zadziała, to jeszcze ze dwa razy. Zazwyczaj pomaga 😉

 

Wygląd

Kolejnym rozczarowaniem było brak łatwej możliwości projektowania aplikacji pod Material Design. Nawet zrobienie flat buttona jest nie lada wyzwaniem. Przykłady można mnożyć, ogólnie nie jest różowo.

Po części przyczyną jest to, że są to Formsy a nie natywna aplikacja Android. Są tu jedynie elementy, które znajdują się na wszystkich platformach. Powoduje to jednak często spore wyzwanie żeby zaprojektować coś sensownego.

 

Wnioski

Główny wniosek jest taki, że nie taki Xamarin piękny jakim go malują. Szczerze mówiąc, jakbym teraz miał decydować o wyborze technologii, prawdopodobnie byłbym za pisaniem natywnych aplikacji w Javie i objectiveC/Swift. Pracy byłoby więcej, ale po napisaniu jednej aplikacji druga tworzy się już o wiele szybciej. No a jednak byłoby o wiele ładniej.

Zobaczymy co przyniesie przyszłość pod znakiem przystosowaniem wersji iOS do rozsądnego stanu. Prawdopodobnie jeszcze o tym napiszę.

 


A na dzisiaj to tyle, dzięki za odwiedziny.

Do zobaczenia, cześć!

3 komentarzy

  1. Xamarin.Forms nie jest technologią do każdego projektu 🙂 Bardzo możliwe, że akurat w tym konkretnym przypadku nie był to trafiony wybór jak piszesz, ale nie przekreślałbym całkowicie tej technologii. Moim zdaniem Xamarin.Forms sprawdza się świetnie w przypadku aplikacji biznesowych gdzie mamy do napisania sporo logiki – pisanie takiej masy kodu na każdą z platform oddzielnie to po prostu strata czasu i pieniędzy. Więcej przypadków kiedy warto użyć Xamarina zamieściłem na swoim blogu: https://blog.damianantonowicz.pl/2017/03/24/xamarin-jak-sie-do-tego-zabrac-w-2017/

    1. Jak najbardziej się zgadzam. W naszej aplikacji jednak logiki było tyle co kot napłakał więc tych zalet Xamarina nie mogliśmy aż tak bardzo odczuć. Na pewno nie skreślam Xamarina, jednak następnym razem dwa razy się zastanowię czy na pewno jest on wskazany 😉

  2. Według mnie większość z tych wad, które wymieniłeś wynika bardziej z tego, że napisałeś pierwszy (bądź jeden z pierwszych) projekt w tej technologii, możliwe, że popełniłeś kilka błędów, o których teraz wiesz oraz zdałeś sobie sprawę z tego, jak wygląda proces tworzenia aplikacji w Xamarinie, a podczas pisania próbowałeś odnieść się do wiedzy z WPF, która to technologia jest zupełnie inna i to, że w obu występuje XAML nie oznacza, że te elementy interfejsu mają być identyczne – w końcu Xamarin jest pisany z myślą o programistach mobilnych i starali się tam dodać takie elemnty interfejsu, które są bliskie tym z Androida czy iOS, a nie WPF. Natomiast podpisuje się pod tym, że Xamarin Studio nie jest czymś wartym opuszczenia VS, pisanie ręcznie XAMLa może być uciążliwe, podobno ciągle trwają prace nad designerem, niestety u mnie on nie działa, więc nie mogę nic pozytywnego o nim powiedzieć. Problem z brakiem niektórych elementów platform w Xamarinie nie jest akurat jego specyficzną wadą, a czymś, co występuje w każdym frameworku, który ma za zadanie wrappowanie natywnych funkcjonalności – zawsze trafi się coś, czego nie ma i wtedy dodanie tego zajmuje dużo czasu. Według mnie o wiele większym problemem Xamarina jest ilość błędów, które ciągle są w Xamarinie przez jego szybki rozwój i które mogą się objawić pod koniec pisania projektu. Xamarin nie jest świętym Graalem, który da sobie rade w każdych warunkach, ale z tak negatywną oceną powinieneś się jeszcze wstrzymać i stworzyć w nim więcej projektów, mimo że kilka argumentów przeciw Xamarinowi jest słusznych.

Dodaj komentarz