Optional background tracking taking 5 random times, instead of 5 regular times per day

[DigitalSeneca]

fixes #9

• Schedule a daily task at 00:00 that generated 5 random times for the day to collect the locations and send to the api

[epou]

Important for iOS:

registerPeriodicTask is only supported on iOS 13+, it might run for only 30 seconds due to iOS restrictions, but doesn't start immediately, rather iOS will schedule it as per user's App usage pattern.
⚠️ On iOS 13+, adding a BGTaskSchedulerPermittedIdentifiers key to the Info.plist for new BGTaskScheduler API disables the performFetchWithCompletionHandler and setMinimumBackgroundFetchInterval methods, which means you cannot use both old Background Fetch and new registerPeriodicTask at the same time, you have to choose one based on your minimum iOS target version. For details see Apple Docs

[epou]

The idea of using a unique tag is that when the user disables the background tracking in the settings page, pending tasks could be canceled by using: Workmanager().cancelByTag("tag");

[DigitalSeneca]

The idea of using a unique tag is that when the user disables the background tracking in the settings page, pending tasks could be canceled by using: Workmanager().cancelByTag("tag");

Another option is to just await Workmanager().cancelAll();

[epou]

In the scenario where various tasks are concurrently running in the background, employing Workmanager().cancelAll(); might not be the most efficient approach. Instead, it's advisable to selectively cancel only those tasks associated with backgroundTracking. That's why I came up with the solution of employing a consistent tag for all tracking-related tasks. This tagging system allows for grouping these tasks together, facilitating their cancellation using a unified tag, regardless of individual task names.

[DigitalSeneca]

Important for iOS:

registerPeriodicTask is only supported on iOS 13+, it might run for only 30 seconds due to iOS restrictions, but doesn't start immediately, rather iOS will schedule it as per user's App usage pattern.
⚠️ On iOS 13+, adding a BGTaskSchedulerPermittedIdentifiers key to the Info.plist for new BGTaskScheduler API disables the performFetchWithCompletionHandler and setMinimumBackgroundFetchInterval methods, which means you cannot use both old Background Fetch and new registerPeriodicTask at the same time, you have to choose one based on your minimum iOS target version. For details see Apple Docs

I've added the setup for iOS but I can't test it without a device
I've also removed some transistorsoft settings that were still there from the previous location system

In the scenario where various tasks are concurrently running in the background, employing Workmanager().cancelAll(); might not be the most efficient approach. Instead, it's advisable to selectively cancel only those tasks associated with backgroundTracking. That's why I came up with the solution of employing a consistent tag for all tracking-related tasks. This tagging system allows for grouping these tasks together, facilitating their cancellation using a unified tag, regardless of individual task names.

Okey, so the daily task is still executed, but if there's no permission enabled, we just skip it and don't schedule the 5 tasks for the day?

[epou]

Okey, so the daily task is still executed, but if there's no permission enabled, we just skip it and don't schedule the 5 tasks for the day?

I was considering halting all background tracking tasks if the user disables that option in the settings page. However, if you believe it's more efficient to keep the scheduler running and simply refrain from scheduling any tasks when the option is disabled, feel free to proceed with that approach.

[DigitalSeneca]

Okey, so the daily task is still executed, but if there's no permission enabled, we just skip it and don't schedule the 5 tasks for the day?

I was considering halting all background tracking tasks if the user disables that option in the settings page. However, if you believe it's more efficient to keep the scheduler running and simply refrain from scheduling any tasks when the option is disabled, feel free to proceed with that approach.

We can halt all tracking tasks, including the one with tag 'scheduleDailyTasks', but then I don't see the performance improvement of cancelling by tag instead of cancelAll();, when we're going to cancel all tasks anyways

[epou]

Okay! We should only need extra care if in the future we add any other kind of task that is not related to background tracking, and only cancel these.