Question: using shareAcrossIsolates with WorkManager tasks

[tobiiasl]

I've been reviewing the available documentation for Drift and WorkManager, but I'm still seeking clarification on a specific use case.

My application requires uploading collections of files to a server using WorkManager tasks. Each task needs to:

• Report upload progress back to the main application.
• Receive signals or messages from the main application (while uploading).

These WorkManager tasks have a constraint requiring internet connection, meaning they could be executed when the main application is not running. Upon the next startup of the application, it needs to retrieve the upload completion status of each WorkManager task.

In a discussion (#3249), it was mentioned: "So as long as the two isolates share a IsolateNameServer instance (I think they do since they're running in the same process), you can use the driftDatabase function from package:drift_flutter with the shareAcrossIsolates: true option)."

However, based on information from Android documentation regarding WorkManager, it seems that WorkManager tasks often run in a separate Android process from the main application. This would imply that they would not share the same IsolateNameServer instance.

Given this potential discrepancy, I'm unsure if the simple setup using driftDatabase() with shareAcrossIsolates: true, as described in the drift_flutter package documentation (https://pub.dev/packages/drift_flutter), is a viable solution for my use case, particularly when the WorkManager task is executed while the main application is closed.

Could you please clarify whether using shareAcrossIsolates: true with driftDatabase() is a reliable approach for communication between the main application and WorkManager tasks?

[simolus3]

However, based on information from Android documentation regarding WorkManager, it seems that WorkManager tasks often run in a separate Android process from the main application

A background thread, sure, but I don't think they use a background process by default? Only the RemoteListenableWorker class (and related classes) are used to control a proper background process that doesn't share memory with the main one.

Could you please clarify whether using shareAcrossIsolates: true with driftDatabase() is a reliable approach for communication between the main application and WorkManager tasks?

Unfortunately the answer is that I don't know because I've never tried that setup. I can tell you that two Dart isolates sharing an IsolateNameServer instance will be able to share drift databases seamlessly, but I don't know if that setup applies here. I assume you could try it yourself by registering a port in the main isolate (IsolateNameServer.registerPortWithName(ReceivePort().sendPort, 'test')) and then spawning a work item that tries to look those up (print(IsolateNameServer.lookupPortByName('test') != null)) if that works, share drift isolates should work too.

[tobiiasl]

Thanks for the swift response! It helped me gain some valuable insights.

I need to support scenarios where the WorkManager task executes even when the main application is not running.

One specific scenario that highlights the challenge is as follows:

1. My main application registers a WorkManager task with a networkType: NetworkType.connected constraint while the device is offline.
2. The task will receive an "upload ID" as an input argument. This ID will be used as a unique identifier when writing progress information to the Drift database.
3. The task is scheduled but not yet executed due to the lack of internet connectivity.
4. The user then turns off their phone.
5. The user turns the phone back on, and it regains internet connectivity.
6. WorkManager now executes the scheduled task, initiating file uploads and writing progress updates to the Drift database, using the provided "upload ID".
7. Sometime after the WorkManager task has started executing, the user launches the main application.
8. The main application needs to listen for and display updates related to the specific "upload ID" written to the Drift database by the WorkManager task.

In this situation, as I understand it, it's highly probable that the WorkManager task and the main application will be running in completely separate Android processes. The WorkManager task would be initiated by the Android OS upon boot and network availability, independently of any existing application process. When the user later launches the app, a new application process will be created.

Given that IsolateNameServer instances are scoped to individual Dart VM instances within a single process, it seems unlikely that the WorkManager task's isolate (running in its own process) would be able to directly access the IsolateNameServer instance of the main application (running in a separate process created later).

[simolus3]

The WorkManager task would be initiated by the Android OS upon boot and network availability, independently of any existing application process

I'm not sure that's true. If I remember correctly, you need to explicitly opt your app in to supporting multiple processes, and it's not easy to do accidentally. The way I understand it, there will be a single process for your entire app that runs if your app has any reason to run (so e.g. if an activity is active or if background work is being executed). Android starts this process when launching your app or background work if the process is not started already. If it's already running, Android will start a background thread within the single process to handle work.

I might be wrong here, but the only way to find out is to try. You can set up a demo work request from within your app to check if Dart running inside a work request has access to ports registered by the main UI isolate or not.