flutter compose

Unifikacja języka UI w aplikacjach mobilnych na przykładzie Jetpack Compose & Flutter

Częścią pracy każdego programisty jest wybór technologii, w których chcielibyśmy się rozwijać. Technologie mobilne, jak i same urządzenia – telefony i tablety, mimo upływu dekady od powstania pierwszego iPhone’a, ciągle rozwijają się w szalonym wręcz tempie. To samo dotyczy języków, których używa się do pisania na nie oprogramowania. Czym powinniśmy kierować się przy wyborze ścieżki naszej kariery jako programiści mobilni? Statystykami, wieszczeniem wróżki Vanessy czy własnym przeczuciem?

Bartosz Kosarzycki

Skłaniałbym się ku rzeczowej analizie rynkowych trendów. Jednym z takich trendów jest zmiana języków definicji UI, rozpoczęta wśród programistów iOS, kontynuowana w React Native i Fluterze i dopełniona w Androidzie pod postacią Jetpack Compose. 

Źródło grafiki 

Początki powrotu do code-first approach

W czasach objective-C interfejsy aplikacji iOS definiowaliśmy w plikach *.xib/*.storyboard pod postacią długich, małoczytelnych dokumentów xml. Sytuacja wyglądała tutaj dużo gorzej niż na konkurencyjnym Androidzie, który mimo użycia równie rozwlekłego formatu, kontrolki zapisywał w logicznym porządku, gdzie id nie były generowane losowo, a nazywane przez programistę. W dłuższej perspektywie okazało się to zbawienne dla utrzymania spójności i unikania konfliktów podczas mergowania kodu inżynierów pracujących nad tym samym modułem.

Źródło kodu 

Programiści iOS skłonili się więc ku SwiftUI, który oferował ucieczkę od problematycznego formatu *.xib, a jednocześnie pozwalał na:

  1. definicję UI bezpośrednio w kodzie – tym samym na nawigację do kodu kontrolek i łatwego czytania dokumentacji, która się tam znajduje,
  2. łatwe użycie funkcji zdefiniowanych w innych miejscach kodu (np. do formatowania, czy walidacji), a nawet zawarcie tam prostej logiki (UWAGA: mieszanie kodu UI i logiki biznesowej jest anty-patternem i nigdy tego nie rób jeżeli nie masz konkretnego powodu).

Oczywiście definicja UI z poziomu kodu ma też swoje wady, o czym później.

kod źródłowy apple swift

Źródło grafiki

Ciekawym aspektem jest fakt, że SwiftUI, czy szerzej definiowanie interfejsu użytkownika z poziomu kodu aplikacji jest tak naprawdę powrotem do korzeni informatyki. Dużym osiągnięciem było rozdzielenie zapisu kształtu UI do osobnych plików – najpierw poprzez pliki *.xml, a następnie poprzez wprowadzenia bindingów i dwustronnych data-bindingów. Ułatwiało to początkującym programistom utrzymanie porządku w architekturze aplikacji i klarowne rozdzielenie logiki biznesowej – zarówno w architekturze MVP, jak i MVVM. 

Flutter – mocny gracz wkracza do akcji już na starcie rozgrywając React-Native

Flutter odbił się niemałym echem w świecie mobilnego multiplatform. Jest on zupełnie nowym podejściem – między innymi po Xamarinie, którego największą bolączką było wrapowanie androidowych kontrolek, zmuszające twórców do pogoni za każdą kolejną wersją platformy i z góry skazanym na porażkę. Co ciekawe Flutter już przy swoim starcie rozwiązał także bolączkę React-native – niewydajnego drzewa DOM, nawigacji na Androidzie i opóźnień w odświeżeniu UI przy dużym obciążeniu. Interfejs zbudowany na silniku Chrome – Blink – pozwala na stałe utrzymywanie 60 klatek/s, aplikacje nie dławią się, a my mamy dostęp do całej palety przepięknych animacji.

Omawiany framework, podejście code-first w UI ma wbudowane od samego startu, a interfejsy definiowane w Darcie, wyglądają następująco:

Źródło kodu

Musicie przyznać, że mamy tu analogię do wspomnianego wcześniej SwiftUI.

Ostatni gracz na rynku – Jetpack compose

Jetpack compose, od niedawna w wersji stabilnej, pojawił się jako ostatni. Zamyka on cykl przejścia do nowego sposobu definiowania UI z poziomu kodu we wszystkich wiodących platformach mobilnych i jasno pokazuje czego możemy spodziewać się w najbliższy dwóch latach. 

Kotlin jest zdecydowanie najpotężniejszym z wymienionych tutaj języków – w związku z czym sam Jetpack Compose ma także najwięcej możliwości – nie tylko rozszerzania, ale swobodnej ingerencji w zachowanie UI. 

W przeciwności do SwiftUI – Jetpack Compose pretenduje też do bycia multiplatformowym frameworkiem definiowania interfejsów… a co z tego wyjdzie – zobaczymy. Statystyki użycia jasno pokazują, że na razie rynkowo nie udało mu się wyjść poza świat Androida. 

comsable

Źródło kodu

Jetpack-compose vs. Flutter

Spójrzmy na prosty ekran logowania napisany w Jetpack Compose i Flutter. Od razu rzucają się nam w oczy ewidentne podobieństwa:

  • w obu rozwiązaniach definiujemy widgety, które odświeżają stan, 
  • w obu rozwiązaniach mamy wiersze/kolumny zamiast typowych LinearLayout, czy ConstraintLayout,
  • w obu rozwiązaniach możemy stosować flex znany ze świata webowego,
  • oczywiście oba rozwiązania korzystają z natywnego języka Kotlin/Dart, a więc możemy korzystać z funkcji/zaawansowanych rozwiązań bezpośrednio w kodzie UI.

Jetpack Compose:

Źródło kodu 

Flutter:

Fluttera i Jetpack Compose pisały zupełnie inne zespoły programistów – widać jednak próby unifikacji podejść. Kod UI nie różni się znacząco od SwiftUI. Jak na razie nie jest możliwe bezpośrednie kopiowanie fragmentów UI pomiędzy Flutterem, a Jetpack Compose, ale może w przyszłości będzie? 

flutter jetpack

Źródło kodu

Pomyślmy jak korzystna z punktu widzenia biznesu byłaba możliwość swobodnego wyboru pomiędzy Jetpack Compose, a Flutterem, czy więcej – zamiana implementacji UI według aktualnych potrzeb – skupienia się na funkcjonalności natywnej [Kotlin] lub wybór oszczędności wynikającej z cross-platformowego podejścia [Flutter]. 

Co więcej, prototyp UI napisany we Flutterze można by swobodnie wykorzystać do natywnej aplikacji kotlinowej z Composem i na odwrót. 

Osadzanie modułów flutterowych wewnątrz aplikacji natywnych również stałoby się łatwiejsze.

Czy ja już tego gdzieś nie widziałem?

Dla starych wyjadaczy informatyki, definiowanie UI z poziomu kodu nie jest niczym nowym. W zasadzie to powrót do lat 2000, czy nawet początku 90-tych. Dlaczego wtedy od niego odchodziliśmy, a teraz, po 20 latach nagle wracamy?

Nadmienię tylko, że mieszanie definicji UI z kodem biznesowym jest niebezpieczną praktyką, a prowadzenie projektu z Jetpack Compose wymaga od programistów dużo samodyscypliny, jak również wnikliwych PR review – w przeciwnym razie nasza aplikacja skończy na śmietniku historii jako spaghetti.

spaghetti code

Źródło grafiki

Podsumowanie

W tym artykule przyjrzeliśmy się obecnie panującym trendom w dziedzinie definicji UI w świecie mobilnym. Przechodząc przez 3 platformy – Android, iOS, Flutter – widzimy na wszystkich z nich tę samą tendencję odejścia od xmli i przejścia ku definicji UI z poziomu kodu. Mamy więc pewność, że trend ten utrzyma się w najbliższych miesiącach, czy nawet latach. 

Ciekawym smaczkiem jest fakt, że całkiem możliwa jest jeszcze większa unifikacja definicji UI i wisząca w powietrzu nadzieja na łatwe współdzielenie kodu UI pomiędzy platformami. Odpowiadając na pytanie zawarte w pierwszym akapicie: tak, jak najbardziej powinniście uczyć się SwiftUI, Jetpack Compose i Fluttera, ponieważ zostaną one z nami na dłużej.

teleturniej programista100k

Zdjęcie główne artykułu pochodzi z unsplash.com.

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
Branża IT wspiera NGO i szpitale w walce z COVID-19