I've got an app that I'm working on that we're trying to use Glance to make the widgets with. Things generally work, but in some instances we are running into issues that seem like our recompositions aren't applying correctly, we only seem to get 2 seconds of recomposition time (if that), and then nothing else. It is documented that recomposition should be happening for ~45 seconds, 2 is a lot less than that. Does anyone have any ideas as to why this would be the case? We've come up with a very hacky workaround that involves using a

LaunchedEffect

that manually updates the widget via

update

but this is almost certainly definitely not how it is supposed to be done.

I wonder, I recently made a little game and noticed that after around 10 or so taps the widget process would be stopped by the OS. I got around it by saving to disk each time.

The data we are loading is ultimately coming from roomDB, but the issue isn't the data, it's just the state we have transitioning from loading to error too quickly. We threw a

forEach { delay250) }

to the flow before collecting it and that generally seems to have solved the problem, but nothing that we can see from the documentation really gives any indication that quick successive recompositions may be ignored (though perhaps we are just missing that)

To understand this better, is the issue that recomposition stops after 2 seconds, or that it updates too quickly? You're right that the widget should continue to recompose for at least 45 seconds after an update request is received or the widget is interacted with. We recommend saving state to disk to avoid losing it once the session is finished. We did recently make a change so that, if another recomposition happens while we are still processing the results of the last recomposition, we will cancel processing the last one and send the next one instead. This helped improve latency by avoiding processing results that will immediately be overridden by the next result.

Hmm, I'll see if I can get some sample code, but we were adding the widget, and it would get stuck showing our loading state even though we were successfully recomposing with the error state (as indicated by the

LaunchedEffect

triggering), removing and adding the widget (or adding another copy of it) it would correctly show the error state. Notably this was happening after a fresh install of the app (debug build).

Yes, provideGlance will get triggered again if it is not already running.

it would get stuck showing our loading state even though we were successfully recomposing with the error state

Is this the layout defined in

android:initialLayout

in your

<appwidget-provider />

info or a loading state composed by your widget?

a loading state composed by the widget.

right, that is definitely unexpected behavior. UI should reflect the most recently composed state. Do you see any errors in logcat when this happens, under the

GlanceAppWidget

tag? Also is there a sample I can try to reproduce this?

I'll get back to you on that.

If it's possible for me to look at the code that's causing the issue, that would be very helpful as well

Here are some screenshots of the code that we are able to fairly consistently reproduce with. UI is build with data coming from room. Yes I'm aware of the slight oddity of how the flow produced by the usecase is being collected and emitted to the uiState. Adding a

forEach{ delay(250) }

just before that

collectLatest

and the issue goes away.

The code looks fine for the most part. One thing that might be an issue here is that your

uiState

flow is a member of your GlanceAppWidget class. One instance of this class can be used to compose for multiple widgets, so they will share the

uiState

variable. You should declare it in

provideGlance

instead.

We are seeing the issue with a instance of the widget and that code (I believe we have since tweaked the code further, but I'll definitely look at moving that into

provideGlance

) 1: we are using 1.0.0 2: Rotating the device has no impact, item is still stuck, I believe if we wait around long enough that the configured refresh time happens then the widget correctly updates (but we shouldn't need to wait for that as we should still be within the available window)