How do you know when the watches field has been populated?

[matejdro]

Currently watches field is backed by a MutableStateFlow that starts with an emptyList() and then, eventually, this field will get populated from the database asynchronously.

This presents a problem: there is no way to distinguish between "watches have been loaded and user's watch list is empty" vs "watch list is yet to be loaded" states.

My use case for this is to, on phone boot, only start the app background service if there are any enabled watches to actually connect. Since this is on startup, I would get an empty list immediately and then after some undetermined time, list would get populated.

Ideally, this flow would be modified to not emit anything until the list is loaded, but I'm not sure how much would that break things on your side. As an alternative, we can add a watchesLoaded: Flow<Boolean> field to the Watches. What do you think? I can submit a PR.

[sjp4]

Adding watchesLoaded would probably introduce a race condition (that was set but the watches field wasn't updated yet). StateFlow has to emit something immediately - we could make that nullable? Or have a parallel watchesFlow which isn't a StateFlow and doesn't emit immediately (but I don't like the duplication of state there. I'd probably go for nullable - what do you think?

We could also expose the connectGoal on devices, if you really only want to start things up when there's a device with an intention to connect.

[matejdro]

that was set but the watches field wasn't updated yet

We just need to set this after the watches field updates.

StateFlow has to emit something immediately

Yes, but we could change it to a SharedFlow that does not need to emit.

I'd probably go for nullable

That is also an option, but I feel it has disproportional impact - flow would only be null at the very start, but now every consumer has to deal with that small edge case.

[sjp4]

FYI you'll need to rebase all the PRs you put up - I just got CI to go green

Yes, but we could change it to a SharedFlow that does not need to emit.

We use watches.value from a few places which aren't suspended (i.e. it's deliverately a StateFlow to enable that)

on phone boot, only start the app background service if there are any enabled watches to actually connect

Thinking about that more, it sounds like that should be checking the connectGoal once it sees a list of devices? e.g. libPebble.watches.first { it.any { it.connectGoal } }. But i'm not sure if you want to wait and start the service whenever a user pairs a device, or do that as a one-off on boot only..

[matejdro]

We use watches.value from a few places

Ah yeah, that kills the idea then. I guess either nullable or separate flow would work then.

Thinking about that more, it sounds like that should be checking the connectGoal

From what I can see, if the watch is the instance of the ConnetedPebbleDevice or a ConnectingPebbleDevice then connectGoal is supposed to be true? I don't think the boolean itself is exposed anywhere, it's private. But this still does not solve the main issue that libPebble.watches.first { it.any { it.connectGoal } } will be always false at startup, because the list would be empty and I have no idea how long to wait to know whether the list is really empty or not.

But i'm not sure if you want to wait and start the service whenever a user pairs a device, or do that as a one-off on boot only

The idea is that, after a watch is paired and a phone is rebooted, we want to restart the connection at boot, so we can connect to the watch again. But we don't want to do that if there are no paired devices, so we don't waste the user's resources.

[matejdro]

How about we change libpebble.watches to a Flow that does not emit until the value is ready, but we add a val currentWatches: List<PebbleDevices> that can be accessed without suspending?

That way we avoid having to handle null values everywhere the flow is connected, but we still keep the non-suspend access.

[sjp4]

I don't love having val currentWatches: List<PebbleDevices> being backed by a mutable list - that's really just what StateFlow is for. How about we leave the existing one unchanged and add either a parallel flow val watchesFlow: Flow<List<PebbleDevice>> which won't emit until populated, or a separate val watchesNullable: StateFlow<List<PebbleDevice>?>?

[matejdro]

It would not be a mutable list. It would be val on the interface, and then var + private set on the implementation.

Parallel flows work too. Which one do you prefer?

[sjp4]

I think I found a better way - can you try out the latest commit on main?