Make Breezy weather data available through a ContentProvider

[papjul]

Update 14/10/2024: Due to the 1 MB limit of broadcast, a complete redesign as a ContentProvider is planned.

To easily allow other apps to use our data, we should have our own WeatherSpec, like what Gadgetbridge does. This spec could include more details and all of the public weather data we have.

The spec should be versioned in the intent name with old versions being supported for a limited remaining time when newer version is out.

Currently, some apps reuse it to make their own widgets.

Pre-requisite: #828

[kmod-midori]

Would it be possible to do this in a way that allows other apps to query weather data directly? For example, as a Content Provider that is protected by a custom permission. Updates can still be notified via intents, but the target app would need to query the CP for actual weather data upon receiving the broadcast. BTW, I wonder how these limitations interact with our architecture.

A third-party app that is just installed will have no access to any information until the first refresh happens, which can cause problems when, say, I want to provide a list of cities for the user to choose when configuring a widget.

One downside is that this might mess with some automation that rely on intent extras and does not have the ability to query content providers (say, Tasker).

[papjul]

For example, as a Content Provider that is protected by a custom permission.

I didn't know about that, that looks better indeed! However, the broadcast has the advantage to send only when there is updated data, to avoid apps querying us every 30 minutes, if background updates are configured to be every 3 hours.

A third-party app that is just installed will have no access to any information until the first refresh happens, which can cause problems when, say, I want to provide a list of cities for the user to choose when configuring a widget.

Breezy Weather will send the information as soon as you enable the setting, you don't need to wait for a refresh. If already enabled, just turn it off and back on.

[papjul]

The goal of #828 is to make broadcast explicit (the user chooses which apps they want to send broadcast to), so I don't think we would be affected by these limitations.

[kmod-midori]

Other apps do not need to poll the provider with a timer, instead they request information from the provider whenever they see the broadcast.

This has the advantage that if the app somehow missed the broadcast (maybe due to other system-level background limitations, very common these days), they are still able to obtain up-to-date weather information when needed at any time.

[joserebelo]

Instead of a Broadcast, maybe you could consider a ContentProvider:

• Can be placed behind a dangerous permission, which requires the user to explicitly accept it
• Allows apps to subscribe to updates using a ContentObserver, which is not subject to the background intent limitations, nor does it need polling.
• Would not be subject to the same limitations we are seeing in #1349

Gadgetbridge consumes data from a read-only ContentProvider from Catima, for example.

The ContentProvider should have a different path depending on the application ID, so that multiple app versions can be installed in parallel (eg. debug vs release).

EDIT: I searched through this issue and missed the first comment... searched for ContentProvider instead of "Content Provider" :')

[kmod-midori]

Based on my reverse engineering of Samsung's Weather app (which was required for my custom widget), they also uses ContentProviders to allow other apps to consume its weather data, potentially with extra permissions to protect sensitive information including location.