Kotlin Design Patterns for Android: Prefer Clear Ownership Over Ceremony

Prefer explicit state to boolean combinations

For a loading screen, a small sealed state can prevent impossible combinations such as “loading and failed and showing success”:

sealed interface LoadState {
    data object Idle : LoadState
    data object Loading : LoadState
    data class Ready(val itemCount: Int) : LoadState
    data class Failed(val message: String) : LoadState
}

This is an illustrative model. Avoid placing sensitive raw exception details in a user-visible message.

Make ownership visible

A global singleton holding an activity is still a lifecycle risk even if it is called a service locator. The Android memory guidance explains why retained references matter.

Use nullability as a contract

Follow Kotlin's null-safety model. A non-null type is useful only when values entering from Java, serialization or external data are validated appropriately. Replacing a failing safe call with !! often moves uncertainty into a runtime crash rather than resolving it.

Prefer explicit empty, unavailable and error states when they have different meanings to the feature.

Keep conventions boring

The Kotlin coding conventions help reduce unnecessary variation. Consistent names and small cohesive files improve review more than clever syntax that hides control flow.

Validate the design with a change

Ask how the code handles a retry, canceled request, offline state or replacement dependency. If a simple change requires editing many unrelated layers, the abstraction may be adding ceremony without protecting a useful boundary.

APKLint's Kotlin and static-code tools can flag patterns, but architecture quality requires reviewing the actual responsibilities and tests. Do not treat a zero-warning snippet as proof that lifecycle and state ownership are correct.