Technical solution to trigger new actions when the device goes online

[maxme]

User is offline, creates a draft, edits of published post and then saves it locally while offline. We need a technical solution to upload this draft, or remote auto-save the post when the device goes online.

We recently made some changes to upload drafts when the user refresh the post list. This is a good first step, but we want to achieve this whatever screen is shown to the user, if the app is hidden or eventually if the app is closed.

Corresponding iOS ticket

wordpress-mobile/WordPress-iOS#11640

Affected Issues

These issues may be affected by the result of this discussion.

• Offline Support: Local drafts aren't synched when going back online. #9568
• Trigger an auto-upload or remote auto-save to preview drafts or published posts #9728

Tasks

These will need to be done after this discussion.

• Create follow up issues

[malinajirka]

I think the ideal goal is to have a WorkManager which starts a service

• periodically - once a day perhaps
• after the device becomes online and a certain period elapsed since the last upload

I'd definitely consider reusing the UploadService. It works pretty well and I don't think we should try to rewrite it. Someone mentioned they'd create another service which would queue stuff for the UploadService. I have never tried it, but my gut tells me starting one service from another might bite us

• both services would need to be foreground services and we'd need to show two notifications, right?
• I'm not sure how WorkManager handles wake-locks, but I feel like we might encounter other issues if we had two services

Moreover, AFAIU we only need to start the UploadService with an intent indicating it should upload all pending items as the UploadHandlers (MediaUploadHandler, PostUploadHandler) already support queueing multiple uploads.

What we need to watch out for

• show just a single notification -> (it seems the PostUploadNotifier already handles it for us)
  • Should we show a number of in-progress/successful/failed uploads?
  • What happens if the user clicks on the notification?
• What do we do if one/multiple uploads fail? Do we show a single notification for all the fail uploads when the uploads fail for example 3 times in a row?

[malinajirka]

I published the comment unintentionally before I was done with it :head-bang:.

But basically one last thing I noticed while scanning the UploadService is that it does a lot of the work on the main thread. I think we should make sure to do basically everything on a background thread. Wdyt?

[maxme]

I think the ideal goal is to have a WorkManager which starts a service

Yes it seems like the best way to achieve this.

I'd definitely consider reusing the UploadService. It works pretty well and I don't think we should try to rewrite it. Someone mentioned they'd create another service which would queue stuff for the UploadService.

I thought about another service because we could use it for other parts of the app, not only for posts and pages, but also for comments or other features. Anyway I'm not a fan of making things too generic and complex for no reasons. We can do a first implementation in the UploadService first, and if we need it, we'll make it more generic or split into 2 services.

What do we do if one/multiple uploads fail?

Good point about error management, I'm not sure what's the best solution.

Also something to keep in mind: since the user won't explicitly ask for an upload they might be confused if we show some errors later when they close the app. Maybe we could do a few automatic retries before showing an error?

[shiki]

Based on my short experience with WorkManager, it is unreliable if you want to have a job executed immediately. This is corroborated by the documentation:

WorkManager is not intended for in-process background work that can safely be terminated if the app process goes away or for tasks that require immediate execution.

That may be something we should look at if we decide to use it.

@malinajirka, I'd like to hear more about how we connect WorkManager and UploadService together. For example, does this mean that call sites will no longer communicate directly with UploadService but communicate with WorkManager instead?

I think the ideal goal is to have a WorkManager which starts a service
after the device becomes online and a certain period elapsed since the last upload

@malinajirka, how do you envision this to work? Will a WorkRequest be created beforehand?

[malinajirka]

Also something to keep in mind: since the user won't explicitly ask for an upload they might be confused if we show some errors later when they close the app. Maybe we could do a few automatic retries before showing an error?

I completely agree!

Based on my short experience with WorkManager, it is unreliable if you want to have a job executed immediately. This is corroborated by the documentation:

WorkManager is not intended for in-process background work that can safely be terminated if the app process goes away or for tasks that require immediate execution.

That may be something we should look at if we decide to use it.

@malinajirka, I'd like to hear more about how we connect WorkManager and UploadService together. For example, does this mean that call sites will no longer communicate directly with UploadService but communicate with WorkManager instead?

I completely agree with everything said above. I think we should use the WorkManager just for the periodic/(*on internet connection changed) uploads. I'd still start the UploadService manually from the app when we want to start the upload immediately.

I think the ideal goal is to have a WorkManager which starts a service
after the device becomes online and a certain period elapsed since the last upload

@malinajirka, how do you envision this to work? Will a WorkRequest be created beforehand?

I haven't thought this through completely, but this is what I had in mind.

1. Create PeriodicWorkRequest which runs every 24 hours with "CONNECTED/NOT_ROAMING" NetworkType and requiresBatteryNotLow constraints.
2. When the user invokes an upload action, check internet connection:

• Connection available: Start the UploadService manually
• Connection not available: Create one time WorkRequest with "CONNECTED/NOT_ROAMING" NetworkType constraint.

3. (*I'd even consider keeping the on internet connection changed logic which uses ConnectionStatusLiveData when the app is in the foreground. The worst case scenario is that the WorkManager tries to start the service and it's already started or it finishes itself immediately as there won't by anything to upload.... This would depend on how much delay does the WorkRequest have after the device regains connection.)