Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request authorization Always doesn't return after being changed in Settings #18

Open
ricsantos opened this issue May 9, 2018 · 9 comments

Comments

@ricsantos
Copy link
Contributor

ricsantos commented May 9, 2018

Latest PromiseKit 6.2.6, which kindly had a fix for #16 in it (🙏) seems to have introduced a regression.

The same test app can be used to reproduce the issue, but with a different sequence of events.

Steps:

  • run app
  • on the first 'When In Use' alert select 'Allow'
  • on the second 'Aways and When In Use' alert select 'Only While Using the App'

Expected result:

  • promise chain completes and print's tada

Actual result:

  • chain does not complete

Also of note, subsequent launches of the app will fail to complete the chain.

@mxcl
Copy link
Member

mxcl commented May 9, 2018

Oh geez. This stuff is not particularly testable, so we have no tests. Sorry.

@mxcl
Copy link
Member

mxcl commented May 9, 2018

Yeah I can see why this would happen, though I'm surprised it didn't happen before.

@mxcl
Copy link
Member

mxcl commented May 9, 2018

Not a regression, Apple don’t fire any CLLocationManagerDelegate method at all when the user chooses the when In Use option for the upgrade alert.

So… not sure if we can even detect this.

@mxcl
Copy link
Member

mxcl commented May 9, 2018

We can probably listen for the became foreground system notification, but this is a hack.

@mxcl
Copy link
Member

mxcl commented May 9, 2018

I guess our only option is to reject the promise when attempting to upgrade and output a warning to the console telling the user to upgrade manually with a link to this ticket.

@ricsantos
Copy link
Contributor Author

Oh dear, you are indeed correct. I think this is worthy of a TSI.

@ricsantos
Copy link
Contributor Author

So I created a TSI with Apple yesterday, and received a response today:

Obviously, there is no “authorization did not change” notification sent to apps.

One thing you can check is the applicationWillResignActive() and applicationDidBecomeActive() app delegate methods (or the corresponding notifications) to know when the user has returned from the prompt.
When the system prompt pops up, you app will resign active. You can check this state (and the knowledge that you have just asked for authorization) to determine it is time to check what the auth level is when the applications becomes active again.

I agree this feels rather hacky.

@ricsantos
Copy link
Contributor Author

I updated the 'CoreLocationTest' to have an implementation of requesting authorization using application state notifications instead of the location manager delegate. It works, as expected, but also requires a piece of persisted state haveRequestedAlways to know if the always alert will be shown or not.

This probably isn't a suitable solution for PromiseKit though, which is a shame.

@mxcl
Copy link
Member

mxcl commented May 11, 2018

Nice research.

My main issue with using the resign active stuff is some other system event could trigger it, eg battery low. So the promise cannot be 100% reliable. Well, at least it seems like we couldn’t be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants