SWIG - C# Calling from UWP Background Task or Extended Execution

I wonder if anyone has tried calling a swig C# wrapper around a C++ library from a UWP Background Task, Extended Execution, or Activation Trigger?

My C# swig wrapper provides functionality written in C++ which handles network calls to services such as cloud etc. It might download or upload files such as documents, images, etc or it might just synchronize them with local on machine copies.

I have been doing lots of reading/research lately on the topic of Background Activation and Foreground Activation from a UWP app. So far, what I have found that:

Background Tasks can run in-and-out-of-process of the UWP app but have limitation to 25 seconds + 5 seconds of execution time.
Background tasks with Application Trigger have limitation to 10 minutes
Extended Execution seem to run until the background task has completed
or...

My goal is to be able to run this application and it will initiate the library (swigged C#) which will do syncing in background. User may or may not work directly with the application, so app can be minimized, covered by another app such as web browser (so not actively used), but the background operation will execute every 10 minutes or so to do its syncing.

Based on my reading and some great help I got so far, I am trying to find a safe path to proceed. These 3 seem to be what I am looking at. Which one is most applicable is still unclear to me.

Has anyone dealt with a scenario like this already that could give some good advice?

Solution

For file download/upload scenarios in the background you can use the BackgroundDownloader/Uploader classes: https://learn.microsoft.com/en-us/windows/uwp/networking/background-transfers

If you need to run long-running sync/maintenance application code tasks in the background without the app actually being run by the user, use a MaintenanceTrigger. This will allow you to run for up to 10min, as frequently as every 15min. However, this task will not run when the device is running on battery. https://learn.microsoft.com/en-us/windows/uwp/launch-resume/use-a-maintenance-trigger

For simple sync tasks in the background when your app is not actively in use, you can use a TimeTrigger. This will also run on battery, but is limited to 30sec execution time for each run (can be scheduled every 15min). https://learn.microsoft.com/en-us/windows/uwp/launch-resume/run-a-background-task-on-a-timer-

If your app is in the foreground and running a synchronization activity that should continue when the app gets minimized or the screen gets locked, use an ExtendedExecutionSession: https://learn.microsoft.com/en-us/windows/uwp/launch-resume/run-minimized-with-extended-execution

If your app is in the foreground and running a synchronization activity should continue even when the user terminates the app, trigger an ApplicationTrigger background task to offload the activity to a background task: https://learn.microsoft.com/en-us/windows/uwp/launch-resume/trigger-background-task-from-app

If the need for synchronization is a triggered from the server-side, take a look at raw push notifications to trigger your app code on the client, even when the user is not actively running your app: https://learn.microsoft.com/en-us/windows/uwp/controls-and-patterns/tiles-and-notifications-raw-notification-overview

AppServices are not a solution here. An AppService is an app-to-app concept, where one app provides a service that another app consumes. This does not seem to be the case here. Btw, the lifetime of the appservice is not 30sec - it can run for as long as the consuming app is in the foreground. But again that's not applicable to your scenario here.