Fix weather widget stuck in loading state

[ar9988]

Summary

Testing note: This change resolves the reported issue in the tested API 30 environment, but the issue still reproduces on API 37 and a physical Samsung device. The behavior in those environments may have a different cause and requires further investigation.

Investigates #402 — WeatherGlanceWidget gets stuck in the loading state (WeatherInfo.Loading) after following the "Always install with package manager" + "Launch: Nothing" run configuration from the sample's README.

Root cause

WeatherGlanceWidgetReceiver.onEnabled() calls WeatherRepo.updateWeatherInfo() to populate the initial weather state. However, onEnabled() is only called once, when the number of widget instances for this provider goes from 0 to 1.

When the app process is restarted while a widget instance already exists on the home screen, onEnabled() is not invoked again because the widget provider already has an active instance. The widget is still updated and rendered through the normal Glance update flow (onUpdate → provideGlance), but since WeatherRepo's state is held in memory and resets on process restart, nothing re-triggers the data fetch — so the widget keeps rendering the Loading state it was left with.

This is confirmed by logcat: in the broken case, WeatherRepo: updateWeatherInfo called never appears, while onUpdate and provideGlance still run normally.

Fix

Move the data-loading call out of the Receiver lifecycle callbacks and into provideGlance(), per the GlanceAppWidget.provideGlance documentation:

"This is a good place to load any data needed to render the Composable. Use provideContent to provide the Composable once the data is ready."

override suspend fun provideGlance(context: Context, id: GlanceId) {
    WeatherRepo.updateWeatherInfo()
    provideContent { Content() }
}

• Removed the CoroutineScope(Dispatchers.IO).launch { WeatherRepo.updateWeatherInfo() } calls from onEnabled() and onUpdate().
• provideGlance() provides the appropriate entry point to load data required to render the widget before calling provideContent().
• WeatherRepo.updateWeatherInfo() already has its own throttling (mutex + lastRun/TIMEOUT), preventing redundant updates when multiple widget instances trigger the call.

Testing

On a Pixel 7 emulator running API 30 (Android 11), I reproduced the bug using the run configuration described in the sample's README (Always install with package manager + Launch: Nothing). Logcat confirmed that updateWeatherInfo was never called and the widget stayed in Loading.

After the fix, on the same environment, I verified across multiple runs that:

• provideGlance → updateWeatherInfo() → provideContent executes correctly on every relaunch, without requiring a resize.
• The widget transitions from Loading to Available as expected.
• No duplicate fetches occur across different widget sizes (throttling confirmed via updateWeatherInfo - throttled (too soon) logs).

Note

I also tested the fix on API 37 (Android 16) and on a physical Samsung device. In both environments, the issue still reproduces. Further investigation is needed to determine whether the issue has a different cause in these environments.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.