5 Lessons Learned beim Entwickeln auf der Fitbit Smartwatch

Anfang diesen Jahres kam unser Kunde mit einer spannenden Idee auf uns zu: Lasst uns eine Home Connect App für die Fitbit Smartwatch bauen! Das Ziel: Home Connect Nutzer können ihre Haushaltsgeräte wie Kaffee-, Waschmaschinen oder Öfen von ihrem Handgelenk aus überwachen und steuern. Sechs Wochen später waren wir stolz auf einen erfolgreichen Launch.

Da es unser erstes Fitbit-Projekt war, haben wir eine Menge dabei gelernt. In diesem Beitrag will ich versuchen fünf Takeaways herauszupicken, die beim Entwickeln einer Fitbit-App hilfreich sein können. Aber zuerst ein paar technische Hintergründe zu unserer Anwendung: Damit Kunden mit ihren Haushaltsgeräten interagieren können, nutzen wir die offizielle Home Connect API. Desweiteren setzen wir darauf, dass der Nutzer eine aktive Internetverbindung an seinem Smartphone hat. Von dort übertragen wir die benötigten Daten auf die Uhr. Alle Aktionen, die der User auf der Uhr ausführt, nehmen den umgekehrten Weg über das Smartphone.

Um sich mit dem Fitbit SDK vertraut zu machen, gibt es einen Guide auf dev.fitbit.com. Für einen Einstieg in die Code-Struktur empfehlen wir einen Blick auf die verschiedenen Open Source Apps auf Github zu werfen. Dort bekommt man einen Eindruck was andere bereits gebaut haben und vor allem wie.

1. Development Infrastructure is Key

Fitbits Web IDE, das sogenannte Fitbit Studio, ist nett um in die Entwicklung mit Fitbit einzusteigen, aber nicht wirklich geeignet, um als Team daran zu arbeiten. Mit drei Entwicklern, die am Projekt arbeiten, ist es zielführend den Code in einem Git Repository zu verwalten.

Das Fitbit CLI stellt eine gute Basis zur lokalen Entwicklung bereit und unterstützt auch die lokale Ausführung direkt auf der Uhr oder im Simulator. Damit sind wir von der Web IDE unabhängig und ready unsere App zu entwickeln.

Ein weiterer Aspekt, der uns geholfen hat, ist nicht nur die Unterstützung von JavaScript, sondern auch von TypeScript - und das ohne zusätzliches Build-Setup. Die von der Community im Projekt fitbit-sdk-types bereitgestellten Typisierungen haben es uns ermöglicht, schnell und selbstsicher mit der Plattform zu interagieren.

2. The Simulator

Es steht ein Simulator von Fitbit zur Verfügung, auf dem man die Apps lokal ausführen kann, ohne dass ein Gerät benötigt wird. Der Simulator ist besonders nützlich, weil die Build-Deploy-Zyklen einer Anwendung auf der Uhr einige Zeit in Anspruch nehmen.

Allerdings ist der Simulator kein Ersatz für das Testen auf dem eigentlichen Gerät. Wie bereits erwähnt, verlassen wir uns auf die Interaktion zwischen der App und der Companion App auf dem Smartphone. Während die Kommunikation im Simulator zwischen diesen beiden immer smooth und synchron vonstattengeht, ist das auf dem richtigen Gerät eine andere Geschichte. Die Bluetooth- oder Internet-Verbindung kann unterbrochen oder die Fitbit Smartphone App durch das Betriebssystem (und damit auch die Companion App) beendet werden.

Nachdem die Basis-Funktionalität für unsere App fertig war, haben diese Tücken mehr Zeit in Anspruch genommen, als wir ursprünglich erwartet hatten.

3. Keep an Eye on the Memory

Anwendungen, die auf der Fitbit Smartwatch laufen, müssen mit 64 KB Speicher auskommen. Das ist nicht viel, besonders in JavaScript. Am Anfang haben wir darauf nicht besonders geachtet, aber recht bald hat uns das Thema eingeholt.

Es lohnt sich, frühzeitig den Memory pressure im Auge zu behalten. So hatten wir beispielsweise anfangs einen starken Fokus auf Objektorientierung, um unsere Öfen und Kaffeemaschinen zu modellieren. Zusätzlich haben wir die von der API kommenden Daten meist auf der Uhr ausgewertet. Das führte dazu, dass die App wiederholt abstürzte, weil der Speicherplatz knapp wurde.

Einerseits haben wir dieses Problem angegangen, indem wir einen Großteil auf die Companion App auf dem Smartphone ausgelagert und nur ein Minimum an notwendigen Daten an die Watch App gesendet haben. Andererseits haben wir auch die Größe unseres Codes auf der Uhr reduziert, indem wir den OOP-Code vereinfacht haben.

4. A Powerful UI

Anfangs hatten wir etwas Angst, dass eine UI mit über hundert einzelnen Elementen Performance-Probleme verursachen könnte. Aber im Gegensatz zu den Speicherbegrenzungen hatten wir solche Probleme nicht. Die Aktualisierung der SVG Elemente alle paar Sekunden, während ein Benutzer durch die App navigiert, hat die User Experience nicht spürbar beeinträchtigt.

Die UI-Library von Fitbit enthält viele hilfreiche vordefinierte Widgets und auch Animationen. Dennoch mussten wir auch Elemente manuell animieren. Zum Beispiel zeichnen wir jede Sekunde manuell ein Rechteck für den Fortschrittsbalken, da die Interpolation der Animationen sonst zu einem Flackern geführt hätte. Auch in diesem Fall haben wir keine Performance-Einbußen festgestellt.

5. Get Creative

Die Entwicklung einer Fitbit-App brachte einige neue Herausforderungen für unser Team mit sich. Bei jedem Projekt müssen wir die richtige Balance zwischen den technischen Möglichkeiten der Plattform und den Anforderungen unserer Kunden finden. Und diesmal war der technische Aufbau doch sehr anders als die Entwicklung von Microservices oder Frontends. Dadurch konnten wir aber einiges über das Entwickeln solcher Apps lernen.

Am Ende muss man vielleicht ein wenig kreativ werden, um seine Ziele zu erreichen, so wie wir es beim Aufbau eines Kaffeeprogramm-Konfigurators getan haben, bei dem wir die Settings API verwenden, um vorübergehend Daten zwischen dem Einstellungen-Screen und der Companion Komponente auszutauschen.

Ich hoffe, dieser Beitrag konnte einen Einblick in den aktuellen Zustand der Fitbit-Plattform geben und ihre Herausforderungen für die Entwicklungsteams vermitteln. Während die Plattform selbst bereits viele Möglichkeiten bietet, freuen wir uns darauf, sie ausgereift zu sehen.