The pairing code is shown before it has reached the server

[ensonic]

With the current code we show the pairing code in the UI and send a push-request with 'cmd=register' and the pairing code to the server. If the robot is on a slow network, the user can enter the code already and then gets this warning from the openroberta lab:

Check if your robot is switched on and connected to the server.

We can't wait for the request to reach the server, since this is a http-push api where, we intentionall fire requests and keep them waiting at the server side. There is no hook for getting notified when the request was sent.
https://docs.python.org/3/library/urllib.request.html#module-urllib.request

A better wait would be to:

1. send the 'init' to the server without a token and receive the token from the server (small timeout)
2. send 'register' with the received token to the server (long timeout)

This way we know that we have connected in 1) and can show the token. See OpenRoberta/robertalab#32

See also #28.

[ensonic]

We have more options.

We can wait for an event from the connector thread before sending the 'connected' signal. The event is basically that we got a reply on the first push. So we change this code to

self.event = threading.Event()
# start connector thread
...
self.status('connected')
self.event.wait() # consider a timeout though
return self.thread.params['token']

and in the connector

self.service.event.set()

This works, but there is quite a pause in the UI before the pairing code is shown. Ideally we show a "connecting ..." message, since otherwise people can press connect multiple times.
(see ui code)

[lotu]

One other possibility to show the code but have a waiting symbol (e.g. two arrows circling each other), until the robot knows the code has been received by the server, then change to a check mark or something.

For context when a middle student is unable to connect their robot it can be extremely discouraging because they did everything correctly but got a bad result and presume that something is wrong with them personally. It also consumes lots of teacher time troubleshooting non-working robots.

[ensonic]

I totally understand, but I don't see how to fix this without UI changes and since those are in a different package, this is tricky. Adding the spinner does not make it easier. If I would have the 2nd signal to turn the spinner off, I could also defer showing the code :/

I'll see if I can introduce the signaling in one change and find a way for the UI to be changed to work with new and old signalling to support a transition period. Maybe I can provide an updated brickman for those who care (the 'jessie' version probably won't get a release otherwise).

[ensonic]

Planning discussion now on a wiki page: https://github.com/OpenRoberta/robertalab-ev3dev/wiki/lab.py-communication-with-brickman