Server-driven updates for Widgets

[V3RON]

Feature Description

Widgets should support server-driven updates, not via push notifications but through HTTP requests sent to a Node.js service running Voltra. It should be possible to configure Voltra to include additional data in these requests, such as access tokens for identifying the user on the server.

Problem Statement

In some cases, we want our widgets to update themselves regularly - say, every day. We don't want to ask users to open the app daily just to trigger an update. There should be a way for widgets to pull updates from a remote service automatically.

Proposed Solution

We can reuse Voltra's existing SSR capabilities. What's missing is the client-side part. On iOS, the TimelineProvider backing widgets can send HTTP requests, so this part should be straightforward. Android is trickier, as we need to spawn a background service, but it should be doable.

Alternatives Considered

No response

Current Library Version

v1.1.2

Implementation

• I would be willing to submit a pull request for this feature

Additional Context

No response

[V3RON]

• iOS (Isolation): The widget runs in a separate process. It cannot see the main app's storage by default. You must bridge this gap using Shared Groups.
• Android (Execution): The widget runs in the app's process, but cannot run networking on the main thread (UI thread). You must offload the work to a background scheduler.

---

iOS Approach (Pull-Based)

Goal: Securely share credentials via Keychain Groups so the Widget can pull data itself.

1. Capability Configuration: Enable Keychain Sharing in Xcode for both the Main App and Widget Extension targets. Ensure they both use the exact same Keychain Access Group identifier.
2. Secure Storage (Main App): When the user logs in, save the auth token to the Shared Keychain (targeting the group from step 1).
   • Crucial Security: Set the item accessibility to kSecAttrAccessibleAfterFirstUnlock. This ensures the widget can read the token in the background even if the phone is locked, while keeping it encrypted at rest.
3. Data Retrieval (Widget): Inside the TimelineProvider's getTimeline method, read the token from the Shared Keychain.
4. Network Execution: Perform the HTTP request directly inside the TimelineProvider. WidgetKit manages the background execution time allowance.

---

Android Approach (Push-Based)

Goal: Offload networking to a background scheduler which pushes updates to the Widget.

1. Secure Storage: Use EncryptedSharedPreferences (Android Jetpack Security) to store the auth token. Since Android widgets are part of the main app binary, they inherently share this storage; no special grouping is required.
2. Scheduling (Widget Provider): In the AppWidgetProvider's onUpdate method, do not make network calls. Instead, enqueue a WorkManager task (e.g., PeriodicWorkRequest).
3. Background Execution (Worker): Create a Worker class. Inside doWork(), retrieve the token from EncryptedSharedPreferences and execute the HTTP network request (synchronously or via coroutines).
4. UI Update (Push): Once data is fetched, the Worker must push the update to the widget. Construct a RemoteViews object and call AppWidgetManager.updateAppWidget() to manually paint the new data onto the home screen.

[V3RON]

Open questions:

• What about the existing API for scheduling widget states in the future? Could these two co-exist somehow, or are they mutually exclusive?

[Angelk90]

@V3RON:

1. Are there common parts that both Android and iOS use?
   I'm talking about React Native code.

If there aren't any common parts, wouldn't it be better to split the project into two repositories now, so that those who only need the Android part can download only the Android part or ios?
Before the project gets too big.

2. The part I'm most concerned about is that those who don't use Expo have problems with using the module, which must be converted to Expo, with no small amount of hassle. Being able to use TurboModules, In a project that doesn't use expo, could be a great idea.