Maui, śmierć Xamarin'a ?

Xamarin został przejęty przez Microsoft już 4 lata temu. To naprawdę szmat czasu. To na tyle długo, że wydaje się, iż tak było zawsze. Na początku Microsoft trzymał tempo rozwoju Xamarina zarówno dla Xamarin.Native jak i dla Xamarin.Forms. Przez ostatnie około dwa lata wydaje się, że rozwijany jest tylko Xamarin.Forms. Powstało dużo udogodnień choćby Xamarin Shell.

Najwięcej jednak dzieje się w narzędziach dookoła Xamarin.Formsów. Visual Studio for Mac, emulatory, Hot Reload, Hot Restart, praca z iOS aplikacjami bez macOS i bez provisioningów.

 

Microsoft znany jest z uśmiercania technologii. A tym bardziej swoich produktów, ja nadal tęsknie za moją piękną Lumią z kafelkowym systemem. Ale czy Xamarin podzieli ten los?

Krótka odpowiedz brzmi NIE. 

Długa wersja mówi o ewolucji. Maui is Xamarin Evolve, jeśli chwytacie dowcip 😂

 

Dlaczego zmiana jest konieczna

We wczesnych latach Xamarin pozwalał na używanie C# do programowania aplikacji mobilnych. Natywnych aplikacji mobilnych, w natywny sposób. Widoki axml dla Androida oraz nib a później storyboards dla iOS. Architektonicznie mieliśmy więc tutaj głównie MVC. MVVM Cross okazał się strzałem w 10 dla ujednolicenia jeszcze większej ilości kodu i nieprzejmowaniem się bindingiem (nie znam polskiego odpowiednika tego słowa). Xamarin.Forms dał nam dodatkowo oprócz MVVM również współdzielone widoki, jeden sposób zapisu definicji widoku za pomocą znanego i lubianego XAML'a

Zmiana z MVC na MVVM dała naprawdę dużego kopa tej technologii. Ba w międzyczasie świat odkrył, że MVVM to nawet spoko wzorzec projektowy i warto go używać. A potem go odwrócił i zmienił dla swoich potrzeb, ale to historia na inny blog post.

Teraz jednak MVVM nie zawsze wystarcza, zwłaszcza gdy stajemy przed pytaniem PUSH czy PULL.

 

Reaktywne programowanie

Flux, Redux i zarządzanie stanem/ zmianą stanu.

MVVM jest świetne przy dużej liczbie bindingów, przy formach do wypełnienia, przy danych do wyświetlenia, gdy je pobieramy. Jednak słabo się sprawdza przy aberacjach MVVMa które zaczęły się pojawiać, polegających na reagowaniu na zmianę. Potrzeba trochę rozwinięcia mojej myśli chodzi o sposób traktowania Modelu vs ViewModelu i pobierania zmian niezależnie odwymagań widoku. Tutaj jest znacznie lepiej odwołać się do Facebookowego systemu powiadomień. Redux, potem Flux i inne systemy zarządzania stanem, oraz powiadamianiu o zmianie stanu na przestrzeni całej aplikacji nie tylko widoku zyskały dużą popularność. Ma to sens w coraz bardziej połączonym świecie natychmiastowych notyfikacji. Takie rozwiązanie sprawdza się w wielu przypadkach. 

 

Nadążanie za światem

Xamarin zyskiwał możliwość korzystania z wszystkich tych wzorców projektowych, ale nie były one wpisane w jego architekture. Pisanie kontrolek i bibliotek nie było łatwe.  

W międzyczasie pojawiły się nowe silne frameworki wspierane przez wielkich, czyli Facebooka i Googla. Jedną z zalet tych frameworków jest duża społeczność wokół nich. Inna zaletą są narzędzia, czy to webowe, czy mobilne jak Hot Reload.

 

React Native  - jego ogromną siłą jest jednolitość z frameworkiem webowym, oraz reaktywne wzorce. Framework webowy ma też możliwość stania się aplikacją desktopową. Wszystko w jednym języku i to jeszcze bardzo rozpowszechnionym  czyli JavaScript.

 

Dalej pojawił się Flutter.

