IssueTracker

Hello,

I'm only a little familiar with Power Apps. Is your app a mobile app or a web app?

This link lists out the alternatives.

The primary recommended alternative for the Google Fit REST API is Health Connect.

If your app does not work on Android mobile devices, you can also consider the Fitbit Web API.

Zoe to investigate string resources or lint checks.

I think this should be higher than a P3. Right now every developer has three options:

1. Try using stringResource because that's what they're used to from Jetpack Compose and it's even suggested by the tooling (b/269961566) -- this gives them a crash; newer Compose users won't find the stacktrace helpful since CompositionLocals are mostly hidden, meaning they may spend time trying to fix their configuration thinking it's a setup issue
2. Hardcode every string -- This is a terrible practice but what all the documentation is currently showing (e.g., https://developer.android.com/develop/ui/compose/glance/create-app-widget)
3. Use the local context -- Non-obvious solution that doesn't trigger recomposition

A quick workaround for devs would be to create their own placeholder function like

@Composable
@ReadOnlyComposable
fun stringResource(@StringRes id: Int): String {
    return LocalContext.current.getString(id)
}

But Glance doesn't appear to handle recomposing the widget if the system language is changed, so there should be a solution in Glance and there should be lint checks since most developers are going to assume they should use stringResource() from compose.ui.

The concern with adding stringResource to Glance has been around not polluting the namespace for Compose UI developers.

We don't want it to be the case that adding the Glance library to a Compose UI app starts making the Glance specific stringResource be suggested when writing Compose UI code, as this would get tricky quite quickly.

We've also tried to avoid prefixing Glance functions with 'glance' because it becomes cumbersome, but in this case maybe it makes sense to have glanceStringResource() , worth investigating whether type inference helps us here.

It might be worth exploring options that would help the tooling side then. For example, if we recommend all widgets go into a widget module that Android Studio understands, maybe it can be smart about pulling in the right imports. Alternatively, maybe a Glance-specific annotation would give AS enough context. Or maybe AS has enough knowledge already by looking up the composable tree to see if the root is ultimately from Glance or not.

The concern about polluting the namespace goes beyond stringResource because of other common composables like Text, so it'd be great if we can solve this more holistically.

+1 to #8.

stringResource() composable automatically triggers recomposition on locale change. However, this isn't the case with LocalContext.current.getString()