Gardzę XML'em, jak zrobić layout bez niego ? Czy ANKO odchodzi do lamusa ? Czy da się to zrobić w Android KTX ?

O ile tworzenie layout'ów w XML jest dobre dla większości noobów, o tyle to nie może działać wydajnie.

Jakiś czas temu na jakimś Google I/O usłyszałem o ANKO.
Bardzo spodobała mi się koncepcja klepania layoutów w DSL jadącym na Kotlinie.
Niestety nigdy nie udało mi się zmusić do działania wtyczki podglądu layout'u, ale nie martwiło mnie to zbytnio.

Przerobiłem swoją appkę tak, że kompletnie pozbyłem się kodu XML'a z layoutów (pomijając pewne problemy z trybem pełnoekranowym - rysowaniem pod StatusBar i NavBar).
Stworzyłem containter programowo i wrzuciłem tam programowo utworzony fragment z mapą Google i UI naklepany w DSL na wierzch tego.

Miałem dłuższą przerwę w programowaniu, a sporo się ostatnio pozmieniało.

Ciągle coś działa niezgodnie z oczekiwaniami i nie ogarniam dlaczego.
Niedawno przeczytałem gdzieś, że Android KTX 'jest odpowiednikiem ANKO', więc z racji bycia dzieckiem Google postanowiłem się na to przerzucić, ale jestem rozczarowany, bo nie widzę w Android KTX żadnej funkcjonalności dedykowanej layout'om.

Czy jest tutaj ktoś kto ogarnia CoordinatorLayout i ConstraintLayout bez użycia XML'a i jakichś nieoficjalnych zewnętrznych bibliotek ?

Znacie może jakieś dobre dokumentacje, czy tutoriale ?

Co myślicie o ANKO ? Wiecie może kiedy z grubsza Google wreście stworzy możliwość klepania layoutów w DSL najlepiej z real time podglądem ?

_ [...]o tyle to nie może działać wydajnie_ . Mógłbyś podrzucić jakiś artykuł który porównuje wydajność tworzenia widoków w xmlu oraz w kodzie? Pracuję ładnych parę lat w androidzie i nigdy tworzenie layoutu w xmlu nie było problemem. Nawet jeśli jedna /dwie ramki wypadną to użytkownik końcowy tego nie zauważy.

Tworzenie widoków z poziomu kodu to tylko mała część Anko. Jeżeli o tej części mówimy, to jest ciekawym eksperymentem, żeby pokazać możliwość budowania DSL. Poza tym, nic specjalnego czy wygodnego.

KTX jest trochę odpowiednikiem Anko, ale nie do końca. KTX ma na celu dostosować już istniejące funkcjonalności tak, żeby były idiomatycznie konsumowane w Kotlinie. Nowe funkcje nie będą się w nim pojawiać tylko w Javowych odpowiednikach.

Czasami pojedyncze widoki tworzę z poziomu kodu, ale jest to raz na ruski rok i nie korzystam z żadnych DSLi.

lubie_programowac napisał(a):

_ [...]o tyle to nie może działać wydajnie_ . Mógłbyś podrzucić jakiś artykuł który porównuje wydajność tworzenia widoków w xmlu oraz w kodzie? Pracuję ładnych parę lat w androidzie i nigdy tworzenie layoutu w xmlu nie było problemem. Nawet jeśli jedna /dwie ramki wypadną to użytkownik końcowy tego nie zauważy.

https://android.jlelse.eu/400-faster-layouts-with-anko-da17f32c45dd
Stere, ale na pewno bardziej, lub mniej aktualne.
Poważne app'ki poprzechodziły na Anko, więc chyba coś w tym jest.
Jak to testowałem na starym Samsungu Note 2 różnica była bardzo odczuwalna - na ANKO appka startowała błyskawicznie, a z XML'a zauważalnie przywieszała start.
Generalnie nie lubię samej koncepcji parsingu danych - to bardziej sprawa ideologiczna, a nie praktyczna.
Po prostu uważam, że tak nie powinno się robić grafiki - ona powinna zawsze działać szybko.
Nie marudziłbym bardzo, gdyby kod XML był w momencie kompilacji sprowadzany do assemblera, ale wiem, że tak nie jest i przetwarza się to w locie co jest słabe.

Kod DSL nie dość, że jest zwięzły to jeszcze w momencie kompilacji jest optymalizowany.

Eksterminator napisał(a):

Poważne app'ki poprzechodziły na Anko, więc chyba coś w tym jest.

Skąd te informacje i które aplikacje?

https://android.jlelse.eu/400-faster-layouts-with-anko-da17f32c45dd
Stere, ale na pewno bardziej, lub mniej aktualne.

Właśnie stare: sprzed Coordinator Layout oraz co ważniejsze sprzed Data Binding Library. W projekcie mam dodane DataBinding, sprawdziłem właśnie w kodzie - z pliku xml podczas kompilacji generowany jest plik ~java w którym zawarte są layoutu. Pola te są final.

Należy zadać więc pytanie czy CL + DB może być wolniejszy niż Anko. Nie będę tego sprawdzać - różnica pewnie jest dosłownie minimalna.

XML powinien być wolniejszy od ręcznie pisanych widoków, bo LayoutInflater korzysta z refleksji.

lubie_programowac napisał(a):

https://android.jlelse.eu/400-faster-layouts-with-anko-da17f32c45dd
Stere, ale na pewno bardziej, lub mniej aktualne.

Właśnie stare: sprzed Coordinator Layout oraz co ważniejsze sprzed Data Binding Library. W projekcie mam dodane DataBinding, sprawdziłem właśnie w kodzie - z pliku xml podczas kompilacji generowany jest plik ~java w którym zawarte są layoutu. Pola te są final.

Należy zadać więc pytanie czy CL + DB może być wolniejszy niż Anko. Nie będę tego sprawdzać - różnica pewnie jest dosłownie minimalna.

Nie zajmuję się programowaniem zawodowo i generalnie nie do końca to wszystko ogarniam

sprawdziłem właśnie w kodzie - z pliku xml podczas kompilacji generowany jest plik ~java

Gdzie się sprawdza takie rzeczy ? Deasemblowałeś gotową app'kę ?

Z pliku XML nie powstaje plik java. Layout z XMLa jest parsowany do innego XMLa (tym razem binarnego) przez narzędzie AAPT2 i ten plik jest potem ładowany przez LayoutInflater.

Chyba, że pytasz o DataBinding. Wtedy plugin generuje pliki javowe, które mapują widoki, listenery i takie tam, ale to nie jest widok tylko most do niego. Możesz podejrzeć te pliki normalnie w Android Studio. Z głowy nie pamiętam, jak się nazywają i gdzie się znajdują, ale Ctrl + B/Cmd + B Cię tam przeniesie.