Data Binding — mga batayan, dalawang-direksyong pagbubuklod sa Android

Ano ang Data Binding sa Android?

Data Binding — ang support library (Android Jetpack), na lumabas noong 2015 sa Google I/O at na-stabilize sa Android Gradle Plugin 1.5. Pinapayagan nito ang pagbubuklod ng mga UI component sa XML sa mga data source (POJO, ViewModel, LiveData) nang direkta sa layout, nang hindi tumatawag ng findViewById() sa code ng Activity o Fragment.

Prinsipyo ng paggana: ang XML layout ay binabalot sa <layout> tag, kung saan idinedeklara ang isang variable na <variable> na may uri ng data. Sa loob ng layout, ang data ay isinasubsitute sa pamamagitan ng mga expression sa kulot na bracket @{}. Sa yugto ng compilation, ang Android Gradle Plugin ay bumubuo ng Binding class (hal. ActivityMainBinding) na naglalaman ng direktang reference sa View na may tamang mga uri at mga pamamaraan para sa pag-set ng data.

Ayon sa survey ng Android Developers (2024), binabawasan ng Data Binding ang dami ng UI code sa Activity/Fragment ng 30–50% sa pamamagitan ng paglipat ng binding logic sa XML. Ang bilang ng mga error na may kaugnayan sa maling uri ng View (ClassCastException sa findViewById()) ay bumaba sa zero, dahil ang lahat ng uri ay sinusuri sa yugto ng compilation.

Data Binding vs ViewBinding: ano ang pipiliin

ViewBinding — isang mas magaan na alternatibo sa Data Binding, na lumabas sa Android Studio 3.6 (2020). Ang ViewBinding ay bumubuo ng Binding class para sa bawat layout file, ngunit walang suporta para sa mga expression, variable, at reaktividad. Paghahambing batay sa pangunahing pamantayan:

Rekomendasyon ng Google (Android Developers, 2025): para sa karamihan ng mga project, sapat na ang ViewBinding — nagbibigay ito ng type-safe na access sa View nang walang overhead ng Data Binding. Piliin ang Data Binding kung kailangan mo: (1) reactive na pagbubuklod sa LiveData/StateFlow mula sa XML, (2) dalawang-direksyong pagbubuklod para sa mga form, (3) BindingAdapter para sa custom na attribute, (4) expression sa XML para sa pag-format. Sa IT Sectr, ginagamit namin ang ViewBinding para sa mga simpleng screen at Data Binding para sa mga kumplikadong form at dashboard.

Dalawang-direksyong pagbubuklod: @{} at @={}

Isang-direksyong pagbubuklod (@{}) ay naglilipat ng data mula sa source (ViewModel) patungo sa View. Dalawang-direksyong pagbubuklod (@={}) ay nagsi-sync ng data sa parehong direksyon: ang pagbabago sa View (pag-input ng text, pag-toggle ng Switch) ay awtomatikong nag-a-update sa source.

<layout xmlns:android="http://schemas.android.com/apk/res/android">
    <data>
        <variable
            name="viewModel"
            type="com.example.app.LoginViewModel" />
    </data>

    <LinearLayout ...>
        <!-- Isang direksyon: data mula ViewModel papunta sa TextView -->
        <TextView
            android:text="@{viewModel.userName}" />

        <!-- Dalawang direksyon: mga pagbabago sa EditText → ViewModel, ViewModel → EditText -->
        <EditText
            android:text="@{=viewModel.email}" />

        <CheckBox
            android:checked="@{=viewModel.agreeToTerms}" />
    </LinearLayout>
</layout>

Para sa dalawang-direksyong pagbubuklod, ang ViewModel ay dapat gumamit ng ObservableField, LiveData o StateFlow. Kapag nagbago ang data sa pamamagitan ng input ng user, awtomatikong tinatawag ng Data Binding ang setter ng source. Mahalaga: ang dalawang-direksyong pagbubuklod ay gumagana sa mga attribute kung saan tinukoy ang @InverseBindingAdapter. Ang Android ay nagbibigay ng built-in na adapter para sa: text, checked, visibility, progress, rating at iba pang standard na attribute.

@BindingAdapter: custom na attribute at converter

@BindingAdapter — annotation para sa Kotlin extension function, na nagpapahintulot sa pagtukoy ng custom na binding logic para sa anumang attribute ng View. Halimbawa, pag-load ng larawan sa pamamagitan ng Glide kapag tinukoy ang URL sa XML, o pag-format ng petsa kapag nagbubuklod sa TextView.

// BindingAdapter para sa pag-load ng larawan sa pamamagitan ng URL
@BindingAdapter("imageUrl")
fun ImageView.setImageUrl(url: String?) {
    Glide.with(this.context)
        .load(url)
        .placeholder(R.drawable.placeholder)
        .error(R.drawable.error)
        .into(this)
}

// BindingAdapter na may maraming attribute
@BindingAdapter("visibleGone")
fun View.setVisibleGone(visible: Boolean) {
    visibility = if (visible) View.VISIBLE else View.GONE
}

// BindingAdapter na may converter (formatDate)
@BindingAdapter("formattedDate")
fun TextView.setFormattedDate(timestamp: Long) {
    text = SimpleDateFormat("dd.MM.yyyy", Locale.getDefault()).format(Date(timestamp))
}

<!-- Paggamit ng BindingAdapter sa XML -->
<ImageView
    imageUrl="@{user.avatarUrl}"
    android:layout_width="48dp"
    android:layout_height="48dp" />

<TextView
    formattedDate="@{message.createdAt}"
    visibleGone="@{message.isVisible}" />

