I created a new fork with some additional parameters for Android

[alindzon]

I only worked on the Android part because I am not testing IOS yet. But we should use
Deferring location updates
let CLTimeIntervalMax: TimeInterval

the same way I am using interval for Android.

I added these parameters with these defaults. I used seconds instead of milliseconds for the first two, because who needs GPS updates in milliseconds? That said, if someone wants to get it working passing in Long be my guest. I could only get it working with Int parameters for some reason.
call.getInt("interval",61),// interval in seconds
call.getInt("maxWaitTime",0),// maxWaitTime in seconds
call.getInt("numUpdates",0) // how many updates before terminates 0 is infinite

also I noticed LocationRequest sets are all being replaced with LocationRequest.Builder sets. Someone should update the whole thing since it is deprecated.

My fork is at https://github.com/alindzon/background-geolocation with changes to
definitions.d.ts
as well as the android source files
BackgroundGeolocation.java
BackgroundGeolocationService.java

[diachedelic]

What does this pull request accomplish?

[alindzon]

First I want to say how grateful I am that the community created this plugin. Although I have not tested it with IOS yet, I can say it works really well with Android. So great job.

I added those parameters because I needed them. interval - allows you to control how frequently the location is taken, otherwise it is pretty much constant, and I needed to be able to manage it to report much less frequently.

numUpdates is great if you just need one value or any fixed quantity. I use that to take a single reading.

maxWaitTime you were defaulting, so even though I did not need it, why not make it an optional parameter?

I am only suggesting adoption of these or similar options because they increase the utility of the plugin, and as optional parameters they don't have any negative impact, depending on the defaults you choose.

My other comment is just related to the potential for the Android implementation to stop working since Location.set... is deprecated and replaced with LocationRequest.Builder.sets...

[alindzon]

I misread the Apple docs. IOS seems to have a distance filter but not a time delay setting. It appears there was a allowDeffereredLcationUpdatedUntilTravelled that had a distance and timeout parameter. The timeout was really a delay so would solve this problem. CLTimeIntervalMax is a constant that is indefinite which seems kind of useless.

anyone know how we can add a fix delay in seconds to the IOS portion?

[diachedelic]

I am not aware of any way to throttle location updates on iOS except by distance. Even if it were possible to throttle by time, most people requesting this feature (such as #83) want to receive location updates are regular intervals, regardless of the distance travelled. That is different to a throttle.

[diachedelic]

A throttle can easily be implemented in JavaScript, although I suspect that approach uses more battery power than if the throttle was implemented natively.

[alindzon]

I agree with both comments. Yes you can ignore the massive number of unnecessary battery sucking updates in TypeScript or JavaScript, but imagine you want then every 10 minutes and they are occurring every 5 seconds. That is staggeringly inefficient. My application is exactly one where you want timely updates even if there is no movement. No Movement could be important to know for medical reasons.

I was thinking short of IOS adding this back which they should, we easily in the plugin just check time since last scheduled update and ignore updates that are not within x seconds of the requested delay, thus taking the responsibility away from the app to ignore updates it does not want to even see. This would not save any battery, but would allow the interval to be applied on both IOS and Android from the perspective of the programmer using the plugin with the caveat that there will still be lots of unnecessary battery usage by the app. Another option would be to have the watch suspended until x seconds before the time the next reading is needed, turn back on the watch, and then suspend it again as soon as you get an accurate position, which would conserve battery life and in theory would work if implemented in the plugin.

[alindzon]

For the IOS implementation of a controlled pause we could use
https://developer.apple.com/documentation/corelocation/cllocationmanager/1423695-stopupdatinglocation
and
https://developer.apple.com/documentation/corelocation/cllocationmanager/1423750-startupdatinglocation
that would preserve battery and assuming we can manage the start with a timer it would do exactly what is needed.

[diachedelic]

I'm not sure that would work. Stopping the location updates loses the GPS fix. The next time it is started, accuracy will be low and probably a bunch of power will go into finding a fix. That means we will have to wait a while until accuracy improves, but then the locations will not be emitted at regular intervals. Plus, this approach could easily be applied at the JavaScript level, by adding and removing watchers.