Insomnia Technologies

Introduction: The Recomposition Nightmare That Changed How We Build Apps

Early in our transition to Jetpack Compose, a junior developer submitted a PR that looked perfectly fine. It fetched user data inside a LaunchedEffect. The catch? The effect was keyed to a mutable UI state variable that updated on every keystroke. The result: an infinite loop of network requests that temporarily took down our staging backend.

Modern Android Development (MAD) in 2026 is no longer about just replacing XML with Compose. It is about mastering Unidirectional Data Flow (UDF), preventing subtle performance traps, and structuring apps so that 10+ developers can work on the same codebase without stepping on each other's toes. This guide covers the production-tested patterns we use to build scalable, crash-free Android applications.

Modern Android Clean Architecture with Unidirectional Data Flow — A robust Android architecture separates UI state, business logic, and data sources, ensuring predictable behavior.

The Reality of Jetpack Compose: Beyond the Basics

Jetpack Compose is now the absolute default for Android UI. However, its declarative nature introduces a new class of bugs: recomposition traps. If your composable functions are not written carefully, the UI will redraw unnecessarily, causing jank and battery drain.

Concept	Beginner Approach	Production Approach
Lists	`Column` with a `forEach` loop	`LazyColumn` with stable `key` parameters
State	Multiple `var` properties in ViewModel	Single `UiState` data class or Sealed Class
Side Effects	`LaunchedEffect` with mutable keys	`LaunchedEffect` with stable keys, or `viewModelScope`
Dependencies	Manual instantiation or Service Locator	Hilt with `@Inject` and scoped modules

💡 Compose Performance Pro Tip

Always use the Compose Compiler Metrics plugin (composeCompilerMetrics). It will explicitly tell you which of your composable functions are "unstable" and causing unnecessary recompositions. Fix those first.

Unidirectional Data Flow (UDF) in Practice

The golden rule of modern Android architecture is UDF: State flows down, events flow up. The UI never modifies state directly; it sends events to the ViewModel, which processes them and emits a new state.

UserProfileViewModel.kt

kotlin

              // 1. Define a sealed UI State
data class UserProfileUiState(
    val isLoading: Boolean = false,
    val user: User? = null,
    val errorMessage: String? = null
)

@HiltViewModel
class UserProfileViewModel @Inject constructor(
    private val userRepository: UserRepository
) : ViewModel() {

    // 2. Private mutable state, public immutable state
    private val _uiState = MutableStateFlow(UserProfileUiState())
    val uiState: StateFlow<UserProfileUiState> = _uiState.asStateFlow()

    // 3. Events flow up from UI
    fun onEvent(event: UserProfileEvent) {
        when (event) {
            is UserProfileEvent.LoadUser -> loadUser(event.userId)
            is UserProfileEvent.Retry -> loadUser(_uiState.value.user?.id ?: return)
        }
    }

    private fun loadUser(userId: String) {
        viewModelScope.launch {
            _uiState.update { it.copy(isLoading = true, errorMessage = null) }

            // Use 'catch' to handle errors gracefully without crashing
            userRepository.getUser(userId)
                .catch { e ->
                    _uiState.update {
                        it.copy(isLoading = false, errorMessage = "Failed to load user")
                    }
                }
                .collect { user ->
                    _uiState.update {
                        it.copy(isLoading = false, user = user)
                    }
                }
        }
    }
}

Collecting State Safely in Compose

Collecting a StateFlow in Compose seems simple, but doing it wrong leads to memory leaks or collecting state when the UI is not visible (wasting CPU and battery).

UserProfileScreen.kt

kotlin

              @Composable
fun UserProfileScreen(
    viewModel: UserProfileViewModel = hiltViewModel()
) {
    // CRITICAL: Use collectAsStateWithLifecycle to only collect when the screen is STARTED or RESUMED
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()

    UserProfileContent(
        state = uiState,
        onRetryClick = { viewModel.onEvent(UserProfileEvent.Retry) }
    )
}

@Composable
private fun UserProfileContent(
    state: UserProfileUiState,
    onRetryClick: () -> Unit
) {
    when {
        state.isLoading -> CircularProgressIndicator()
        state.errorMessage != null -> ErrorView(message = state.errorMessage, onRetry = onRetryClick)
        state.user != null -> UserDetailView(user = state.user)
    }
}

Advanced Coroutines & Flow Patterns

Coroutines are powerful, but misuse leads to concurrency bugs. Two patterns we use daily in production:

●
Debouncing User Input: Use debounce() and distinctUntilChanged() on a search query MutableSharedFlow to prevent spamming the backend with API requests on every keystroke.
●
Combining Multiple Data Sources: Use combine() to merge a local Room database Flow with a remote network Flow, emitting a "Loading from cache" state followed by "Fresh data".

SearchViewModel.kt

kotlin

              // Debouncing search queries to protect the backend
private val searchQuery = MutableSharedFlow<String>(replay = 1)

init {
    viewModelScope.launch {
        searchQuery
            .debounce(300) // Wait 300ms after the last keystroke
            .distinctUntilChanged() // Ignore identical consecutive queries
            .flatMapLatest { query ->
                if (query.isBlank()) flowOf(emptyList())
                else repository.searchUsers(query).catch { emit(emptyList()) }
            }
            .collect { results ->
                _uiState.update { it.copy(searchResults = results) }
            }
    }
}

fun onSearchQueryChanged(query: String) {
    viewModelScope.launch {
        searchQuery.emit(query)
    }
}

Dependency Injection: Hilt Best Practices

Hilt is the standard, but poorly structured modules lead to slow build times and confusing scopes. Avoid putting everything in SingletonComponent.

NetworkModule.kt

kotlin

              @Module
@InstallIn(SingletonComponent::class)
object NetworkModule {

    @Provides
    @Singleton
    fun provideOkHttpClient(): OkHttpClient {
        return OkHttpClient.Builder()
            .connectTimeout(15, TimeUnit.SECONDS)
            .addInterceptor(HttpLoggingInterceptor().apply {
                level = if (BuildConfig.DEBUG) {
                    HttpLoggingInterceptor.Level.BODY
                } else {
                    HttpLoggingInterceptor.Level.NONE
                }
            })
            .build()
    }

    @Provides
    @Singleton
    fun provideRetrofit(client: OkHttpClient): Retrofit {
        return Retrofit.Builder()
            .baseUrl(BuildConfig.BASE_URL)
            .client(client)
            .addConverterFactory(Json.asConverterFactory(ContentType.Application.Json)) // Kotlinx Serialization
            .build()
    }
}

💡 Build Speed Pro Tip

Hilt can significantly increase Gradle build times. Use @BindValue in tests instead of full Hilt integration tests whenever possible, and enable Gradle configuration caching.

Room Database: Avoiding the Main Thread Trap

Room is excellent, but returning List<User> instead of Flow<List<User>> forces you to manage manual cache invalidation. Always return Flow for reactive UI updates.

UserDao.kt

kotlin

              @Dao
interface UserDao {

    // CRITICAL: Return Flow to automatically update UI when DB changes
    @Query("SELECT * FROM users ORDER BY last_updated DESC")
    fun observeUsers(): Flow<List<User>>

    // Use suspend for one-off writes
    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertUsers(users: List<User>)

    // Example of a TypeConverter for complex objects
    @TypeConverter
    fun fromTimestamp(value: Long?): Date? {
        return value?.let { Date(it) }
    }
}

Testing: The Safety Net You Cannot Skip

Manual QA is not enough for modern Android apps. We enforce a minimum of 70% test coverage on the Domain and Data layers. Here is our testing stack:

Layer	Tool	Purpose
ViewModel / Domain	JUnit 5 + MockK + Turbine	Verify business logic and Flow emissions
Repository	MockK + Fake Database	Test data merging and error handling
UI (Compose)	Compose Test Rule + Semantics	Verify UI state changes and user interactions

