Das Henne-Ei-Problem

Wenn wir unsere Webanwendung starten, sollte sie sinnvollerweise die Ist-Werte des Players bei der Lautstärke und des Titels anzeigen. Es liegt nahe, dass der Server automatisch diese Werte an den Client übermittelt, sobald eine Verbindung hergestellt wurde. Allerdings muss der Verbindungsaufbau nicht automatisch heißen, dass der Client mit der Datenübertragung bereits etwas anfangen kann oder will.

Es bietet sich also an, dass der Client entweder ein Initial-Kommando sendet oder explizit die Infos anfordern kann, ohne vorher ein Player-Kommando zu übermitteln beziehungsweise die Lautstärke zu ändern. Ein Initial-Kommando könnte bei unserer Problemstellung auch damit einhergehen, überhaupt erst die Bluetooth-Verbindung aufzubauen - doch zu dieser Problematik mehr im nächsten Abschnitt.

Wir haben uns entschieden, explizit die Infos anzufordern. Dazu gibt es das spezielle Kommando nop (kurz für No Operation), das eben nicht per Bluetooth weitergeleitet wird. Es wird nur vom Websocket-Server beachtet und er sendet daraufhin einfach die aktuell vorliegenden Informationen.

Doch woher bekommt der Server die Daten vom Musikplayer? Er kann nach dem Verbindungsaufbau mit dem Peripheral die entsprechenden Eigenschaften lesen. Allerdings hatten wir bei den ersten Schritten zu Debugging-Zwecken eine andere Logik implementiert, die auch jetzt noch präsent ist: Wenn ein Central, also unser Server, eine Eigenschaft abonniert, wird der Wert der Eigenschaft auch sofort an den Abonnenten geschickt. Praktisch ist das ein Test, ob die Verbindung tatsächlich in beide Richtungen funktioniert.