Apps Bluetooth support #67
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Deploying microbit-connection with
|
| Latest commit: |
90a9e79
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://75387384.microbit-connection.pages.dev |
| Branch Preview URL: | https://apps.microbit-connection.pages.dev |
This contains breaking changes (e.g. flash progress interface, connect
signature, device error codes) and will form part of a v1 at some point.
Migrating USB-only code should be trivial though.
Changes:
- Switch to capacitor-ble for bluetooth
- Quite a simplication as the service/characteristic lookups are deferred to
point of use and the interactions are internally queued.
- Support DFU and partial flashing on iOS/Android platforms
- Drop a bunch of workarounds that need reevaluating after the switch
- Temporarily drop uBit name support due to capacitor-ble limitation
- Don't try to start notifications on absent services. Prevents issues when not
in application mode for a flash.
- Improve connect interface (which had a misleading return value) and
connect/flash progress.
This branch is going to be long lived for a month or two during apps work, then
we'll loop back around and see what it means for Web Bluetooth - does it
replace it or do we have both implementations.
Design issues:
- Should connecting and connecting for flashing both be the same flow? Or are
the ideas different enough that we split them? It's nice in that it matches
USB but it's also quite different because of pairing.
microbit-matt-hillsdon
force-pushed
the
apps
branch
from
0d58d9d to
fa96588
Compare
- Use .js extension for imports consistently - Fix typo in exports for types (also on main, but at least VS Code seems to cope)
This might be a behaviour change for bluetooth but is consistent with USB.
For USB there's not really anything to do but let's keep it consistent
This has caused app-level issues because disconnected doesn't let the app understand that a reconnect will automatically happen.
You can want to pause due to a hidden tab, but defer it due to flashing then become visible before you ever did pause. But we went ahead with the pause incorrectly.
Remove them from the connection status. Check them before connect but also provide pre-flight API for UX flows. This better matches the iOS/Android permission model and is easier for client code to manage.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This contains breaking changes (e.g. flash progress interface, connect
signature, device error codes) and will form part of a v1 at some point.
Migrating USB-only code should be trivial though.
Changes:
Switch to capacitor-ble for bluetooth
point of use and the interactions are internally queued.
Support DFU and partial flashing on iOS/Android platforms
Drop a bunch of workarounds that need reevaluating after the switch
Temporarily drop uBit name support due to capacitor-ble limitation
Don't try to start notifications on absent services. Prevents issues when not
in application mode for a flash.
Improve connect interface (which had a misleading return value) and
connect/flash progress.
This branch is going to be long lived for a month or two during apps work, then
we'll loop back around and see what it means for Web Bluetooth - does it
replace it or do we have both implementations.
Design issues:
the ideas different enough that we split them? It's nice in that it matches
USB but it's also quite different because of pairing.
TODO: