swift – Methods to run code within the background on iOS? Undecided which methodology is smart

First, it isn’t attainable to generate “periodic” (i.e. occurring at a particular interval) occasions of any type in iOS that persist indefinitely. Nevertheless it would not sounds such as you want that. There isn’t any must sync knowledge to the server when the person hasn’t modified any knowledge.

The use case you are describing is exactly what background transfers are designed for. Whereas they’re usually mentioned by way of downloading giant information, the identical approach is acceptable for uploads. Background uploads will proceed to run within the background, even when your app is terminated. They’re dealt with totally by the OS, not your app.

To ensure that your add duties to proceed operating within the background, they must be created on a background-capable URLSession. The default .shared session just isn’t background-capable.

Equally to how it’s described within the background obtain docs, the steps are:

• Create a background URLSessionConfiguration utilizing .background(withIdentifier:).
• You in all probability wish to set .sessionSendsLaunchEvents to false, so your app is not re-launched when the add completes.
• Setting .isDiscretionary is a judgement name. The way in which you have described it, you might have considered trying this feature. However watch out if this can be a syncing engine. It could be a really very long time earlier than the add runs.
• With the configuration set, create a URLSession.
• Create a activity with uploadTask(with:fromFile:). You can’t use a completion handler or async model right here. You’ll be able to solely add a file from disk.
• Chances are you’ll wish to set earliestBeginDate to delay the add. This may make it simpler to cancel uploads if there is a new model to sync earlier than the add begins.
• It’s useful to set countOfBytesClientExpectsToSend and countOfBytesClientExpectsToReceive to assist the system schedule the duty appropriately.
• Begin it with resume().

When your app is launched, you possibly can recreate the session with the identical identifier (that is usually only a static string), and use getTasksWithCompletionHandler to get a listing of all in-progress duties. This may can help you cancel uploads that have not began but if you wish to make a brand new activity.

You doubtless don’t want beginBackgroundTask except establishing for the sync takes non-trivial time. If that’s the case, then you may bracket that setup with a beginBackgroundTask and endBackgroundTask to assist stop it from being interrupted.

You additionally in all probability do not want BGProcessingTaskRequest. I’d in all probability schedule all of the sync operations whereas within the foreground. But when making ready for the sync is time or battery intensive, then it might make sense to push all of that work right into a BGProcessingTaskRequest, and kick off the add on the finish. That’s what they’re for. However there is no want for it simply to carry out the add. That is simply the identical as specifying isDiscretionary.

Whether or not you mix your whole uploads right into a single file and create a single add request, or create tons of of small add requests is as much as you. Each have their advantages, and rely on how your sync engine works. The system is certainly able to dealing with tons of of requests with out bother. However I do advocate setting taskDescription that will help you hold observe of the duties. It might probably even be used to encode helpful knowledge concerning the activity. Its contents are totally as much as you. You must also concentrate on use taskIdentifier, which can uniquely determine every activity.