Enabling use of PermissionScope on a per-request basis

[winzig]

NOTE: I haven't been using PermissionScope long, so it's definitely possible I'm tackling this the wrong way, but sometimes I'd like to utilize PermissionScope from within my own app's UI, e.g. to request notification permissions from a UISwitch in my app's interface.

In commit a4fc02d some of the API was opened up which would allow this.

But when using it I discovered situations that weren't working, like if the user had disabled/denied permissions, the alert view couldn't be shown by PermissionScope since it's primary window wasn't being shown. So I modified things to allow me to pass in a view controller on the request*() calls, which can then be passed into the declined/denied alerting methods in those situations.

Next issue was I needed a way to know when the permission request was finished, so I made the authChangeClosure and cancelClosure public, allowing me to set them directly. (Feels a bit hacky, but wasn't sure if it was worth modifying the request*() methods to allow for an optional set of closures instead?)

Finally, in the situation where the permissions were declined/denied, and we're showing the alert to let them know and help them fix it, I needed to know that this had happened, so I created a new public closure property called disabledOrDeniedClosure, and it's called when either of those alert views are shown.

[nickoneill]

Thanks @winzig! I do like this approach: making the callback closures public is the right direction since we can assume that you've looked into the API if you're writing your own UI and just want the unified request/status methods.

I'll take a more thorough look soon and we'll get this merged in.

[nickoneill]

Thinking about this more today, we're still maintaining an instance of PermissionScope when making the now-public requestLocation / requestPhotos / etc. Does it make more sense to create a presentingViewController property during configuration (defaulting to self) and simply use that in show / showDeniedAlert / showDisabledAlert rather than adding it to every request method?

[winzig]

Makes sense to me, especially if that approach is being taken for the other things needed for direct access (like the closures).

[nickoneill]

Great, I'll pull your changes in and then convert the presenting view controller to a property.

[winzig]

Oh, just saw your update. I made a similar change, but obviously it's not hard to fold in either way.

[nickoneill]

No worries, I haven't done any work on it yet.

[nickoneill]

Thanks again for this! If you have a chance to write up a quick example of how you use the non-UI version, please include it here or in the Readme.