⬆️ UIBackgroundFetchResult ordinal mapping

[Kymer]

Currently in the setMethodCallHandler block of backgroundMethodChannel a UIBackgroundFetchResult is created using the flutter result Int like so:

UIBackgroundFetchResult(rawValue: UInt(fetchResult))

We shouldn't rely on the internal ordering of UIBackgroundFetchResult cases, as they could change with future iOS releases.

[timrijckaert]

Actually this was an idea we already discussed with @jeremie-movify and @petermnt before.
The return of a boolean was a MVP approach.

Ideally we would want to return some sort of enum representing the success state of a background task.

Android already expects either a:

• Result.failure()

  • Used to indicate that the work completed with a permanent failure. Any work that depends
    on this will also be marked as failed and will not be run. If you need child workers
    to run, you need to return Result.Success() failure indicates a permanent
    stoppage of the chain of work.

• Result.success()

  • Used to indicate that the work completed successfully. Any work that depends on this
    can be executed as long as all of its other dependencies and constraints are met.

• Result.Retry()

  • Used to indicate that the work encountered a transient failure and should be retried with
    backoff.

As of now (0.0.12) the plugin will map the returning bool as following:

• false -> Result.retry()
• true -> Result.success()

I thought the iOS return code was similarly mapped.

We could then have something like:

void callbackDispatcher() {
  var result = Result.retry
  Workmanager.executeTask((task) async {
    switch (task) {
      case simpleTaskKey:
       print("do some background work");
       result = Result.success
        break;
    }

    return Future.value(result);
  });
}

[petermnt]

This issue is actually about something else.
The iOS code maps an int (0, 1, 2) to an enum. But it uses the 'index' of the enum for getting the right enum.
At the moment they are in a certain order, but if the order ever changes, the int -> enum mapping would break.
A proper switch case would fix this.

[timrijckaert]

Ok I misunderstood I'll open another ticket for the idea from above 👍