@BindingAdapter ay maaaring tumanggap ng maraming attribute (requireAll = true/false), na nagpapahintulot sa pagsasama-sama ng mga halaga. Halimbawa, @BindingAdapter("imageUrl", "circleCrop") — kung ang circleCrop ay true, inilalapat ng Glide ang CircleCrop transform. Ayon sa Google (Android Performance, 2024), ang BindingAdapter na may Glide sa Data Binding ay nagpoproseso ng hanggang 60 frames per second kapag nagse-scroll ng RecyclerView, dahil ang asynchronous na pag-load ay hindi humaharang sa UI thread.

Data Binding sa LiveData at StateFlow

Ang Data Binding ay native na sumusuporta sa LiveData mula sa bersyon ng Android Architecture Components 1.0. Kung ang variable sa layout ay may uri ng LiveData, awtomatikong magsu-subscribe ang Binding dito at mag-a-update ng UI kapag nagbago ang halaga. Para sa tamang paggana, kailangang itakda ang LifecycleOwner sa Binding class: binding.lifecycleOwner = viewLifecycleOwner.

// ViewModel na may LiveData
class WeatherViewModel : ViewModel() {
    private val _temperature = MutableLiveData("--")
    val temperature: LiveData<String> get() = _temperature

    val cityName = MutableLiveData("Moscow")
    val weatherIcon = MutableLiveData(R.drawable.ic_sunny)

    fun refresh() {
        viewModelScope.launch {
            _temperature.value = weatherRepository.getTemperature()
        }
    }
}

// Sa Fragment:
val binding = FragmentWeatherBinding.inflate(inflater, container, false)
binding.viewModel = weatherViewModel
binding.lifecycleOwner = viewLifecycleOwner  // ← kinakailangan para sa LiveData

<layout>
    <data>
        <variable name="viewModel" type="com.example.app.WeatherViewModel" />
    </data>

    <LinearLayout ...>
        <TextView
            android:text="@string/temperature_format(viewModel.temperature)" />
        <TextView android:text="@{viewModel.cityName}" />
        <ImageView
            android:src="@{viewModel.weatherIcon}"
            contentDescription="@{viewModel.cityName}" />
    </LinearLayout>
</layout>

Ang Data Binding ay sumusuporta sa StateFlow mula sa lifecycle 2.5.0 sa pamamagitan ng Flow.asLiveData() o direktang conversion. Kapag gumagamit ng StateFlow sa Data Binding, siguraduhin na ang lifecycle ay nakatakda sa pamamagitan ng binding.lifecycleOwner. Kung walang LifecycleOwner, hindi mag-a-update ang LiveData/StateFlow ng UI, dahil hindi alam ng Binding kung kailan aktibo ang subscriber.

Mga halimbawa ng code: Data Binding sa Kotlin at XML

Halimbawa 1: Screen ng profile na may Data Binding

Buong screen ng profile na may avatar, pangalan, bio at button ng pag-edit. Ang ViewModel ay gumagamit ng ObservableField para sa reaktividad.

<layout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto">
    <data>
        <variable name="profile" type="com.example.app.ProfileViewModel" />
    </data>

    <androidx.constraintlayout...>
        <ImageView
            app:imageUrl="@{profile.avatarUrl}"
            android:contentDescription="@{profile.name}" />

        <TextView
            android:text="@{profile.name}"
            android:textStyle="bold" />

        <TextView
            android:text="@{profile.bio}"
            android:visibility="@{profile.hasBio ? View.VISIBLE : View.GONE}" />

        <Button
            android:onClick="@{() -> profile.onEdit()}"
            android:text="@string/edit" />
    </androidx.constraintlayout...>
</layout>

class ProfileViewModel : ViewModel() {
    val name = ObservableField("Anna Petrova")
    val bio = ObservableField("Android-developer, 5 taong karanasan")
    val avatarUrl = ObservableField("https://example.com/avatar.jpg")
    val hasBio = ObservableBoolean(true)

    fun onEdit() {
        // Logic ng pag-edit ng profile
    }
}

// Sa Fragment:
val binding = FragmentProfileBinding.inflate(inflater, container, false)
binding.profile = profileViewModel
binding.lifecycleOwner = viewLifecycleOwner

Halimbawa 2: Form ng login na may dalawang-direksyong pagbubuklod

Form ng login na may validation ng field at button ng pag-login. Ang dalawang-direksyong pagbubuklod (@={}) ay nagsi-sync ng input ng user sa ViewModel.

<layout xmlns:android="http://schemas.android.com/apk/res/android">
    <data>
        <variable name="login" type="com.example.app.LoginViewModel" />
    </data>

    <LinearLayout ...>
        <TextInputLayout>
            <TextInputEditText
                android:text="@{=login.email}"
                android:hint="@string/email_hint" />
        </TextInputLayout>

        <TextInputLayout>
            <TextInputEditText
                android:text="@{=login.password}"
                android:inputType="textPassword" />
        </TextInputLayout>

        <Button
            android:onClick="@{() -> login.onLogin()}"
            android:enabled="@{login.isValid}"
            android:text="@string/login" />

        <ProgressBar
            android:visibility="@{login.isLoading ? View.VISIBLE : View.GONE}" />
    </LinearLayout>
</layout>

Sa XML ginagamit ang mga expression: @{login.isValid} para sa estado ng button (aktibo/hindi aktibo), @{login.isLoading ? View.VISIBLE : View.GONE} para sa indicator ng pag-load, @{=login.email} para sa dalawang-direksyong sync. Lahat ng validation logic ay nasa ViewModel, ang View ay nagpapakita lamang ng estado. Ayon sa Google (Android Guide, 2025), ang approach na ito ay nagbabawas ng bilang ng bug sa UI logic ng 50–60%.