Java 17+ czy Kotlin wraz z Jetpack Compose?

0

Czyli całkowicie odchodzimy od idei graficznego projektowania interfejsu przez dewelopera? Pamiętam projekt na studia, gdzie cały interfejs w GTK musiałem pisać z palca, bo nie istniał RAD dla tej biblioteki. O ile szybciej by było poustawiać kontrolki i ich własności w GUI. Obecnie istnieje Glade.

W Compose przyjęto założenie, że projektantka stworzy interfejs w Figmie, a deweloper podepnie gotowe komponenty.

https://developer.android.com/jetpack/compose/tooling/relay

W Compose musisz już wiedzieć, jakie są komponenty, jakie własności (lub co chwilę zaglądać do dokumentacji), bo GUI nie zawsze podpowiada wszystkie dostępne opcje. Dużo rzeczy piszesz z palca, które byś normalnie ustawił z poziomu Designera. Na razie przechodzę tutorial Compose, ale aplikację muszę szybko zacząć, więc mam dylemat, czy na siłę iść w Compose, czy jednak wykonać ją tradycyjnym sposobem, gdzie jest wiele szablonów i jest integracja z Material.

Niestety muszę przebudować projekt, by widzieć zmiany w Compose. Może czegoś nie ustawiłem.

Piszę jednak w Kotlinie.

0
Shiba Inu napisał(a):

Niestety muszę przebudować projekt, by widzieć zmiany w Compose. Może czegoś nie ustawiłem.

A masz najnowsze Android Studio? Wygląda na to że dopiero niedawno to weszło do wersji stable:

Compose Preview updates automatically - In earlier versions of Android Studio, you had to manually refresh Compose Previews after making changes. In Electric Eel, Previews update automatically after you make compatible code changes in the same file, allowing you to iterate on your UI faster. If your code change was incompatible, Previews will show a “Needs Rebuild”

https://android-developers.googleblog.com/2023/01/android-studio-electric-eel.html

1

Używam IntelliJ IDEA Ultimate, który ma wbudowaną wtyczkę do Androida.

Na razie przechodzę przewodniki Compose. Warto też przeczytać wprowadzenie:

https://developer.android.com/jetpack/compose/mental-model

2

Nie mam dużego doświadczenia, napisałem w życiu kilka niewielkich aplikacji na Androida. Jedną w okolicach 2010 roku, drugą w okolicach 2015, trzecią zacząłem w 2022 roku.

Z moich obserwacji wynika, że:

  1. W Kotlinie pisze się znacznie przyjemniej i szybciej. Nigdy więcej nie wrócę do Javy na Androidzie.
  2. W Kotlinie jest duży nacisk na "nowe podejście" do nullability. Powoduje to trochę problemów i masę warningów kiedy się konwertuje jakiś stary kod w Javie na Kotlin, używa w projekcie plików Java (bez konwersji), albo chce się pisać "po staremu", czyli deklarujemy a później wypełniamy pola albo i nie. Trzeba się nauczyć pisać kod w którym nullable jest tylko to, co powinno być nullable. Jak ktoś miał do czynienia z programowaniem funkcyjnym, rozumie na czym ono polega to jest dość łatwo.
  3. Miałem jeden poważny problem po przejściu na Kotlin - skrypty Gradle mają inną składnię, trzeba poświęcić trochę czasu żeby to opanować, a później może (ale nie musi) okazać się, że nie wszystko co się dało w Gradle pod Javę da się zrobić w Gradle pod Kotlin. Ja miałem taki problem z Gradle SSH Plugin.
  4. Filozofia tworzenia UI w Androidzie ciągle jest niedopracowana się zmienia, pełno jest nieprzemyślanych rozwiązań, dokumentacja nie nadąża, na developer.android.com pełno jest nieaktualnych i/lub złych (powodujących duże problemy z późniejszym rozwojem albo utrzymaniem projektu).
  5. "Reklamowane" biblioteki, które miały ułatwić życie programistom często je komplikują. Na przykład próbowałem używać DataBinding, ale z czasem okazało się, że to jest gorsze niż klepanie findViewById. Aktualnie używam "odchudzonej wersji", czyli ViewBinding. Jest też to nowe API do nawigacji. Fajnie to wygląda na papierze, ale jak się zacznie z tym pracować dłużej to zaczyna być denerwujące i tworzy nowe problemy w projekcie, bo nie działa z tym czy tamtym.
