iOs permission requests not synchronous

[peterbodo]

Your Environment

• Plugin version: 4.14.6
• Platform: iOS
• OS version: 15.8.2
• Device manufacturer / model: Iphone 7 Plus
• React Native version (react-native -v): 0.72.5
• Plugin config

  {
  locationAuthorizationRequest: "Always",
  backgroundPermissionRationale: {
      title: "Engedélyezed, hogy a {applicationName} hozzáférjen a helyadatokhoz a háttérben?",
      message:
          "Azért, hogy a háttérben is rögzíthessük az utazásaidat, kérlek engedélyezd a helyadatokat {backgroundPermissionOptionLabel} formában",
      positiveAction: "Váltás {backgroundPermissionOptionLabel}-re",
      negativeAction: "Mégsem",
  },
  desiredAccuracy: BackgroundGeolocation.DESIRED_ACCURACY_HIGH,
  distanceFilter: 2,
  desiredOdometerAccuracy: 100, 
  allowIdenticalLocations: true,
  stopTimeout: 60,
  debug: false,
  logLevel: BackgroundGeolocation.LOG_LEVEL_OFF,
  stopOnTerminate: true,
  startOnBoot: false,
  url: `${BASE_URL}telemetry`,
  batchSync: true,
  maxBatchSize: 200,
  autoSync: false,
  extras: { session: sessionId, telemetryEvent: "COLLECT" },
  locationTemplate,
  headers: {
      "x-carbontracker-authtoken": accessToken,
      "x-carbontracker-userid": userId,
  },
  notification: {
      title: "Step2Stop",
      text: "Utazás rögzítése folyamatban",
  },
  }

Expected Behavior

Permission requests pause code, after requests given code continues.

Actual Behavior

at #start permissions are asked. code after start never runs code runs on Android!

Steps to Reproduce

1. new install without permissions
2. Below code run:

            onLocation = BackgroundGeolocation.onLocation(async (location) => {
                await setDashboardValues(location);
            });
            const sessionId = uuid.v4();
            const options = getBackgroundGeolocationOptions(
                sessionId,
                userId,
                accessToken
            );
            await BackgroundGeolocation.setConfig(options);
            await BackgroundGeolocation.start();
            await BackgroundGeolocation.resetOdometer();
            await BackgroundGeolocation.changePace(true);
            setIsTracking(true);
            setSeconds(0);
            setTimerOn(true);

4. permissions given
5. code never coninues to run

[christocracy]

I don’t see that you’re calling .ready(config)

[peterbodo]

Since the docs says that ready can be called once and only once, I call it from a useeffect at first render. Since we have several sessions with changing config we use only setConfig each time.

const initBG = async () => {
    const accessToken = await getFromStore("accessToken");
    const userId = await getFromStore("userId");
    const sessionId = "init";
    const options = getBackgroundGeolocationOptions(
        sessionId,
        userId,
        accessToken
    );

    await BackgroundGeolocation.ready(options);
};

    useEffect(() => {
        initBG();
        return () => {
            if (onLocation) onLocation.remove();
        };
    }, []);

[christocracy]

See wiki “Debugging”. Configure the plug-in for verbose logging, enable debug: true, launch your app in XCode and observe the logs of your app launching.

[peterbodo]

I don't own a mac :)

BTW the code continues to run perfectly in android. And in ios if I kill the app and relaunch (now, with previously given permissions) the tracking starts as expected.

It looks like that during permission requests in iOs the app is somehow losig track where it paused to run code.

[christocracy]

I don't own a mac :)

How do you expect to efficiently develop a cross-platform app without the ability to debug locally?

Create for me a simple “hello-world” app which reproduces the problem and share it in a public GitHub repo so I can try it myself.

[peterbodo]

okay, thanks for the offer, but went biking and realised that the demo app would be an overkill (at least to produce by me), So I rather channeled error messages to the server.

Now, what I see is that immediately as the permission dialogues appear an error:1 happens. This tells me that onlocation is already triggered and the error is of course location permission denied since ther was not yet a chance to select a permission.

With the exact same app on android, there is no error. there is no onlocation event until all the permissions are selected.

what worries me is that if I understand well it is #start, which handles both permissions and starting to get locations as well, so there is no way that I listen to an event of permission changes and start getting locations manually.

[peterbodo]

(In Android even the activity indicator stops circling, whil I select permissions. On the other hand on iOs it keeps making circles.)

[christocracy]

I don’t understand your problem.

show me logs.

see api docs “Logger” and learn to use the .emailLog method.

[peterbodo]

ok I will, but the problem is that onlocation starts firing on ios as soon as permission dialogues come up, and since no permission was given yet, it throws a locationerror:1

[christocracy]

Have you read the api docs for onLocation?

If you were watching the logs and not scurrying about blindly developing an iOS app without a Mac, you’d see a warning in the logs about not providing the optional 2nd argument locationErrorCallback to onLocation.

[peterbodo]

Also my code is in a try/catch block. I just realised that my main problem is that after the locationerror the other code part stops executing.

Nevertheless the root cause is onLocation firing too early.

In the meantime I have read your comment. Okay this will be the way to go

still don't understand why onlocation is firing, but anyway. catching an error was never a problem.

[christocracy]

still don't understand why onlocation is firing, but anyway. catching an error was never a problem.

Because you didn’t provide the 2nd argument to onLocation, the plug-in has no other option to inform you an error occurred but to send it to the only callback you did provide to onLocation.

Read the api docs onLocation

[peterbodo]

Have you read the api docs for onLocation?

I think maybe sometime :) And really grateful for the excellently documented project, but if we are realistic it is impossible to read (and especially learn) all the docs of all the libs we use.

If you were watching the logs and not scurrying about blindly developing an iOS app without a Mac, you’d see a warning in the logs about not providing the optional 2nd argument locationErrorCallback to onLocation.

Poor developer cooks with water :)

But anyway. Thanks a million. That will be the solution.

[peterbodo]

I just wanted to share with you that the locationerrorcallback has solved the problem. And also do not put those in a try catch.

Thanks a lot for your help.

And still I think it is worthwile investigating that android hangs up until permissions are dealt with, but iOs not.

[christocracy]

And still I think it is worthwile investigating that android hangs up until permissions are dealt with, but iOs not.

These are completely different operating systems. I have no control over how the OS handles their permission dialogs.