Skip to content
This repository has been archived by the owner on Feb 27, 2019. It is now read-only.

Minor Bluetooth fixes #108

Closed
wants to merge 5 commits into from
Closed

Minor Bluetooth fixes #108

wants to merge 5 commits into from

Conversation

cgst
Copy link

@cgst cgst commented Oct 14, 2015

Addresses #106, but maybe having a configurable flag that defaults to true is better instead
Addresses #107

@cgst
Copy link
Author

cgst commented Oct 14, 2015

This seems to block PermissionScope.show() at
while self.waitingForBluetooth ...

@cgst
Copy link
Author

cgst commented Oct 14, 2015

I've updated this to ask for bluetooth permissions without calling start/stop advertising, and without blocking the main thread.

The iOS Bluetooth permission dialog seems to trigger only once per bundle ID; restarting/reinstalling the app doesn't trigger it again.

@nickoneill
Copy link
Owner

@felix-dumit This commit (from issue #107) replaces the call to start/stop advertising with just creation of the bluetooth manager. This seems to request the permission just fine for me but I recall something about this in your original commit for bluetooth support. Was there some situation that required the start/stop calls?

@felix-dumit
Copy link
Contributor

So I tested and it did work, but I could swear before by just instantiating the manager the system permission would not show up.
Finally I remembered that when I was developing I was testing using the Objc-Example and that in fact is the issue here.
By running the swift example it works but not for obj-c. (I'm not sure why this is though)

So probably the best solution to fix #107 is to check in triggerBluetoothStatus if the manager is .PoweredOn otherwise wait for the update in peripheralDidUpdateState and only then start/stop advertising (if powered-on)
Also what concerns me a bit with this is the removal of the waitingForBluetooth because previously we could have the permission alert flash while the bluetooth status was still in process of going from .Unknown to .Authorized.

@nickoneill
Copy link
Owner

Thanks for the feedback @felix-dumit, I'll check this out in the objc example.

We do have some plans to behave differently for async permissions requests, such as cloudkit. Maybe best to wrap the removal of waitingForBluetooth into that.

@felix-dumit
Copy link
Contributor

Sounds good. I was thinking maybe it would make sense to wrap the results of the status callbacks using a promise or future.

@nickoneill
Copy link
Owner

I just defaulted the bluetooth power alerts to off, this'll be in the next 1.0.2 release. The other two issues here are broken out into #132 and #133

@nickoneill nickoneill closed this Nov 28, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants