Hi folks, I am trying to understand the best pract...

# compose-android

[Abhimanyu]

Hi folks,
I am trying to understand the best practise to architect an Jetpack Compose app.

Current architecture - Pure Compose, Single activity, No fragments, using Compose navigation (No external nav libs).

Specifically, I am looking to understand how to pass data and events between screen composable and viewmodel.
Adding more details in thread.

[Abhimanyu]

Currently, I have

Screen

@Immutable
data class HomeScreenUIData(
    val isXVisible: Boolean = false, 
    // ...
)

@Immutable
internal data class HomeScreenUIEvents(
    val navigateToSettingsScreen: () -> Unit,
    // ...
)

fun HomeScreenUI(
    events: HomeScreenUIEvents,
    uiState: HomeScreenUIState,
    state: CommonScreenUIState,
) {
  // ...
}

The problem with this data class approach is the screen composable recomposes for any changes.

[Abhimanyu]

I tried referring to some sample apps like Now In Android and they pass all the data and events into the compostables directly.
This may be too large to maintain.

[Joel Denke]

composable(
    "profile?userId={userId}",
    arguments = listOf(navArgument("userId") { defaultValue = "user1234" })
) { backStackEntry ->
    Profile(navController, backStackEntry.arguments?.getString("userId"))
}

See https://developer.android.com/jetpack/compose/navigation#nav-with-args

In viewmodel getting data through SavedStateHandle.
Can also combine navgraphs per compose screen.

[Joel Denke]

For events, see UDF https://developer.android.com/jetpack/compose/architecture#udf

[Abhimanyu]

Hi @Joel Denke,
For reference,
This is my sample app - https://github.com/Abhimanyu14/finance-manager

I have gone through the docs.

All the docs have a simplified examples with few lambdas for events and it seems to work okay.
But as it scales to lot of events, the number of parameters in a composable grows by a lot.

[Joel Denke]

To avoid a lot of lambdas, I usually having one shared event lambda for a screen and propagate up to viewmodel and viewmodel then respond ui state change. Often can aggregate input data and some ui states isolated state holders.
In large scale apps I see no issue, used this pattern in really large apps. Just make sure separating ui from Android SDK and domain logic.

[Joel Denke]

In general to avoid recompositions, depend on as little data as possible per composable. Trickle down from screen level, divide and conquer and isolate.
For home screen not sure from sample. But share as little as possible. Do not send ui data from home level to sub screens, as causing recompositions all the time.