Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SettingsManager: use Flows instead of LiveData #714

Merged
merged 2 commits into from
Apr 10, 2024
Merged

Conversation

rfc2822
Copy link
Member

@rfc2822 rfc2822 commented Apr 8, 2024

Uses Flow instead of LiveData to provide observable settings.

  • callbackFlow is used with the SettingsManager.addOnChangeListener.
  • The flow always emits the current value (even if it's null; so something like Sync state indicator bar not shown in CALDAV tab #681 won't happen) and then updates
  • In the Compose UI, collectAsStateWithLifecycle is used to collect the flow lifecycle-aware: if the Activity is paused, the flow will be stopped; if it's resumed, it will be started again.
  • At some points, .asLiveData() is used so that existing code that uses settings LiveData doesn't have to be rewritten in this PR.

In the AccountDetailsPage, there was a problem with the initial value of groupMethod: forcedGroupMethod may be null at the first composition and then be updated. Now updated values of forcedGroupMethod are forced into the groupMethod. In this context, we're also using Flow.map.

In TaskUtils.currentProviderFlow, I have used stateIn to make the SELECTED_TASK_PROVIDER setting flow hot and stateful: the initial value and then incoming updates will be collected to a current state (StateFlow) so that the result always has a correct value.

@ArnyminerZ @sunkup I think this is how we could use Flows in the future (as discussed yesterday). Please test / have a look and tell me your thoughts.

@rfc2822 rfc2822 added the refactoring Internal improvement of existing functions label Apr 8, 2024
@rfc2822 rfc2822 marked this pull request as ready for review April 8, 2024 20:43
@rfc2822 rfc2822 force-pushed the settings-live-flow branch 3 times, most recently from 6d113d6 to 3689145 Compare April 9, 2024 08:30
@rfc2822 rfc2822 force-pushed the settings-live-flow branch from 3689145 to fbbe078 Compare April 9, 2024 08:41
@rfc2822 rfc2822 self-assigned this Apr 9, 2024
@rfc2822 rfc2822 requested review from sunkup and ArnyminerZ April 9, 2024 08:57
Copy link
Member

@sunkup sunkup left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment:
Aha, really nice to have some flow scenarios together in a smaller PR. I see myself coming back taking a look at this in the future whenever I struggle ~

Especially the callback wrapping of our SettingsManager. I wonder whether we could later have SettingsProviders expose their settings as flows as well? I guess it comes down to SharedPreferences exposing settings as flows which will likely never happen, now that DataStore is the recommended approach.

I think the more verbose nature of Flows, in comparison to LiveData, will actually make me become more aware of the android lifecycle mechanisms.

It annoys me a tad, that we need collectAsStateWithLifecycle() and it's so long, but I will get used to it. Other than that I gather flows are much more elegant. Now LiveData feels clumsy in comparison ^^

Review:
It works and looks okay to me. I can't really see any issues with it as of right now.

@rfc2822 rfc2822 merged commit b88c351 into main-ose Apr 10, 2024
8 checks passed
@rfc2822 rfc2822 deleted the settings-live-flow branch April 10, 2024 10:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactoring Internal improvement of existing functions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants