Mobile app BLE support #643
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
This version is a bit messy but will DFU flash the data collection hex. Needs more dialog steps, progress, feeedback on success/fail. Having said that, I'm going to go straight for reconnecting for the accelerometer data.
|
Preview build will be at |
It needs to become richer to deal with the multi-stage process and indeterminate parts but we'll revisit that later. NPM script for hot reload
This will significantly improve the apps experience as it will allow full flashes to be avoided completely if you already have a MakeCode hex on the micro:bit and in any case for the data collection - MakeCode transition. This change also means that we now support Bluetooth mode for the data collection hex. There's some risk of confusion and we might discuss this further but on balance it's probably better if flashing always works the same way. This should significantly help development speed on the app as we can flash over this hex. I've added just-works variants for mobile as the UI flows really expect pairing to happen so it's better for us not to contribute toward it unexpectedly not happening... though we can't control this completely as it's about the hex already on the device. This one might be worth splitting out and applying to main but applying here for now. To revisit: I'd also like to merge Carlos's uhex tool and automate the splitting of the MakeCode hex here.
It's useful to have enums for the possible BLE values - these are not opaque identifiers which is what the rule assumes.
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.
TODO:
Before it's good enough to merget to the apps branch as a demo:
Fix playwright tests
Initial pair and download works either for data collection hex or MakeCode hex but other scenarios fail, including typical end to end use. I've seen multiple pairing dialogs that make no sense as we should already be paired. What's going on? Is it a service discovery thing? Better logging is needed.
Flashing progress
doing pre-flashing bits of the flow. We need an integrated notion of progress, worth bottoming out before we move the code.
The current shared error handling is mistitled and errors when you uses it. Fix it to at least let you try again.
Test the web flows, including on V1
Test on Android and note but defer any Android specific issues
In follow up changes / new issues
Can we get PF and DFU in application mode in the data collection hex and still stick with MakeCode? Some CODAL config fu or C++? For discussion as it's confusing that the end state in Bluetooth and data collection modes is identical.
Error scenarios (largely new from flashing):
Figure out relationship to microbit-connection. Seems increasingly like the code should move there, maybe as a temporary branch until the dust settles. Could we use Capacitor's web implementation for Bluetooth? We have a few hairy workarounds though. What about non-Foundation clients? Is it an acceptable dependency? Maybe an optional dependency/separate package?
Improve the reset dialog
Introduce a step about pairing like the current mobile app
Improve the factoring of the download/connection flows... it's very hard to follow the different cases. Maybe we need a separate set of states for each of radio/web BT/native BT?
Known limitations