AppState Class Contradicts the definition in the official Guide to App Architecture Documentation

I noticed the [StateHolder guide](https://developer.android.com/topic/architecture/ui-layer/stateholders?utm_source=chatgpt.com)
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!

Start by reading the StateHolder guide and the NiaAppState entry point mentioned in the issue, along with its references to UserNewsResourceRepository, NetworkMonitor, and TimeZoneMonitor. Compare the implementation with the guide and document whether the current design is intentional; done requires a decided architectural direction, not just a code change.

Written by the indexing model from the issue text.