Bis jetzt gab es von uns schon Berichte zur Sensorik, zum Alarmsystem auf dem Pi und über den Web-Service, der die Funktionalitäten des Systems über eine REST-Schnittstelle exponiert. Was noch fehlt ist die mobile Android-App, die dem Eigenheimbesitzer die Kontrolle über sein Alarmsystem gibt. Deshalb widmen wir den letzten Blog-Eintrag diesem Thema.
Die App wurde in drei großen Schritten erstellt. Zuerst wurden die Möglichkeiten der Nutzerinteraktion konzipiert und ein Design mit entsprechender Navigation zwischen mehreren Ansichten, im Android-Jargon Activity, entwickelt. Die Navigation durch die App sieht dabei wie folgt aus:
Als erstes loggt sich ein Nutzer über die Anmeldedaten seines Alarmsystems ein. Die eingegebenen Daten werden lokal abgelegt, sodass bei wiederholtem Öffnen der App der Nutzer angemeldet bleibt. Bei erfolgreicher Anmeldung wird der Nutzer auf die Home-Activity weitergleitet. Hier gibt es eine Fußzeilennavigation, die dem Anwender je nach Auswahl eine Liste aller Sensoren und Aktoren, Regeln oder Benachrichtigungen anzeigt. Abhängig von der Liste, die angezeigt wird, sind auch die Menu-Buttons in der Toolbar unterschiedlich. Beispielsweise ist es möglich über einen Menu-Button den Einwahlmodus zu starten, wenn man sich in der Listenansicht der Sensorik befindet. In der Ansicht für Regeln können neue hinzugefügt werden und wenn die Benachrichtigungsliste zu sehen ist, wird dem Nutzer angeboten einen eingeschalteten Alarm zu deaktivieren – sofern einer aktiv war. Durch das Klicken auf ein Listenelement kommt man auf die jeweilige Detailansicht, in der entweder Sensor-, Regel- oder Benachrichtigungsdetails angezeigt werden. Von der Home-Activity aus kann der Nutzer auch zu einer Settings-Activity navigieren, von der aus Nutzername und Passwort geändert werden können. Ebenso kann man sich hier explizit vom System abmelden. Nach der Realisierung der Darstellung erfolgte die Abbildung der Alarmsystementitäten als Java-Klassen in der App, d. h. Modellierung von Sensorklassen, Regeln, etc. und deren Adapterklassen, um die Eigenschaften einfach im UI darstellen zu können. Insbesondere die Abstraktion durch Adapterklassen ermöglichte einen große Wiederverwendbarkeit des UI-Codes, sodass EINE allgemeine Listenanzeige implementiert wurde, die letztlich aber individualisiert sowohl Informationen für Geräte, Regeln und Nachrichten anzeigen konnte. Des Weiteren wurden neben Activities auch eigene Dialoge implementiert, um dem Nutzer das Ändern seines Passworts oder auch das Hinzufügen von Sensoren/Aktoren zu Regeln zu vereinfachen. Einige Screenshots der Anwendung verdeutlichen das eben gesagte nochmal:
Der zweite Schritt bestand dann darin, die App mit dem Web-Service kommunizieren zu lassen. Gemäß des Single-Responsibility-Prinzips haben wir bewusst davon abgesehen, Netzwerkanfragen in den Activities selbst durchzuführen. Stattdessen wurde eine zentrale Klasse RemoteAlarmSystem implementiert, die den Großteil aller Web-Service-Methoden kapselt und über Instanzmethoden der aufrufenden Activity zur Verfügung stellt. Ebenso wird das Transformieren von App-Objekten zu JSON-Daten und umgedreht direkt in der Klasse übernommen. Damit wurde die Komplexität der Netzwerkkommunikation an einer zentralen Stelle gelöst und nicht komplett über die Anwendung gestreut. Innerhalb der Klasse RemoteAlarmSystem wird das Volley-Framework verwendet, um asynchrone HTTP-Anfragen an den Web-Service zu stellen. Das Framework hat sich als wesentlich einfacher und schlanker als die Entwicklung mit AsncTask herausgestellt. Feinheiten, wie das Verwerfen von Requests beim Anhalten einer Activity, wurden auch berücksichtigt.
Die letzte Aufgabe in der App-Entwicklung konzentrierte sich auf das Empfangen von Push-Benachrichtigung, ohne die die App zweifellos an Effektivität einbüßen würde, da nur so Alarme auch zeitnah dem Eigenheimbesitzer mitgeteilt werden können. Um die Benachrichtigungen zu realisieren, verwendeten wir die Dienste der Google Firebase Cloud. In der Cloud-Umgebung wurde zunächst ein öffentlicher API-Schlüssel generiert, über den sowohl die App als auch das Alarmsystem den Cloud-Messaging-Dienst aufrufen. In der App erfolgte anschließend die Implementierung zweier Services, die parallel zur Anwendung im Hintergrund laufen und im ständigen Kontakt mit der Cloud auf eintreffende Nachrichten warten. Des Weiteren erzeugt einer der Services einen Token, welcher nur für ein spezielles Gerät gilt. Dieser Token wird dem Alarmsystem mitgeteilt, das dann wiederum bei allen Cloud-Anfragen den Token mitgibt, um nur an das jeweilige Zielgerät Push-Nachrichten zu senden. Das bedeutet im Umkehrschluss, das jedes Alarmsystem korrekterweise nur Nachrichten an das Android-Gerät sendet, das sich auch beim Alarmsystem angemeldet und seinen Token mitgeteilt hat. Mittels Postman kann das entsprechend auch getestet werden.
Zu guter Letzt:
Um mal einen Überblick über unseren Code zu bekommen: https://github.com/HomeSecurity
Generell ganz nützlich, falls noch jemand nach einer guten Projektstrukturierung mit Git sucht: http://nvie.com/posts/a-successful-git-branching-model/