UrlFlow and errorFlow are initialized with the state value and eagerly started

[TimoPtr]

Summary

From #6687, the FrontendViewModel.urlFlow and errorFlow are always returning null if it doesn't have any subscriber and invoking .value on it. It is because of the stateIn WhileSubscribe behavior instead we should initialize with the state behavior and always collect to update this field. It is important since we are using .value in few places so we need to make sure it reflect the current state (We could still have a race but regarding of where it is used I think we are fine).

Checklist

• New or updated tests have been added to cover the changes following the testing guidelines.
• The code follows the project's code style and best_practices.
• The changes have been thoroughly tested, and edge cases have been considered.
• Changes are backward compatible whenever feasible. Any breaking changes are documented in the changelog for users and/or in the code for developers depending on the relevance.

[Copilot]

Pull request overview

This PR adjusts FrontendViewModel’s derived urlFlow and errorFlow so their .value reflects the current viewState even when there are no active subscribers, addressing a stateIn(WhileSubscribed) behavior where .value could remain null.

Changes:

• Switch urlFlow and errorFlow to stateIn(..., SharingStarted.Eagerly, initialValueFromState) instead of WhileSubscribed.
• Update unit tests to assert on errorFlow.value directly (without needing to collect first) and add a derived-flow test group.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
app/src/main/kotlin/io/homeassistant/companion/android/frontend/FrontendViewModel.kt	Makes derived flows eagerly started and initializes them from the current viewState to keep .value current
app/src/test/kotlin/io/homeassistant/companion/android/frontend/FrontendViewModelTest.kt	Updates tests around derived flows and removes reliance on “activate via subscription” for errorFlow

[jpelgrom]

From #6687, the FrontendViewModel.urlFlow and errorFlow are always returning null if it doesn't have any subscriber and invoking .value on it (...) It is important since we are using .value in few places so we need to make sure it reflect the current state

I can understand this change and why it might be needed for race conditions, but not why you're referring to #6687 as that doesn't touch either of these two flows?

[TimoPtr]

From #6687, the FrontendViewModel.urlFlow and errorFlow are always returning null if it doesn't have any subscriber and invoking .value on it (...) It is important since we are using .value in few places so we need to make sure it reflect the current state

I can understand this change and why it might be needed for race conditions, but not why you're referring to #6687 as that doesn't touch either of these two flows?

I found the issue while working on the #6687 because my first implementation was using the urlFlow to give the current url to the bridge before I switch to the Uistate.

[jpelgrom]

I found the issue while working on the #6687 because my first implementation was using the urlFlow to give the current url to the bridge before I switch to the Uistate.

Do you want to switch back to using the urlFlow after this is merged?

[TimoPtr]

I found the issue while working on the #6687 because my first implementation was using the urlFlow to give the current url to the bridge before I switch to the Uistate.

Do you want to switch back to using the urlFlow after this is merged?

No I don't think it is useful since we already have the UIState that is the source of truth, the main goal of urlFlow is for the error screen.