UserProfileViewModelTest.kt

kotlin

              @OptIn(ExperimentalCoroutinesApi::class)
class UserProfileViewModelTest {

    @get:Rule
    val mainDispatcherRule = MainDispatcherRule()

    private val userRepository = mockk<UserRepository>()
    private lateinit var viewModel: UserProfileViewModel

    @Before
    fun setup() {
        viewModel = UserProfileViewModel(userRepository)
    }

    @Test
    fun `loadUser success updates state correctly`() = runTest {
        val fakeUser = User(id = "1", name = "Igor")
        coEvery { userRepository.getUser("1") } returns flowOf(fakeUser)

        viewModel.onEvent(UserProfileEvent.LoadUser("1"))

        // Turbine makes testing Flows incredibly clean
        viewModel.uiState.test {
            assertEquals(true, awaitItem().isLoading)
            assertEquals(fakeUser, awaitItem().user)
            cancelAndIgnoreRemainingEvents()
        }
    }
}

Production Performance: Baseline Profiles & R8

Your app might be perfectly architected, but if it takes 3 seconds to launch, users will uninstall it. In 2026, shipping without Baseline Profiles is considered a critical oversight.

●
Baseline Profiles: Pre-compile critical app paths during installation, reducing cold start time by up to 40%. Generate them using Macrobenchmark.
●
R8 Full Mode: Enable isMinifyEnabled = true and isShrinkResources = true in release builds. Ensure you have proper ProGuard rules for serialization and reflection.
●
Image Loading: Never load full-resolution images into memory. Use Coil (with Compose integration) and enforce strict memory caching limits.

Common Modern Android Mistakes

●
❌ Putting business logic in Compose functions: Composables should only observe state and dispatch events.
●
❌ Using LaunchedEffect for data fetching: This ties the network call to the UI lifecycle. Use viewModelScope instead.
●
❌ Ignoring key in LazyColumn: This causes Compose to lose item state during scrolling or list updates, leading to severe performance drops.
●
❌ Overusing MutableStateFlow for events: Use Channel or SharedFlow with replay = 0 for one-time events (like showing a Snackbar) to prevent them from re-triggering on configuration changes.
●
❌ Skipping catch blocks in Flows: An unhandled exception in a Flow will silently terminate the collection, leaving the UI stuck in a loading state.

"Jetpack Compose makes building UI easy, but it makes writing bad architecture easier. Discipline and Unidirectional Data Flow are your only defenses."

Frequently Asked Questions

Is Clean Architecture overkill for a small app?

Yes, a strict 3-layer Clean Architecture can be overkill for a 3-screen app. However, the core principle of UDF and separating UI from business logic should always be applied. You can collapse the Domain and Data layers initially, but keep the boundaries clear.

How do I handle configuration changes (like screen rotation) with Compose?

ViewModels survive configuration changes automatically. As long as your state is held in the ViewModel (not in the Composable's `remember`), the UI will seamlessly reconnect to the existing state upon rotation.

Should I use Kotlin Multiplatform (KMP) for new projects?

KMP is production-ready for sharing business logic and networking layers between Android and iOS. However, stick to native Jetpack Compose for the Android UI layer unless you have a specific, justified need for Compose Multiplatform.

How do I debug recomposition issues?

Enable "Show Recomposition Counts" in Android Studio Layout Inspector. For deeper analysis, use the Compose Compiler Metrics Gradle plugin to identify unstable classes and parameters.

Conclusion

Modern Android development in 2026 is not about chasing the newest library; it is about mastering the fundamentals of state management, reactive programming, and performance. By strictly adhering to Unidirectional Data Flow, leveraging the power of Coroutines and Flow safely, and rigorously testing your business logic, you can build Android applications that are fast, maintainable, and resilient at scale.

Want to deepen your Android expertise? Check out our guides on [Optimizing Jetpack Compose Performance], [Advanced Kotlin Coroutines Patterns], and [Setting Up Baseline Profiles for Faster App Startup].