0
Kamil A napisał(a):

W Kotlinie jest duży nacisk na "nowe podejście" do nullability. Powoduje to trochę problemów i masę warningów kiedy się konwertuje jakiś stary kod w Javie na Kotlin, używa w projekcie plików Java (bez konwersji), albo chce się pisać "po staremu", czyli deklarujemy a później wypełniamy pola albo i nie. Trzeba się nauczyć pisać kod w którym nullable jest tylko to, co powinno być nullable. Jak ktoś miał do czynienia z programowaniem funkcyjnym, rozumie na czym ono polega to jest dość łatwo.

To się nazywa null safety i jako koncepcja to nie nowość, C# ma to od dawna. Z tą różnicą, że w C# to nie jest prawdziwe null safety, bo typy nullable to jest Nullable<T> a zapis np int? to tylko lukier składniowy.

W Kotlinie i Dart int i int? to są inne typy i jak coś nie jest nullable to musi dostać wartość przy deklaracji, bez tego będzie błąd kompilacji (w C# będzie tylko warning)

1

Android to temat rzeka. Przez tydzień nie da się opanować podstaw. Właśnie kończę oficjalny kurs. Jest on dla początkujących programistów, więc nauka metodą małych kroków. Google powinno stworzyć też kurs dla zaawansowanych, aby od razu uczyć dobrych praktyk, tak jak powinno się budować aplikacje i rozszerzać jedną aplikację zamiast dwudziestu małych. Byłoby o wiele szybciej. Czeka mnie jeszcze nauka API Androida.

Jest też osobny kurs dla Compose, gdzie tematy się powtarzają:
https://developer.android.com/courses/jetpack-compose/course

Compose zawiera znacznie więcej bibliotek:
https://developer.android.com/jetpack/androidx/explorer

Pełna dokumentacja Compose
https://developer.android.com/jetpack/compose/documentation

Czy opłaca się dalej uczyć Compose? Czy ta technologia ma przyszłość? Jeśli to nie będzie wieloplatformowe, to moim zdaniem szkoda czasu. Ale czego by się nie uczyć, to za kilka lat trzeba uczyć się czegoś nowego. Na uniwerku były warsztaty z pisania natywnych aplikacji na Windows Phone. Później w modzie były Cordova i PhoneGap. Potem Xamarin, który działał dość wolno. Dziś React Native i Flutter. Dlaczego nie PWA? Uniwersalne API, wieloplatformowe technologie, ale gigantom przynosiłoby to straty.

0

W google powinni się uczyć od MS. Jak MS zrobił.NET-a i WPF 20 lat temu to do tej pory niewiele się zmieniło z punktu widzenia programisty.
A w Google coraz to nowe biblioteki niekompatybilne z całym światem, albo jakieś atrapy bibliotek do MVVM-a które się nadają co najwyżej do aplikacji z 3 widokami.

0

To nie do końca prawda, bo .net core zerwał praktycznie kompatybilność ze starym .net framework. Wszystko trzeba było pisać od początku.

0

To jest jakiś wzorzec projektowy? Znalazłem taką wtyczkę do Android Studio.

https://github.com/levinzonr/jetpack-compose-ui-arch-plugin

Dla każdego komponentu generujemy 5 plików, wszystko warstwa UI. Jakie są zalety takiej architektury? Niestety nie ma dokumentacji, co do czego służy, gdzie wstrzyknąć ProvideKomponentActions, co ma być w ViewModel, a co w Coordinator. To trochę bardziej komponentowe podejście. W googlowskich przykładowych projektach jest 1 lub kilka ViewModel, nie ma żadnych koordynatorów, w RouteGraph bezpośrednio używamy konkretnych Composable i często ViewModele mają napchane dużo logiki, która powinna znajdować się w innych miejscach?

Możecie podrzucić projekty na GitHubie, gdzie Waszym zdaniem jest wszystko poprawnie poukładane.

Ale nie ma co rozmyślać nad architekturą. Klient się niecierpliwi, a ja nawet prostego demo nie mam do pokazania.

3

Ja wrzucę opinię, która w tym dziale raczej nie zdobędzie przesadnej popularności. Uważam, że aplikacje na Androida są koszmarnie przekombinowane. Nie wiem co masz zrobić, ale 90% aplikacji mobilnych, to (czasami lekko rozwinięte) OPA do uruchamiania na telefonach. Przeczytaj sobie o tym jakie są komponenty aplikacyjne (activity, service, content provider, broadcast receiver), szczególnie uważnie przeczytaj fragmenty o ich cyklu życia, bo z braku znajomości tego cyklu bierze się większość błędów.... Rozpisz sobie to co masz na te komponenty. Na 90% nie wyjdziesz poza activity, ale warto zerknąć na początku. Czasami wskoczy jakiś broadcast receiver, ale raczej z marszu, jak będziesz implementował np. notyfikacje.
W drugim kroku masz do ogarnięcia łączność ze światem - tworzysz sobie klienta http, który ma wstać razem z aplikacją, zrobić handshake, w razie czego w prosty sposób możesz dorzucić tu jakiś cache.
Kolejny komponent, to utrwalanie danych - też zwykła klasa, ma odpowiadać za zapis odczyt do bazy danych (tutaj uwaga - naprawdę, większość aplikacji mobilnych nie potrzebuje relacyjnej bazy danych, często wystarczy utrwalić 5 rekordów na krzyż w jakimś jsonie i go gdzieś trzymać...).
Pozostaje jeszcze kwestia wstrzykiwania zależności i tutaj kiedyś się używało Dagger'a, ale... w Androidzie, wszystko musi być osadzone w jednym z komponentów aplikacyjnych, a tych nie tworzysz, nie masz możliwości zmiany ich konstruktora, kończy się na wstrzykiwaniu pól i wywołaniu gdzieś metody daggera "hej wstrzyknij mi wszystkie pola z adnotacjami". Więc o jakimkolwiek sensownym IoC nie ma co marzyć. Jak ci się chce zgłębiać kolejną bibliotekę, to możesz, ale jak nadpiszesz sobie klasę Application i wstawisz w niej metody fabrykujące do komponentów, których potrzebujesz, to będzie działać, w dodatku będziesz wiedział jak działa i zaoszczędzisz dzień, czy 2 na zmuszaniu jakiejś biblioteki do działania. Warto za to przemyśleć jakiś event bus, czyli np. w jednym miejscu użytkownik pobiera dane na nowo, klient http jak je dostanie, to wysyła zdarzenie, wszystkie kontrolki, które powinny dostają powiadomienie i się odświeżają.

Na UI jak to we front endzie - pokazują się jakieś nowinki, ale po skumaniu jak działają layouty, odpaleniu widoku z xml+preview da się robić UI szybko. Jedna uwaga - trzeba się nauczyć robić komponenty, nie ma z tym dużo roboty, a dużo prościej się w tym kodzie odnaleźć. Nie wiem jak dużo daje Jetpack, bo wyszedłem z Androida zanim się pojawił, ale jak już napisałem - z XML da się żyć.

Rzeczy na które na 100% się nadziejesz - nic co wykorzystuje komunikację http, albo może trwać dłużej nie ma szansy zadziałać na głównym wątku. Albo się nie skompiluje, albo będzie przypadkowo naparzać błędami u użytkowników. więc znowu kwestia wyboru... RxJava albo androidowy Handler. Znowu - moja wiedza jest tutaj przestarzała, od ~5 lat nie dotykałem Androida, ale wcześniej nawet sporo, jeszcze przed pojawieniem się pierwszych urządzeń.

MVVM, to w skrócie mapowanie widoku na model. Opisujesz każde pole na widoku, jak ma się mapować na model, jak zmienisz model i powiadomisz widok, to sobie te dane zaciągnie, jak widok coś zmieni, to też zrobi update na modelu. Nie potrzeba pisać z łapy model.setWhatever(mojaKontrolka.getText()). W Compose masz to już z tego co widzę "wbudowane", co może być jakimś argumentem.

Pytanie z tematu wydaje mi się równie bezcelowe jak zapytanie frontendowców "react czy angular"...

0 użytkowników online, w tym zalogowanych: 0, gości: 0