Skip to content

Add Background Location support & fix background GPU usage#385

Merged
sarahcodes100 merged 8 commits intomasterfrom
gpuIssuesFix
Nov 21, 2017
Merged

Add Background Location support & fix background GPU usage#385
sarahcodes100 merged 8 commits intomasterfrom
gpuIssuesFix

Conversation

@msmollin
Copy link
Copy Markdown
Member

@msmollin msmollin commented Nov 1, 2017

Overview

This fixes #378 and additionally adds support for background location mode updates in the main location manager.

Proposed Changes

@msmollin msmollin changed the title Fix Background GPU Usage [WIP] Add Background Location support & fix background GPU usage Nov 17, 2017
@@ -13,3 +13,9 @@ protocol ApplicationProtocol {
}

extension UIApplication: ApplicationProtocol {}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think we should rename this file to be more generic now that it doesnt just contain application extensions?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, yep. Will update.

*/
open func canEnableBackgroundLocationUpdates() -> Bool {
if UIApplication.shared.backgroundRefreshStatus != .available { return false }
if !isAlwaysAuthorized() { return false }
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can simplify these two lines to just return isAlwaysAuthorized()

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I see that? isAlwaysAuthorized() (which just checks CLLocationManager.authorizationStatus()) doesn't necessarily reflect the current backgroundRefreshStatus which is a separate setting in iOS apps. Here's Waze, for example:
screen shot 2017-11-20 at 11 09 10 am

//MARK: - Application Lifecycle Observance
func observeLifecycleNotifications(notificationCenter: NotificationCenterProtocol = NotificationCenter.default) {
notificationCenter.addObserver(self, selector: #selector(applicationWillResignActive), name: .UIApplicationWillResignActive, object: nil)
notificationCenter.addObserver(self, selector: #selector(applicationWillEnterForeground), name: .UIApplicationWillEnterForeground, object: nil)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we use UIApplicationWillEnterForeground instead of UIApplicationDidBecomeActive?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm I think I misread UIApplicationWillEnterForeground vs DidBecomActive description in the lifecycle docs. Basically I thought that DidBecomeActive would get called when the application became active regardless of foreground or background status. This can happen if your app uses background refresh via silent push notifications. In that scenario, we don't want the GPU to start rendering.

However, re-reading the docs (https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1622956-applicationdidbecomeactive), it seems that DidBecomeActive is the appropriate time to restart GPU interaction. Will fix.

- parameter seconds: How long the animation should last.
*/
open func animate(toPosition position: TGGeoPoint, withDuration seconds: Float) {
if isInBackground { return }
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We would be fine without the isInBackground tests since we would let a 'pending' animation until the app is brought back from the background. Now, by adding those, we set this to be a no-op when the app is in the background. I think that it would be important to document that depending on what you end up choosing here (no-op vs pending).

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed on documentation for the no-op. Not sure I follow the "pending animation" part? Do you mean on ES 0.9 ? This is still on 0.8 so allowing any calls through to Tangram-es will cause errors?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes, this is still pending for 0.9.0 so don't mind it for now. You could consider changing this behavior when updating to the new version.


/**
Resets the camera on the current location, as well as the zoom and tilt.
Resets the camera on the current location, as well as the zoom and tilt. Can return false if the app is currently backgrounded
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be in the returns block?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah good call. Updated.

- Renamed ApplicationExtensions file to more reflect usage
- Updated location manager for more succinct logic
- Changes from applicationWillEnterForeground to applicationDidBecomeActive
- Updated tests
@sarahcodes100 sarahcodes100 merged commit 5da7ba5 into master Nov 21, 2017
@sarahcodes100 sarahcodes100 deleted the gpuIssuesFix branch November 21, 2017 15:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

3 participants