I noticed the StateHolder guide
describes plain class state holders as UI-only, without business logic. But in the Now in Android code, NiaAppState:

directly references UserNewsResourceRepository, NetworkMonitor, and TimeZoneMonitor (i.e. data layer)

computes derived state related to “unread resources” (some business logic)

is instantiated via remember, not through a ViewModel

So NiaAppState is not a pure “plain class state holder” per the guide. It behaves more like an app-level UI coordinator / state orchestrator, combining UI logic with lightweight access to domain data for navigation and cross-feature state.

Could you clarify:

1. Was NiaAppState deliberately designed this way (blending data and UI logic) for sample simplicity or is there another architectural reason?

2. In your view, should some of the data access / business-logic portions be moved to a ViewModel or domain layer instead?

I can also propose a stricter refactoring version that aligns more closely with the guide’s architecture!