Wady i zalety Compose w aplikacjach eCommerce. Kiedy warto korzystać z tej technologii?
Zmiana to jedna z niewielu pewnych rzeczy w programowaniu. Nieustannie mamy do czynienia z nowymi technologiami, które obiecują łatwiejsze rozwiązywanie problemów, krótszy czas rozwoju aplikacji czy automatyzację zadań.
Pojawienie się deklaratywnych rozwiązań do tworzenia UI wywołało dość dużo zamieszania na rynku mobilnym. Flutter, SwiftUI i Jetpack Compose szybko zyskały sobie zwolenników, choć nie brakuje też sceptycznych opinii. Skąd to poruszenie?
Podejście imperatywne vs deklaratywne – różnice
Na wstępie warto zrozumieć różnicę pomiędzy klasycznym sposobem budowania widoków (przez pliki XML na Androidzie czy XIB na iOS) a rozwiązaniami oferowanymi przez Compose czy SwiftUI.
Podejście imperatywne
Widoki w XML/XIB służą do budowy aplikacji w podejściu imperatywnym. Komponenty i ekrany są modelowane przy pomocy definicji, które znajdują się w plikach tekstowych.
Do stworzenia widoków w uruchomionej aplikacji wykorzystujemy pliki z definicjami pożądanych elementów. Z poziomu kodu możemy następnie wywoływać metody , które modyfikują te elementy widoku – ustawiając na nich konkretne wartości czy przypisując im odpowiednie funkcje.
Upraszczając, tworzymy pusty widok z przypisaną ograniczoną liczbą parametrów. Następnie modyfikujemy go przy pomocy odpowiednich funkcji i danych, które chcemy wyświetlić. Jest to klasyczne podejście wykorzystywane jeszcze w czasach poprzedzających erę aplikacji mobilnych. Między innymi w środowiskach .NET (przez pliki XML/XAML) i Java (np. framework Swing).
Podejście deklaratywne
Jetpack Compose i SwiftUI reprezentują inne spojrzenie na ten sam problem – podejście deklaratywne. W tym przypadku to dostarczone dane definiują, w jaki sposób widok ma być zbudowany i jakie komponenty należy wykorzystać.
Programista określa w kodzie stan widoku oraz komponenty, które będą go obsługiwać. Każda zmiana tego stanu powoduje odświeżenie interfejsu i – jeżeli to konieczne – zmianę/przebudowę komponentów. Te same zasady stosuje również Flutter.
Podejście deklaratywne spopularyzowało się wraz z rozwojem webowego frameworka React, który sprawnie wykorzystał niektóre z jego mechanizmów. Na platformach mobilnych jest to jednak rozwiązanie stosunkowo nowe. To dlatego zdecydowana większość aplikacji dalej korzysta z podejścia imperatywnego.
Co możemy zyskać dzięki Jetpack Compose?
Łatwiejsze budowanie i animowanie widoków
Ze względu na zmianę podejścia do budowania UI, Jetpack Compose ułatwia tworzenie niestandardowych komponentów – a tych w aplikacjach mCommerce nie brakuje. Wprowadzanie dopasowanych kształtów, nakładanie dodatkowych efektów czy stylizowanie tekstu jest tu dużo prostsze niż w podejściu klasycznym.
Compose ma również całkowicie nowe API do animacji. To pozwala m.in. na szybsze tworzenie efektownych przejść pomiędzy komponentami czy animacji reagujących na akcje użytkownika.
Mniejsze ryzyko długu technologicznego
Od dłuższego czasu Google, jako właściciel całego ekosystemu Androida, kładzie mocny nacisk na adaptację i rozwój Compose. Jako że technologia ta jest nowsza i została dość ciepło przyjęta przez deweloperów, może stanowić bezpieczniejszy wybór w kontekście długofalowego rozwoju projektu.
Dodatkowy plus stanowi fakt, że Compose wchodzi w skład pakietu Jetpack. Jest to zbiór bibliotek, które dostarcza Google, żeby ułatwić prace nad aplikacjami na Androida. To oznacza, że prawdopodobnie będą powstawały integracje Compose z innymi rozwiązaniami z tego pakietu. Chociażby z `android-paging` (obecnie w wersji alpha) czy z Mapami Google.
Zadowolenie deweloperów
Zdecydowana większość programistów, z którymi pracowałem przy projektach wykorzystujących Compose, była z niego zadowolona. Deweloperzy zwykle lubią nowe technologie, a szczęśliwszy zespół to zazwyczaj zespół bardziej zmotywowany do działania.
Decydując się na Compose, łatwiej też zachęcić programistów do udziału w projekcie. Wielu z nich szuka obecnie okazji do pracy z tą technologią, aby rozwijać swoje umiejętności.
Krótszy czas rozwoju oprogramowania
Zdaję sobie sprawę, że zagadnienie to pozostaje kwestią sporną. Wiele osób podkreśla, że Compose jest technologią relatywnie młodą i w związku z tym cierpi na „choroby wieku dziecięcego”. Rzeczywiście, wykorzystanie nowej technologii, kiedy nie można liczyć na zbyt wiele wsparcia, zwiększa podatność na błędy. Trzeba też mieć na uwadze, że rozwiązanie niektórych (nawet trywialnych) problemów może wymagać więcej czasu.
Z naszych doświadczeń wynika jednak, że Compose w dalszym ciągu pozwala dużo szybciej tworzyć interfejsy aplikacji niż klasyczne podejście z XML.
Wyraźnie to widać w przypadku widoków złożonych z wielu komponentów różnego rodzaju. W aplikacjach mCommerce zazwyczaj są to widoki podsumowania zamówienia lub karty produktu. Można to też zaobserwować na niestandardowych komponentach. Trudno dokładnie określić, ile godzin oszczędzamy wykorzystując podejście deklaratywne, ale zdaniem deweloperów pracujących w naszych projektach, różnica była zauważalna.
Na jakie problemy można natrafić?
Bugi i problemy technologiczne
Pomimo wsparcia ze strony Google, trzeba pamiętać, że Compose to nadal rozwiązanie nowe i nieustannie rozwijane. Tym samym nie jest wolne od błędów. Natrafialiśmy czasem na problemy, które wymagały kontaktu z pracownikami Google i naprawy błędów po ich stronie.
Na szczęście żaden z tych problemów nie miał znaczącego wpływu na rozwój samych aplikacji mCommerce i ich działanie. Wydłużyły one jednak czas budowy funkcjonalności. Nie oznacza to, że tworząc widoki przez XML na błędy nie natrafimy, ale prawdopodobnie będzie ich mniej.
Mniej doświadczeni deweloperzy
Ponieważ Compose jest dość nowym rozwiązaniem, nie wszyscy deweloperzy mieli już okazję z nim pracować. Dlatego nawet jeśli dany specjalista ma wieloletnie doświadczenie programistyczne, nie oznacza to, że miał kiedyś styczność z deklaratywnym budowaniem UI.
W projektach mCommerce czynnikiem decydującym o budowie danej funkcjonalności często jest czas i co za tym idzie – koszt. Zespół mniej doświadczony w Compose może mieć większe trudności z wykorzystaniem tej technologii. Bywa, że przekłada się to na opóźnienia w projekcie bądź nawet rezygnację z pewnych funkcjonalności.
Brak możliwości wykorzystania gotowych rozwiązań
Nie wszystkie biblioteki i komponenty używane w aplikacjach są kompatybilne z Compose (choć sytuacja ulega ciągłej poprawie). W przypadku niektórych elementów konieczne może być wykorzystanie klasycznych widoków z XML. Dotyczy to np. skanera kodów kreskowych albo map z punktami odbioru zamówienia.
Nie stanowi to większego problemu ze względu na interoperacyjność pomiędzy Compose i XML. Może jednak sprawić, że realizacja niektórych zadań będzie bardziej złożona.
Który sposób budowania UI jest najlepszy?
Na to pytanie nie ma jednoznacznej odpowiedzi. Wybór pomiędzy podejściem klasycznym a Compose powinien być podparty znajomością problematyki i wymagań aplikacji, jaką będziemy tworzyć. Decyzję warto więc podjąć dopiero po zweryfikowaniu, jakie funkcjonalności będą potrzebne. Następnie można się zastanawiać, które z nich łatwiej zrealizujemy w jednym bądź drugim podejściu.
Alternatywne rozwiązanie
W przypadku naszej ostatniej realizacji, czyli aplikacji Homla, nauczeni doświadczeniem podjęliśmy decyzję o wykorzystaniu podejścia hybrydowego. Wszystkie widoki i komponenty tworzyliśmy przy wykorzystaniu Jetpack Compose. Jednak po zweryfikowaniu wymagań klienta dotyczących nawigacji, postanowiliśmy wykorzystać rozwiązania nawigacyjne z klasycznych `Fragmentów`. Nawigacja w Compose po prostu nie była w stanie zaoferować nam potrzebnych funkcjonalności.
Decyzja o wyborze danego rozwiązania nie powinna zależeć jedynie od deweloperów. Warto zaangażować w analizę również zespół odpowiedzialny za design i testy. Designerzy mogą zweryfikować, jakie komponenty są dostępne w ramach bibliotek Compose. Następnie powinni omówić z deweloperami, na ile problematyczna może być implementacja niestandardowych komponentów w jednym i drugim podejściu. Dzięki temu ostateczny wybór będzie odpowiadał wszystkim zaangażowanym w rozwój aplikacji.
