get example app working #68
Conversation
| get { | ||
| return id.id | ||
| } | ||
| set(newID) { |
There was a problem hiding this comment.
Adding a public setter to Transmitter.id isn’t the right solution, since additional state on Transmitter like activationDate need to be reset. I think it’s cleaner for clients to recreate Transmitter when the ID changes.
There was a problem hiding this comment.
Thanks @ps2, will do, much cleaner. I have changed the client code to recreate Transmitter; it just doesn't always start scanning reliably after a change to the transmitter ID. Once I've chased that down I'll push the changes.
There was a problem hiding this comment.
Is there anything I need to do in the client to tear down the old transmitter and replace it with a new one? When I try this, and change the ID in the client, the CBCentralManager state is sometimes .poweredOn, which is all good, but sometimes .unsupported, in which case we can't scan. Does the central manager need to be a singleton or something?
There was a problem hiding this comment.
What if we store the transmitter state (activationDate and lastTimeMessage in the TransmitterID object, which gets renewed on a new ID). If we write the setter like this
set(newID) {
stopScanning()
id = TransmitterID(id: newID)
resumeScanning()
}
then we scan afresh when the user changes ID.
I'd be happy to replace the entire Transmitter object, but can't find a clean way for the old Transmitter object to release all bluetooth resources in time for the new object to use them (if that makes sense).
There was a problem hiding this comment.
We do need to reset the bluetooth peripheral if we're changing the transmitter id.
There was a problem hiding this comment.
See #70; I've incorporated some of the things you've been pointing out there. I think this PR should just focus on getting the example app building. I.e. Removing cocoapods, and incorporating the example app into the project.
2 participants
This PR
pod installis called (see here for reference)IDinTransmitterxDripG5.podspecto 10.3 to keep dependencies happyNote that the compilation order for xDripG5 needs to be changed as a workaround for https://bugs.swift.org/browse/SR-631. Specifically,
PeripheralManager+G5.swiftandBluetoothServices.swiftneed to be compiled afterPeripheralManager.swiftto avoid errors like "'Configuration' is not a member type of 'PeripheralManager'". Not sure how to specify compilation order in CocoaPods.