Background Fetch Alternative

[CasperCL]

Recently I saw some discussion here on this problem. Right now we use background refresh to check if the screen temperature must change, however this isn't very reliable, because it requires the screen to be enabled to change the colour. Now the latest problems with battery of the Facebook app set me thinking. What if we let the background fetch determine whether it's time to switch, and as soon it's time to switch we enable 'Audio background' playing. This allows the app to change the screen colour as soon as the device is unlocked, because it can continuously run in the background. We disable the 'Audio background' thereafter to keep the battery usage to a minimum. I might be wrong on this idea, because I've never played around with the 'Audio background' mode. What do you think?

[CasperCL]

So it seems this is possible. I'm writing this down for reference: http://stackoverflow.com/questions/28054669/continuously-run-an-ios-app-in-the-background-even-after-sleep-or-reboot I'm going to look into it this weekend.

[thomasfinch]

These solutions aren't really ideal and I would like to avoid them if possible. Staying awake in the background would be nice for the app functionality but could potentially have a big impact on battery life. Likewise background audio could be battery intensive and would have the downside of not allowing the user to play any music or audio from other apps in the meantime. I'm open to using either, but as I told someone before please test any backgrounding changes on your own device for a few days to make sure it doesn't negatively impact battery life before putting in a pull request. I really don't think the current method of using background fetch is bad at all, it has very little battery impact and usually triggers a color switch within half an hour of the set time for me. Obviously this isn't the best it can possibly be but it's pretty good for working within the confines of Apple's sandbox.

On Fri, Oct 16, 2015 at 3:40 PM, Casper notifications@github.com wrote:

So it seems this is possible. I'm writing this down for reference: http://stackoverflow.com/questions/28054669/continuously-run-an-ios-app-in-the-background-even-after-sleep-or-reboot

I'm going to look into it this weekend.

Reply to this email directly or view it on GitHub: https://github.com/thomasfinch/GammaThingy/issues/37#issuecomment-148816044

[CasperCL]

Staying awake in the background would be nice for the app functionality but could potentially have a big impact on battery life

Suppose it's only activated around sunset/rise for an hour.. I think this wouldn't drain your battery. But I'll test the app, as I do usual with my software, thoroughly before submitting.

downside of not allowing the user to play any music or audio from other apps in the meantime

Fair point I'll look into it.

[CasperCL]

The audio going mute had to do with my mac trying to play on the same speaker..  😑 So far I'm seeing a increase of battery from 'zero' (no audio in background) impact to 'low' (with audio background enabled). Thus far promising results, but I'll have to make this a bit smarter to safe battery life. I'll also create a switch which can enable this extra reliable/battery draining auto switching method.

[ANGOmarcello]

Where is the advantage of Audio Backgrounding compared to VOIP Backgrounding?

Am 17.10.2015 um 16:04 schrieb Casper notifications@github.com:

The audio going mute had to do with my mac trying to play on the same speaker.. 😑 So far I'm seeing a increase of battery from 'zero' (no audio in background) impact to 'low' (with audio background enabled). Thus far promising results, but I'll have to make this a bit smarter to safe battery life. I'll also create a switch which can enable this extra reliable/battery draining auto switching method.

— Reply to this email directly or view it on GitHub.

[CasperCL]

Good question! Audio Backgrounding gives more control on when the task is running, so you can reduce the battery drainage. Moreover Audio Backgrounding allows you to run in the background continuously, which means it could change the temperature right after you unlock your phone. Thus you wouldn’t have to wait for the 15 min cycle of the VOIP task to kick in.

On 17 Oct 2015, at 17:57, Ango notifications@github.com wrote:

Where is the advantage of Audio Backgrounding compared to VOIP Backgrounding?

Am 17.10.2015 um 16:04 schrieb Casper notifications@github.com:

The audio going mute had to do with my mac trying to play on the same speaker.. 😑 So far I'm seeing a increase of battery from 'zero' (no audio in background) impact to 'low' (with audio background enabled). Thus far promising results, but I'll have to make this a bit smarter to safe battery life. I'll also create a switch which can enable this extra reliable/battery draining auto switching method.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/thomasfinch/GammaThingy/issues/37#issuecomment-148926435.

[ANGOmarcello]

Im not entirely convinced of this approach, is it possible to still play music as user? Also how is this more battery friendly as VOIP backgrounding? (VOIP has an impact of "Zero" and Audio is marked as "Low" in Xcode) Also is it really better to run continuous compared to all 15 minutes?

So to put this next to each other: VOIP is still seen as a battery problem. And Audio as well. I heard in this repo that Facebook used VOIP to steal background time. What I have read though was that Facebook used the Audio Method. I'm not entirely sure now what is true of this so I will try to avoid Facebook in my conclusion.

So comparing how f.lux does things compared with our options I think, that Fetching is entirely not suited for what we want to do. F.lux runs a deamon in the background of your iOS device. We can assume that the deamon of f.lux is not that much of a battery hug. But what does it do?

As far as I know it runs in the background, we don't know if it runs continuously or only partly. But we know it runs. So to achieve the same functionality VOIP and AUDIO are still viable options.

I guess that the deamon also only checks for the time and if necessary triggers a switch (and also plays a transition animation) location data is only fetched from inside the f.lux application because it's data only needed once. That should mean the deamon does for obvious reasons no battery intensive operation like network tasks or using gps. If we stick to the same approach VOIP or AUDIO should be no bigger Battery problem then f.lux itself.

So with AUDIO we have the ability to check as offten as we want if it is time to switch and with VOIP every 15 minutes (We also could increase this amount of time for VOIP or decrease it up to a minimum of 10 minutes.) The question is do we need it to be switched on the minute? A little analysis of our best and worst case delay: -AUDIO we have no delay at all -VOIP we have a delay of 0 in the best case and a smallest possible worst case of 10-15 minutes depending on how we configure it

The deamon is also launched in the background on system start. (Jailbreak tweaks are reboot persistent.) I don't know if AUDIO is able to accomplish this but with VOIP our ApplicationDidFinishLaunching method is called after system start so that our reboot persistence code can be called right after the user has unlocked his device after a reboot.

Please make your own conclusions and share your thoughts.

I use the VOIP method for a few days now and it works like a charm. Anyone who wants to try it on my fork of GammaThingy is a VOIP branch everyone can try out to build his own opinion.

[ANGOmarcello]

You can find a working version of the VOIP Backgrounding here: https://github.com/ANGOmarcello/GammaThingy/tree/VOIPBackgrounding

[CasperCL]

Hi @ANGOmarcello , I was unaware that the application is able to wake the screen. I see no advantages in the approach in Audio backgrounding over your approach of VOIP backgrounding, please create a merge request for it:)