Der Beitrag für diese Woche behandelt die Weboberfläche für Client-Geräte sowie die Kommunikation zwischen Frontend und Backend.

Vorüberlegungen

Eine zentrale Fragestellung in diesem Kontext war die Auswahl einer geeigneten Bibliothek zur Erleichterung der Implementierung entsprechender Funktionen. Ausschlaggebend für eine Entscheidung war die Kompatibilität mit Promise-Objekten.

Bei mehreren asynchronen Aufrufen und Abhängigkeiten der zurückgegebenen Ergebnisse führt der Einsatz der Javascript Callback-Funktionen oftmals zu einer sogenannten „callback-hell“: Mehrere callback-Funktionen müssen ineinander verschachtelt werden und die Codequalität durch die daraus resultierende Unleserlichkeit nimmt stark ab. Eine geeignetere Lösung ist daher der Einsatz von Promises. Dies sind Objekte, die in naher Zukunft einen Wert zurückgeben werden und damit Erfolg oder Fehlschlagen einer asynchronen Operation ausdrücken. Durch den Zusatz des Schlüsselbegriffs „await“ wird die Ausführung von nachgelagertem Code solange gestoppt, bis ein Ergebnis zurückgegeben wurde.

Promises können zwar auch mittels jQuery verwendet werden, da jQuery das Promise Interface implementiert, jQuery liefert jedoch kein natives Promise-Objekt zurück. Genau genommen wird ein jQuery XMLHttpRequest (jqXHR) Objekt zurückgegeben. (siehe http://api.jquery.com/jquery.ajax/) Die jquery.ajax() Funktion kann zwar in eine weitere Promise.resolve() Funktion verpackt werden, bedeutet jedoch ein kleiner Mehraufwand. Die Axios Bibliothek hingegen liefert ein natives Promise-Objekt zurück. Des Weiteren resolvt das von Axios zurückgegebene Promise Objekt nicht nur mit dem eigentlichen Response-Body, sondern mit weiteren Daten wie Header und Statuscode. Für die Frontend und Backend-Kommunikation wird daher die Axios Bibliothek anstelle der jQuery-AJAX Funktion eingesetzt.

Das obige Codebeispiel zeigt noch einmal im direkten Vergleich das Rückgabe-Objekt einer jQuery- und einer Axios-Implementierung. Das Axios-Objekt hat einen ersichtlich höheren Informationsgehalt.

Projektstatus

Nach Implementierung einer „Helper-Funktion“, die die Anfragen an den Server schickt, ist es nun möglich einen Login mit Benutzername und Passwort durchzuführen, Benutzerprofile mit Bild und Name über ein Formular in der Datenbank zu speichern sowie wiederum aus dieser abzurufen. Die Helper-Funktion auf Basis der Axios Bibliothek sieht wie folgt aus:

Die Standardwerte für die Konfiguration, wie beispielsweise Basis URL und JSON als Standardformat für den Inhalt, werden in den ersten beiden Codezeilen definiert.

Das Bild wird vorab Base64-codiert, damit es in der MongoDB gespeichert werden kann.

Funktion zur Codierung im Base64-Format

Die Oberfläche sieht damit wie folgt aus:

Nach Anlegen eines Benutzers wie beispielsweise „Ingrid“ mit Profilbild kann dieser anschließend auch betrachtet werden.

Außerdem ist es bereits möglich dem gesamten Kühlschrankinhalt abzurufen. Hierfür werden aktuell noch Mockdaten aus der Datenbank genutzt.

Arbeitspakete der nächsten Wochen

Zukünftig soll es auch möglich sein, Kühlschrankinhalte benutzerbezogen anzulegen und diese aus der Datenbank bei Übergabe des Benutzernamens abrufen zu können. Darüber hinaus sollen Kühlschrankbestände, auf Zeilenebene der Tabelle, nachträglich über den „Edit“-Button modifiziert werden können.

Die Ansteuerung der Kamera auf dem Pi wurde erfolgreich mithilfe der Python Bibliothek „picamera“ realisiert. Aktuell wird an der Anbindung des Touchscreens gearbeitet, wobei spezielle Linux Device Tree Overlays notwendig sind.

RaspberryBuy (5) Status der Weboberfläche

Ein Gedanke zu „RaspberryBuy (5) Status der Weboberfläche

Schreibe einen Kommentar

Zur Werkzeugleiste springen