Background Refresh

[ANGOmarcello]

Added preparations for background refresh without depending on the iOS background refreshing using this solution.

This solution could also enable a transition animation equally to f.lux.

Also a small design change: App is now longer named "GammaTest" on SpringBoard but "Gamma Thingy"

[gblazex]

Which one is more battery friendly is what the question should be.

[ANGOmarcello]

I think this hugely depends on what you do when your application is active in background. A deamon like f.lux uses is also running all the time. We can implement with this some thing like a non jailbreak deamon.

Seems for me like the only way to implement: -Reliable times for change -Long transition between states

[gblazex]

It seems to be deprecated as of iOS 9: https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplication_Class/#//apple_ref/occ/instm/UIApplication/setKeepAliveTimeout:handler:

In iOS 8 and later, voice-over-IP (VoIP) apps register for UIRemoteNotificationTypeVoIP remote notifications instead of using this method.

[gblazex]

Which is unfortunate because as you said it might be the only way to accurately do those background tasks.

[ANGOmarcello]

Oh sorry I missed that. But I guess pre iOS 9 this could be helpful. :/

Well it could be possible to implement the change with these notifications as well. Maybe we can schedule them to fire in the future and is it possible to create them locally? The fact that this project does not need to be in the App Store should open up some things not intended by apple.

[ANGOmarcello]

This seems to still work despite being deprecated. I use 9.0.2.

So maybe we should just implement it. Just calling [GammaController autoChangeOrangenessIfNeeded]; in the block should do the trick. The question is how offten do we want to check. Setting the value of timeout to 600 equals 10 minutes I'm not sure if it should be checked that offten. Maybe every 15,30 or 60 minutes would be better.

Edit: Maybe the time picker should only allow to select in 15 minutes intervals if it is decided to implement this. F.lux let's you decide in the same measure at least on Mac.

[gblazex]

Sure it works, it's just been deprecated in iOS 9. But it'll be removed in the future, so it's best to search for alternatives.

[thomasfinch]

I've been aware that this is one way to change colors but decided against it because keeping the app alive in the background perpetually is heavy handed. This method wouldn't work if the user chose to kill the app from the app switcher ever, which plenty of users would definitely do, and I think the impact on battery life, which could be pretty significant. I'm not interested in changing to this unless you thoroughly investigate solutions to both of those problems. Also, using notifications for background refresh isn't going to work because that can only be triggered from remote notifications, not local ones, which means there would need to be a server and it wouldn't work when the network connection is gone.

On Tue, Oct 13, 2015 at 3:45 AM, Ango notifications@github.com wrote:

Added preparations for background refresh without depending on the iOS background refreshing using this solution. This solution could also enable a transition animation equally to f.lux. Also a small design change: App is now longer named "GammaTest" on SpringBoard but "Gamma Thingy" You can view, comment on, or merge this pull request online at: https://github.com/thomasfinch/GammaThingy/pull/21 -- Commit Summary --

• -Prepared for background functionality -- File Changes -- M GammaTest/AppDelegate.m (11) M GammaTest/Info.plist (3) -- Patch Links -- https://github.com/thomasfinch/GammaThingy/pull/21.patch https://github.com/thomasfinch/GammaThingy/pull/21.diff

  Reply to this email directly or view it on GitHub: https://github.com/thomasfinch/GammaThingy/pull/21

[ANGOmarcello]

I don't really understand your battery concern. In what way does this drain the battery more then any other scheduled task? Because this is just a sheduled task the application is not active perpetually, it becomes active to perform it's task after a set amount of time

When the App entered the background:

As you can see energy consumption is zero. In addition to that [GammaController autoChangeOrangenessIfNeeded]; does not perform any network activity or heavy lifting processing. So why would it drain battery? Mail apps using this drain your battery because they download data on your phone mostly with mobile data.

The only problem I see is the user exiting the application. It could be possible to circumvent this somehow. If no solution for this is possible it could be opportunistic to use fetching if the application is not in background (inactive) and timeout if it is not manually exited.

[thomasfinch]

I think it's pretty obvious that running an application perpetually in the background is a potential battery killer. I don't know for sure if it is though, which is why I said it needs to be tested thoroughly before it's potentially merged. What I mean is, test it on your device for a few days and make sure it doesn't affect your battery at all.

[luuuke]

Just a note: A possible solution to users killing the app could be preemtively scheduling an UILocalNotification for some time after the next auto change date. If the auto change triggers correctly, just cancel the notification, if not (as the app was exited), the notification will alert the user to open the app or to tap on a "Change orangeness now" button on the (then interactive) notification.

[ANGOmarcello]

@thomasfinch As I told you the application is only in ram till the timeout fires. Using it for the next couple days to proof it. :)

@luuuke sounds to me like the best next thing or using fetching as fallback

[gblazex]

@ANGOmarcello here's once thing to test:

1. Note down Battery Usage & Standby numbers from Settings.
2. Lock your phone for 5 minutes.
3. Check Battery Usage & Standby numbers again.

Standby should be +5, while usage should be +1 minutes max compared to the previous numbers.

(I remember the Facebook app having some kind of way of preventing the phone from going to proper sleep which meant unusual battery drain)

[ANGOmarcello]

The result:

[ANGOmarcello]

@galambalazs yeah I also heard that Facebook thing but they don't use this way because in that case Facebook would not be allowed on the App Store. They used a dirty trick for this.

[gblazex]

So usage grew by +3 minutes (instead of the expected +1). Can you do a control test with GammaThingy app uninstalled?

(so as to make sure what to compare this result to)

[ANGOmarcello]

The result with Gamma Thingy uninstalled was like you expected. I have to note though that Gamma Thingy finds no mention at all in the Battery list and Xcode tells me that it has zero impact.

That is conflicting information. :/

[gblazex]

I'm pretty sure this VoIP keep-alive is what FB used. It was considered dirty as they were not using it for VoIP, not sure why Apple allowed them to.

Battery list mostly measures CPU usage I would think. The issue here is that CPU cannot go to proper sleep mode. But over the long term this can have a big impact (both locked and unlocked).

The best approach - after this initial round - is to do real world testing.

Test 1: Locked battery drain over 8 hours (easiest to do overnight). Test 2: Unlocked battery drain with normal use. e.g. Playing 2 hours of video.

Having these two cases covered with the App both installed & uninstalled you get a pretty good picture of how it impacts battery life.