Great question! Let’s break down exactly how this Kotlin syntax works, why it’s the standard pattern for ViewModel LiveData, and what makes it so useful.

First, Recap the Pattern’s Purpose #

You already know we use this setup to encapsulate mutable state:

• _isRealtime is a private MutableLiveData — only the ViewModel can modify it (via postValue() or setValue()).
• isRealtime is a public LiveData — external components (like Fragments/Activities) can only observe it, not change its value.

The magic here is the get() = _isRealtime syntax — let’s dive into that.

How the Custom Getter Works #

This is Kotlin’s custom getter for a property without a backing field. Let’s break the line down:

val isRealtime: LiveData<Boolean> get() = _isRealtime

• val isRealtime: LiveData<Boolean>: Declares a read-only property of type LiveData<Boolean>. Unlike a regular val, this one doesn’t store its own value (no backing field).
• get() = _isRealtime: Defines what happens every time someone accesses isRealtime. Instead of returning a stored value, it directly returns the private _isRealtime instance.

Key Difference from a Regular Val #

If we wrote it like this:

val isRealtime: LiveData<Boolean> = _isRealtime

This would create a fixed reference to _isRealtime when the ViewModel initializes. The custom getter version, though, returns _isRealtime every time you access isRealtime.

In this specific LiveData scenario, both work almost the same way (since _isRealtime is never reassigned). But the custom getter gives you flexibility: if you ever need to adjust what’s returned (e.g., wrap the LiveData in a transformation), you can modify the get() logic without changing how external code accesses isRealtime.

Why This Matters for Android #

1. Enforces Immutability: By exposing LiveData instead of MutableLiveData, you guarantee external code can’t accidentally modify the state directly — all changes have to go through the ViewModel’s controlled logic.
2. Clean, Kotlin-idiomatic Syntax: Instead of writing a verbose fun getIsRealtime(): LiveData<Boolean> = _isRealtime, we use Kotlin’s property syntax which is more readable and concise.
3. Preserves Observer Subscriptions: Since we always return the same _isRealtime instance, any observers attached to isRealtime will stay subscribed to the underlying mutable LiveData — no risk of losing updates from a new instance.

Quick Example of How It’s Used #

In your ViewModel, you might update the mutable LiveData like this:

fun toggleRealtime() {
    _isRealtime.postValue(_isRealtime.value?.not() ?: false)
}

And in a Fragment, you observe the public property safely:

viewModel.isRealtime.observe(viewLifecycleOwner) { isEnabled ->
    updateUI(isEnabled)
}

No way for the Fragment to call setValue() or postValue() on isRealtime — perfect for maintaining a single source of truth.

内容的提问来源于stack exchange，提问作者adamhurwitz.eth