BlocklyProp
BlocklyProp copied to clipboard
Change port refresh event trigger and/or port list element display technique
The once-every-two-second port refresh request from BlocklyProp Editor is wasteful and now contributes to problems with user port selection once Wi-Fi ports are involved.
The order of Wi-Fi "port" discovery changes (by nature) and the Wi-Fi port discovery process adds enough time to the round-trip request+response that a user is able to select a port from the previous port list after a new refresh request is made and before the response is received. The displayed value in the port list sometimes ends up suddenly switching on it's own after the user selected it.
Here's a video demonstrating the problem. During it, I'm secretly watching network activity and I am intentionally selecting "Jeff's WX2" right after the browser sends BPClient a port-refresh-request, but, as you can see, the two Wi-Fi modules happen to be discovered in a different order each time... causing the actual selected port to be Jeff's WX1 each time... the last of them clearly being selected properly, then suddenly changing to the other.
https://drive.google.com/file/d/0B0tev9Y3WaL4SjlGNXE4dXc5RDg/view?usp=sharing
I will make BlocklyPropClient sort the Wi-Fi ports alphabetically (which will help the above case), but that won't completely solve the problem since wireless ports may appear and disappear across consecutive port refresh requests. To fix that, more has to be done on the BlocklyProp Editor side.
-
Fix 1: Change the editor's selected port display code (that I'm assuming is triggered upon port refresh response) from index-based to text-based so that, if the user selects "Port A" while a port refresh request is being performed, the final item selected in the port field is actually "Port A" (if it still exists) instead of it being whatever element happens to occupy that position in the list on that particular refresh cycle.
-
Fix 2: Set the port refresh request to be user-action based (when they click on the port field's down arrow button) and not on a timed basis. Most often, during normal user workflow, they connect their device, select the port, and then program away... the port ID they are using doesn't change from moment to moment, so let's make the port refresh request occur when they need it instead of hundreds of times when they don't.
- Ideally, the BPClient should push port arrival/departure events to the BlocklyProp Editor, but still accept refresh requests. This takes more advanced code on each platform (for BPClient) and in the protocol between the BPClient and Browser... so we'll have to make that a wish-list item.