Background refactor

[fjcaetano]

The background worker needs to be revisited. I understand it's to create the notifications but it's absolutely draining battery.

Checking on my phone battery usage, it has consumed 83% of the battery and has been running in the background for 8.9 hours.

Isn't it possible to achieve the same using background fetch instead of location updates?

[istornz]

The main problem is the restriction imposed by Apple...
When you disable location update, you can run background mode while 3 min max. The "hack" is to refresh location to let the app active.
We are currently searching a new way but it's not very simple... :/

[fjcaetano]

I guess one idea is using a third party app like Boxcar or Pushover and let the server handle the notifications. It would be notified through another app, but it's a notification nonetheless

[markvl91]

That doesn't change the fact that our app needs to fire something off to get the notifications there. This means we need a background mode that isn't as restrictive as Apple's.

A way around it is setting up a complete server which is actually capable of handling Apple Push Notifications. This is a pretty costly solution though.

[fjcaetano]

Those services I mentioned allow for push to be sent to their apps by sending a simple HTTP request. So when the server detects that a pokemon that should be notified is found, it can trigger that request.

It's true that it is their app that will be notified instead of iPokeGo and the user will have to have both apps installed if he wants to receive push notifications, but it is a solution that requires no implementation in the fronted apps (iOS or Android), purely on the server side, not to mention that it is free and solves the battery problem.

[nileplumb]

I'm going to assume this is why all my data for the month got used in one day :( 1.6GB used by iPokeGo ouch

[markvl91]

That's due to PokemonGo-Map's inefficiency. I've added delta updates to the raw_data call in my setup, this reduced data usage by nearly 100x.

[fjcaetano]

Another approach to the data consumption issue: add a "WiFi only" option to the background mode.

[fjcaetano]

BTW, I've requested that the servers compress the requests using gzip or some other library. For me, a request for a scan of 5 steps returns 200KB, which means that, in background, my app is consuming ~864MB/day.

Gzip averages compression at 30~40%, if I'm not mistaken, which means that data consumption could go down to 260MB (which is still a lot) without any changes in frontend clients