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"...