The setExactAndAllowWhileIdle seems like it's wait...

# compose-wear

[yschimke]

The setExactAndAllowWhileIdle seems like it's waiting for the alarm to fire.

[yschimke]

Do you have something waking the app up periodically with a timer, or driven by data updates.

[yschimke]

The point of ambient is to not keep refreshing the screen, so I think you'd want something updating once a minute normally, and then maybe once a second when it's close to firing.

[yschimke]

And Wear OS might be trying to stop you updating once a second.

[FEDUSS]

I have a timer updating the screen once a seconds of course, that maybe i have to stop while entering on ambient mode (and start on interactive)

[FEDUSS]

Ok so i misunderstood the refresh point of ambient...maybe becaude the samsung timer i was comparing to is keeping refreshing once a second on ambient (but it's a system app)

[FEDUSS]

The refreshing during last timer's seconds should be enough for the context...but i think it's wear os related, and the batching sys

[yschimke]

To be honest, as much as you want a timer that updates predictably in ambient, I think the system wants to stop you doing that. It might require a partial wake lock to get it working well, but that could kill battery?

[FEDUSS]

I already tested battery by keeping screen on (in interactive mode) during a personal workout (1.5h), but only during timer usage (20/25min)...battery usage is between 10-15% on my galaxy watch pro and a little more on galaxy watch 4.

But, if there's a way to re-enable recomposition (in ambient mode) during the last timer seconds, should be ok (on wrist rotation, you can anyway enter in interactive mode, and see all data)...the important thing is to warn the user about timer expiring and timer changing

[FEDUSS]

@yschimke ok, by stopping the active timer, it seems that the broadcast receiver is triggered...now i have to figure out how to update the timer ambient page from the broadcast receiver 😄 (i don't think i can start an activity from a broadcast receiver on sdk 33 for ex., and it may be already on foreground, with AoD)

[yschimke]

I thought that happens just by compose state reads. The broadcast receiver just wakes your process up?

[FEDUSS]

Didn't got what you mean...i'll try to explain better my app flow during active timer.

When the timer is active and ambient mode is interactive, the onTick / onFinish functions of timer tells the VM to update the uistate.

When the app is paused during interactive mode or if the watch switches to ambient mode, i do a timer.cancel(), enable the background alert (setExactAndWhileIdle bla bla method :D) and the ongoing notification with the pending intent of MainActivity.

While on interactive mode, the switching between a timer and the next is, as i wrote before, handled by compose + viewmodel, but during background usage (including ambient mode), is all up to broadcast receiver (that saves the info about the current active timer, to restore it when the user resume the app throught the icon, recents or ongoing notification). When a timer expired during ambient mode, i have no clue how to recompose the timer view with the next timer, because " i'm " on broadcast receiver (it's not guaranteed that the app is on foreground during ambient mode, expecially on wear os 5)...of course a wrist rotation can restore the app state (and i handle this), but i'm talking about an case in which the user uses AoD all the time, and i had to refresh the view with the next timer, while on Ambient...i hope to have been more clearer :P (it's a complex flow, i know)

[yschimke]

Yeah, I think on Wear 5, there is a 1 minute limit for ambient, and then fallback to ongoing activity or similar.

[FEDUSS]

So, i suppose that value of onUpdateAmbient is not passed from AmbientAware, when the app goes on background during ambient mode

[yschimke]

Not sure. The Composable is a thin wrapper over the callback based api

[FEDUSS]

@yschimke while playing on archive.org, i found this old guide that shows an example to refresh the ambient mode more frequently:

https://developer.android.com/training/wearables/views/always-on#update-content-in-ambient-mode

(Maybe there's another old version of the doc with the same guide, but more updated...need to check there --> https://web.archive.org/web/20240000000000*/https://developer.android.com/training/wearables/views/always-on)

Tomorrow i will read it to see if is still valid (the current documentation is very poor)

[yschimke]

I believe some of the doc updates are because the system has more control now. In Wear 4 & 5. If you want to update frequently during ambient then you are fighting the system trying to optimise power.

[yschimke]

There were samples showing updating more frequently that got removed because they no longer applied on newer Wear and even android. Such as exact timers.

[FEDUSS]

yeah maybe...i'll try to find another way to follow the system behavior and to update the timer to the next