Nie używaj Data Binding w Androidzie

Zajmowanie się wywołaniami findViewById() od pierwszego dnia podczas pracy nad Androidowymi UI opartymi na XML było prawdziwym koszmarem. Nieco później pojawiło się coś, co nazwaliśmy View Binding, aby uprościć proces, a następnie pojawiło się wiązanie danych (Data Binding), aby pobierać dane bezpośrednio z widoków XML.

Przewiduje się, że Data Binding i View Binding staną się mniej istotne w miarę przechodzenia na Jetpack Compose. Tak, nadszedł czas, aby odejść od tych metod. Są jednak starsze aplikacje na Androida, w których przejście z Javy na Kotlina może być w zasięgu, ale przepisanie interfejsów użytkownika w Jetpack Compose może być zbyt dużym wyzwaniem.

Gdybyśmy nadal musieli trzymać się Kotlina i widoków XML, należy rozważyć wady stosowania Data Binding. A jest ich trochę, szczególnie, że wiele osób postrzega tę technikę jako nieoptymalną i ciężką w utrzymaniu.

<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android">

    <data>
        <variable
            name="contact"
            type="com.something.databinding.ContactCard" />
        <variable
            name="presenter"
            type="com.something.databinding.ContactListActivityPresenter"/>
    </data>

    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:orientation="vertical"
        >
        <TextView
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:text="@={contact.contactId}"
            />
        <TextView
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:text="@={contact.contactName}"
            />

        <EditText
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:text="@={contact.contactOrganisation}" />

        <Button
            android:text="Show office address on map"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:onClick="@{() -> presenter.onShowMap(contact)}"
            android:id="@+id/button" />

        <Button
            android:text="Show call history"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:onClick="@{() -> presenter.showCallHistory()}"
            />

    </LinearLayout>
</layout>

Dlaczego kochamy Data Binding w Androidzie?

Lepsza czytelność kodu

Data Binding zmniejsza potrzebę stosowania kodu boilerplate'u i upraszcza implementację wzorca Model-View-ViewModel (MVVM). 

Większe bezpieczeństwo typowania

Data Binding zapewnia bezpieczeństwo typowania poprzez sprwadzenie typów danych w czasie kompilacji. Zmniejsza to prawdopodobieństwo wystąpienia błędów w runtime’ie i poprawia ogólną stabilność aplikacji.

Lepsza wydajność

Data Binding może poprawić wydajność aplikacji poprzez zmniejszenie liczby wywołań funkcji findViewById() i zmniejszenie kodu wymaganego do aktualizacji elementów UI.

Łatwa integracja z LiveData

Data Binding jest ściśle zintegrowane z LiveData, upraszczając implementację reaktywnych komponentów UI.

Wiązanie dwukierunkowe

Data Binding pozwala na dwukierunkowe wiązanie między UI a modelem danych, co ułatwia aktualizację danych w czasie rzeczywistym.

Jak Data Binding narusza niektóre zasady inżynierii oprogramowania?

Istnieją różne opinie na temat wykorzystania Data Binding w aplikacjach Androida.

Ściśle powiązany kod

Podczas gdy Data Binding może pomóc zmniejszyć kod boilerplate i uprościć aktualizacje UI, może również utrudnić debugowanie i sprawić, że baza kodu będzie bardziej silnie powiązana. Kiedy widzimy powód „silnie powiązana”, wiemy, że nie jest to coś, czego chcemy w uniknąć nowoczesnym świecie tworzenia oprogramowania - to również dlatego zrezygnowano z używania klas bazowych.

Separation of concerns

Separation of concerns to podstawowa zasada w inżynierii oprogramowania, która opowiada się za rozdzieleniem funkcjonalności na różne moduły, tak aby każdy moduł miał pojedynczą odpowiedzialność. Dzięki temu łatwiej jest utrzymać i przetestować kod.

W przypadku Data Binding może utrudnić czytanie i zrozumienie kodu, ponieważ łączy kod UI i kod manipulacji danymi. To z kolei może utrudnić debugowanie i utrzymanie kodu, zwłaszcza jeśli aplikacja jest złożona.

Trudniejsze do testowania i debugowania

Jak powtórzono dwukrotnie powyżej, ponieważ Data Binding jest kodem wygenerowanym, może być trudniejszy do debugowania w porównaniu do zwykłego kodu. Dodatkowo, ponieważ wygenerowany kod nie jest widoczny w projekcie, prześledzenie pojawiających się problemów może być trudne.

Testowanie jednostkowe kodu stworzonego poprzez Data Binding jest również stosunkowo trudniejsze.

Techniczne względy, aby nadal używać Data Binding

Należy zauważyć, że to do każdego zespołu należy rozważyć plusy i minusy i zdecydować, czy Data Binding to odpowiednie narzędzie dla ich potrzeb. Jednakże, mamy kilka dodatkowych technicznych kwestii, jeśli chcemy dalej używać wiązania danych (Data Binding) w starszym projekcie aplikacji w języku Kotlin z widokami XML.

Data Binding zależy od KAPT, ale to KSP jest przyszłością

Jako bardziej złożony niż View Binding, Data Binding wymaga dodatkowego generowania kodu i opiera się na KAPT.

KAPT jest w trybie utrzymania. JetBrains utrzymuje go na bieżąco z ostatnimi wydaniami Kotlina i Javy, ale nie ma planów dodania nowych funkcji. Obecnie zaleca się używanie API Kotlin Symbol Processing (KSP) do przetwarzania adnotacji.

Możemy korzystać z zalet wydajności KSP tylko wtedy, gdy w projekcie używamy wyłącznie KSP bez KAPT. Im dłużej Data Binding z nami zostanie, tym większa szansa, że stanie się przeszkodą. Ponieważ inne biblioteki polegające na KAPT będą stopniowo dostarczać wersję KSP i wycofywać wersję KAPT.

Data Binding jest również w trybie utrzymania

Jak ujawnił Google, Data Binding jest również w trybie utrzymania.

Google nie planuje wspierać KSP, ani nie zaleca używania Data Binding na tym etapie, ponieważ compose jest ich zalecanym rozwiązaniem UI.

Jeśli KAPT przestanie działać, Data Binding również przestanie działać.

Podsumujmy

Utrzymanie starszego projektu aplikacji może być trudne - albo zamrażamy wszystkie wersje bibliotek i zależności (lub nawet kompilatora Kotlin), aby upewnić się, że projekt nadal się kompiluje, albo poświęcamy trochę minimalnego wysiłku, aby utrzymać aktualne zależności, aby wspierać nowsze urządzenia z systemem Android i przestrzegać polityki Google Play, a to wszystko zależy od decyzji zespołu programistów.

Ponieważ widzimy, że KAPT staje się przestarzały, warto zweryfikować wykorzystanie Data Binding, jeśli starszy projekt aplikacji ma przetrwać dłużej bez migracji do Jetpack Compose.

Oryginał tekstu w języku angielskim przeczytasz tutaj.