HS Buddy seems to consuming battery power running in background

[gotcl2]

Is there anyway that HS Buddy can be taylored more to help decrease the amount of power it is consuming in the background? I am by no means a programmer... I do have some experience with geofencing when I used to work for Apple and I remember they were able to decrease power consumption in the background by telling the system to poll less when an SLC isnt detected and to check more once it is moved outside of its static geolocation I believe. Not sure if that is entirely accurate anymore. Just curious if any one else has experienced this issue... Seems like it has become worse this past month, not sure if an update was pushed out though.

Thanks!

[avargaskun]

Hi gotcl2 - thanks for the post. There has been some work around optimizing the use of location data to preserve battery power. I presume your device is running iOS? I have been running HSBuddy with Geolocation enabled for a really long time now and even after several app and OS updates I have not noticed an increase in battery drain. However, different conditions will likely generate different results. I can offer to look into this more in a future release, there are a couple tweaks I have not tried yet. However, here's a quick rundown of what the app is doing today to attempt to save battery:

1. In both Android/iOS, the app will request access to Health and Fitness data. That information gives it the ability to detect when the device changes between being stationary to 'active' (whether that is walking/running/driving/etc.). When 'inactive' the app will not try to retrieve geolocation data (nor will it update the server). This setting cannot be changed in the app, it's always on by default. This attempts to save battery by reducing usage of the phone's location services.
2. When 'active' the app will request location data at a given interval (30 seconds, not configurable) and it will send the new location to the server only after the location has changed significantly (10 meters, not configurable). The threshold is 'elastic' , meaning it will adjust based on the speed you're moving at, to lower the amount of updates sent to the server. This attempts to save battery by reducing the number of times the app sends update to the server.
3. There is a slider in the Server/Settings/Geolocation section of the app which lets you configure the accuracy of location retrieved by the app. Based on this setting, the app will decide whether to use WiFi, Cellular or GPS signals to determine the location of the device. This attempts to save battery by reducing use of GPS and relying instead on other signals to determine location.

The one thing I have not tried yet is using Apple's Significant Location Change API. The reason why I didn't use this in the first place is because it reduces the accuracy to ~1Km. I think in combination with other signals (such as visible WiFi networks and GSM antennas) the OS may still give up a reasonably accurate output. I can add a setting in the app to toggle this ON/OFF. I can't promise how quickly I will get to this, but I've added it to the list of things to-do.

UPDATE: I guess one thing I could recommend is double-check that the app has permissions to access fitness and location data, otherwise some of the optimizations I mentioned above will not take effect.

[gotcl2]

avargaskun Thanks for the info. I did check over the items you listed above an all are as they should be. I did previously reduce the accuracy tolerance and it doesnt seem to have made too big a difference. Does the app behave differently while within a geofence? ie: does it check less or more often for change of location? I do believe when the SLC API came out, this was to help improve battery life while using geofencing. I might have an engineer friend I could ask.

Let me know if/when you try the SLC thing, I would be happy to help test.

-Adam

[joegr]

I am having this extreme battery drain problem too. HSbuddy is not listed as one of the apps getting health data, and I've had no prompt asking to allow it or not.