You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
When switching to a new transmitter, stop restoring the first one #8
BluetoothManager only assumes there's one peripheral we care about, which isn't true as we continue to restore the original one.
In the interest of reusing BluetoothManager in other use cases and projects, let's always ask the delegate (in this case, the Transmitter class) for permission before connecting.
Ok. I was wondering if asking the transmitter for permission would result in having to ask the user permission for the app to access Bluetooth. I wouldn't want to have to repeat that popup request to the user.
CoreBluetooth supports something called State Restoration which makes it quicker to re-launch your app in response to bluetooth events, if it was closed for reasons like memory pressure. When the app relaunches and state is restored, you receive a list of all previously connected (or connection-pending) peripherals from the time the app was terminated.
So my first G5 Transmitter went dead yesterday, and I opened a new one, but the library wasn't accounting for having more than one peripheral in its restoration array, and would choose the last one each time. This meant spotty readings until I realized the issue. PR incoming...
I filed #10 to track. I'm seeing successful updates happening only every 30 minutes or so in my app, but the dex app seems to be getting every reading.
Activity
dennisgove commentedon Jan 16, 2016
Will this result in asking the user for permission?
loudnate commentedon Jan 16, 2016
The user has already provided a
TransmitterID, but we're not using to differentiate peripherals during scan or restore.dennisgove commentedon Jan 16, 2016
Ok. I was wondering if asking the transmitter for permission would result in having to ask the user permission for the app to access Bluetooth. I wouldn't want to have to repeat that popup request to the user.
loudnate commentedon Jan 16, 2016
Oh, sorry, you definitely have to do that. It's a new peripheral.
loudnate commentedon Jan 16, 2016
that is, if you're not running in "passive mode", in which case you've already responded to that dialog in the Dexcom app.
dennisgove commentedon Jan 16, 2016
I see. What's the use case for " continue to restore the original one"?
I only ever use in passive mode so suspect I'm missing something here.
loudnate commentedon Jan 16, 2016
CoreBluetoothsupports something called State Restoration which makes it quicker to re-launch your app in response to bluetooth events, if it was closed for reasons like memory pressure. When the app relaunches and state is restored, you receive a list of all previously connected (or connection-pending) peripherals from the time the app was terminated.So my first G5 Transmitter went dead yesterday, and I opened a new one, but the library wasn't accounting for having more than one peripheral in its restoration array, and would choose the last one each time. This meant spotty readings until I realized the issue. PR incoming...
Make the delegate name more Cocoa-ic
loudnate commentedon Jan 16, 2016
@dennisgove Have you updated to the latest version of the Dexcom G5 app?
dennisgove commentedon Jan 16, 2016
I updated to 1.0.19 earlier today and haven't seen any issues in glucose-badge, but I haven't been watching consistently.
loudnate commentedon Jan 16, 2016
I filed #10 to track. I'm seeing successful updates happening only every 30 minutes or so in my app, but the dex app seems to be getting every reading.
Fix plugin manager identifier so plugin will correctly restore serial…
Syncing Surfacing of G5/G6 Sensor Lifecycle + Detect Anubis-modded G6…
Updated translations from Lokalise on Mon Mar 20 01:37:12 CDT 2023 (L…