Question: relation to christocracy plugin

[EGreg]

How is this related to the plugin here: https://github.com/christocracy/cordova-plugin-background-geolocation

I realize that you built yours based on that one, and both seem to be maintained and been around for years. That other one costs money, this one is free. They have slightly different APIs. But is there anything that one does which this one doesn't do? Does yours also support callbacks on both iOS and Android even when app is not running? The author says he switched to using Android FusedLocationProvider. Does it use background app refresh to try to update the location even when the app has been killed on iOS? I figured maybe the geofencing is more advanced there. But can you please explain the difference for someone considering which one to use?

[pmwisdom]

Hey @EGreg.

So the android version is roughly based on an old version of his plugin but they've diverged quite a bit, and yes the android version also supports callbacks.

The iOS version is a complete re-write in swift, and doesn't share any code with christocracys.

I haven't checked out his version in a very long time but the main differences are probably:

A. I use detected activities libraries on ios / android to shut off the GPS when you are standing still instead of using geofencing. This means you can also collect data about how the user is moving as well (walking, driving, etc).

B. Both send callbacks. There is no support for out of the box HTTP requests by the plugin, you have to perform them in your JS (this is because the plugin actually keeps your application alive and there is no need for internal HTTP requests).

C. Free.

The reason for these design decisions is because when I set out to make this plugin I wanted consistent updates and callbacks for all platforms. Using the significant locations library on iOS poses a serious problem to some use cases where you might not be traveling more than a couple blocks in a long span. So instead of setting up geofences or using significant locations to keep your app alive and save battery life, we just turn off GPS while your still and wake it up when you start moving. Doing this, while your moving at least, you always get updates every X seconds (whatever you asked the plugin) instead of updates after you go a couple blocks and then X seconds after you've triggered the significant location change.

[EGreg]

Thank you for answering the questions. I had one in there that I was particularly interested in, "Does it use background app refresh to try to update the location even when the app has been killed on iOS" ... let me explain what I meant:

I know that iOS kills the app from time to time (e.g. to save memory), in which case the background processing wouldn't work unless you have one of the background processing modes . I was asking because Christocracy's plugin seems to make use of the significant locations API to wake the app up even if it was killed.

And on Android it says it uses AlarmManager. But elsewhere it says it uses FusedLocationAPI. Does the latter wake up the app?

In short, I am basically asking how the app is woken up if it was killed by the OS. (I am OK with the app not working in background if it was killed manually, though it seems from the linked docs that SLC still works to wake it up then.) Sorry if the question is kind of arcane.

[pmwisdom]

Nope not inane, I see what your asking. So each platform use different strategies.

iOS: Uses background tasks and our location callback to refresh background task timing execution, this one is a little hard to explain but, generally an app has 10 minutes of execution time in the background, but if you fire off a background task from your received location callback, you can keep launching background tasks through this vector for what seems like forever. I've tested this plugin on an iphone for a few days and it never turned off.

Android: Uses FusedLocationAPI + Detected Activities API + Foreground process + Service Connection to keep the app alive. What this means is that the plugin is literally attached at the hip to your application and it tells the OS that your application should be treated like its in the foreground, even when its in the background, hence the notification on android saying that the application is tracking you. There is a lot more that could be done here to keep the app alive (like the AlarmManager you mention, but in my testing, it hasn't failed yet on my devices.

TLDR: If the app is killed by the OS, there is no strategy in place to retrieve it (yet). All of my code has focused on preventing the OS from ever killing your app to begin with. In testing I find this works extremely well and I didn't need to build in functions to wake up the app if its destroyed.