In Compose, if SSOT principles are followed, can the type itself be assumed to be Immutable or Stable?

[yongsuk44]

@Stable
class NiaAppState(
    val navController: NavHostController,
    coroutineScope: CoroutineScope,
    val windowSizeClass: WindowSizeClass,
    networkMonitor: NetworkMonitor,
    userNewsResourceRepository: UserNewsResourceRepository,
    timeZoneMonitor: TimeZoneMonitor,
)

Currently, looking at the primary constructor of NiaAppState, only the WindowSizeClass is marked as @Immutable, and the rest seem to adhere to SSOT principles through interfaces (the NavHostController is provided solely through rememberNiaAppState, which appears to meet SSOT principles - #186).

I am curious whether it's acceptable to omit the @Immutable annotation if all methods of an interface are considered to have referential transparency.

@Stable when applied to a type indicates a type that is mutable, but the Compose runtime will be notified if and when any public properties or method behavior would yield different results from a previous invocation. (In practice this notification is backed by the Snapshot system via @Stable MutableState objects returned by mutableStateOf().)
Such a type may only back its properties using other @Stable or @Immutable types.

Because, according to the Compose API guide, a class using the @Stable annotation should back its properties only with other @Stable or @Immutable types.

[Jaehwa-Noh]

I am not sure I understand fully your question.
In my opinion, If you remove @Immutable, compose compiler no way to know NiaAppState that was Immutable.

[yongsuk44]

@Jaehwa-Noh
Before repling, Apologies for the confusion in my previous messages, where I mistakenly referenced Issue 184 instead of PR #186

The NiaAppState class utilizes interfaces such as TimeZoneMonitor, NetworkMonitor, and UserNewsResourceRepository. These interfaces are not declared as @Immutable, thus the Compose compiler cannot automatically infer them as stable types.

According to the Compose API guide, properties of a class annotated with @Stable should be based only on other @Stable or @Immutable types. However, in PR #186, the NiaAppState employs the NavHostController, which adheres to the SSOT principle but is not marked as @Immutable.

I am curious whether types that are not @Immutable, yet adhere to the SSOT principle like the interfaces mentioned earlier, can be used in a @Stable type class (e.g., NiaAppState) without being explicitly annotated as @Immutable.

[Jaehwa-Noh]

I assumed that the code from #186 has @Immutable parameters, because of defined val.
That val will probably help to make decision Compose compile infer it's types.
But, I'm not sure my thought is right.

@Stable
class NiaAppState(
    val navController: NavHostController,
    val windowSizeClass: WindowSizeClass
) 

[yongsuk44]

Thank you for your commnet. 🙂

However, I understand that the use of val has no bearing on the Compose compiler inferring types as Stable. This can be confirmed by examining the Compiler compiler Report.

// WindowSizeClass.kt
@Immutable
class WindowSizeClass private constructor(
    // ....
)

// NavHostController.kt
public open class NavHostController

// Compiler Report
stable class NiaAppState {
  unstable val navController: NavHostController
  stable val windowSizeClass: WindowSizeClass
  unstable val isOffline: StateFlow<Boolean>
  unstable val topLevelDestinations: List<TopLevelDestination>
  unstable val topLevelDestinationsWithUnreadResources: StateFlow<Set<TopLevelDestination>>
  unstable val currentTimeZone: StateFlow<TimeZone>
}

[Jaehwa-Noh]

The compiler report says that navController was unstable.
It seemed to be you are right.

This is out of topic but, I got a question now, isOffline was StateFlow but why that represented in unstable? I don't understand.

[yongsuk44]

Simply put, in my opinion, StateFlow ensures the consistency and up-to-date status of data, but the state can change over time.

Due to this mutability, in Compose, if the state of StateFlow is not explicitly checked, it becomes difficult to track when the state has changed, which is why it is considered an 'unstable type'.

[Jaehwa-Noh]

Could that maybe be Wrapper solution?
This documentation makes Wrapper for unstable List<Snack>, and makes HighlightedSnacks stable.

So, make NiaAppState to use as Wrapper.
What about this thinking?

[yongsuk44]

NiaAppState is already wrapped with rememberNiaAppState and used in NiaApp

restartable skippable scheme("[androidx.compose.ui.UiComposable]") fun NiaApp(
  stable appState: NiaAppState
  stable modifier: Modifier? = @static Companion
)

My question is as follows 🥲 :

The NiaAppState class utilizes interfaces such as TimeZoneMonitor, NetworkMonitor, and UserNewsResourceRepository. These interfaces are not declared as @Immutable, thus the Compose compiler cannot automatically infer them as stable types.

According to the Compose API guide, properties of a class annotated with @Stable should be based only on other @Stable or @Immutable types. However, in PR #186, the NiaAppState employs the NavHostController, which adheres to the SSOT principle but is not marked as @Immutable.

I am curious whether types that are not @Immutable, yet adhere to the SSOT principle like the interfaces mentioned earlier, can be used in a @Stable type class (e.g., NiaAppState) without being explicitly annotated as @Immutable.

[yongsuk44]

This is my very personal conclusion, drawn from continuously searching for references and basing it on them

---

It was mentioned that all properties of a StateHolder should be based on @Stable or @Immutable types. It is thought to be for making state changes predictable and easy to manage.

Actually, all StateFlows in NiaAppState are converted into State using collectAsStateWithLifecycle() in a Composable, thereby detecting state changes and triggering ReComposition, and are thus used stable.

Moreover, each interface (TimeZoneMonitor, NetworkMonitor, and UserNewsResourceRepository) serves solely as a DataSource for delivering State to Composable, that is, they are responsible only for generating the current state of UI elements in the StateHolder. Therefore, I think they can be used in NiaAppState without being annotated with @Stable or @Immutable.