Wprawdzie google też ma tendencję do uśmiercania swoich technologii, jednak wydaje się, że Flutter ma przed sobą świetlaną przyszłość. Ogromną zaletą jest wykorzystywanie grafiki do generowania obrazu i częściowe odświeżanie tylko elementów zmienionych. Dzięki temu ten framework jest bardzo szybki w renderowaniu widoków. I ponownie uniwersalność - Flutter również daje możliwość pisania aplikacji webowych, w planie również desktopowych oraz ma być głównym językiem dla nowego systemu operacyjnego od Googla o którym mówi się już od lat - Fuksja 

 

Blazor

W świecie stało się jeszcze jedno.

Pojawiło się WebAssembly. Teoretycznie to technologia webowa, więc nie powinna mieć wpływu na świat mobile. Jednak WebAssembly w połączeniu z Progressive Web Apps zmienia również świat aplikacji mobilnych oraz desktopowych. Największą zmianą jest wykorzystanie WebAssembly i powstanie się Blazora. Blazor z jednego demo stał się po dwóch latach produktem gotowym do użycia. To pełny ekosystem, web servier-side, web client-side, wszystko oparte na .NET. Blazor wykorzystywał Mono jako runtime, teraz Mono jest już częścią .NETa. Do tego Blazor mobile powoli również się rozwija. Blazor Progresive Web Apps to również możliwość stworzenia aplikacji desktopowej praktycznie zerowym kosztem, potrzebujemy tylko tryb offline i jeden checkbox.  Blazor bindings czyli wersja mobilna wykorzystuje podspodem Xamarin.Forms. Jest to absolutnie zrozumiałe, wystarczy dopisać inne renderery i mamy gotową platformę. Problem w tym, że mamy trochę inne wzorce projektowe co utrudnia pisanie rendererów. 

 

Ewolucja

Dużo się zmieniło przez ostatnie 4 lata i w świecie i w Xamarinie.

Pora się rozwijać dalej. 

Nie chodzi o to aby zabić kolejną technologię. Raczej o pójście o krok dalej. Inne metody renderowania, inne wzorce projektowe, inne platformy. Ogólnie otwartość na zmiany. Otwartość na mnogość możliwości. Tym bardziej teraz gdy .NET jest tak bardzo rozpowszechniony i uniwersalny. Nowe wyzwania pojawiają się już teraz jak z Blazorem i te które będą pojawiać się dalej. Ewolucja jest nieunikniona i właśnie się rozpoczęła. I to dobrze.

 MAUI: Multi-platform App UI

Jak zwykle Microsoft nie ułatwia życia wyszukiwaniu informacji, ponieważ Maui to druga co do wielkości wyspa na Hawajach.

MAUI to ewolucja Xamarin.Forms. Maui pojawi się wraz z .NET 6 i jest zmianą nazwy. Wynika to głównie z filozofi "One .NET"

Maui będzie miało zmienioną architekturę wewnętrzną oraz nowe możliwości. Przez kolejne dwa lata Xamarin.Froms będzie rozwijany równolegle z Maui, dopiero gdy zostaną połączone Xamarin.Forms w ostatniej jego wersji przejdzie w fazę utrzymania i wygaszania brancha. Jednak migracja będzie tylko zmianą namespaców.

Czy warto teraz zaczynać projekt w Xamarin?

W Xamarin.Forms: TAK.

W Xamarin.Native, jak bardzo kocham właśnie tą formę Xamarina, teraz bym się zastanowiła. Xamarin nadal udostępnia dostęp do najnowszych SDK i będzie to robił nadal, ale jak spojrzymy na roadmapę do wersji 5 to główne siły idą na Xamarin.Forms a drugą ścieżką na Maui.

Xamarin czy Flutter czy React Native?

Tutaj odpowiedź powinna brzmieć MAUI.

MAUI będzie odpowiedzią na Fluttera i myślę że React Native również. Ale to dopiero w listopadzie 2021, a to trochę daleko. Więc tutaj opowiedź powinna pasować do długoterminowych planów projektu.

PS: 

To moja opinia. Następnym razem opowiem trochę o mięchu Maui, tak aby wiedzieć czego się spodziewać.