Lösung Komponenten mittels App Inventor
Nachdem nun die Oberfläche der App kreiert wurde, muss die Funktionalität der App noch erstellt werden. Zuerst muss auch die Block-Ansicht rechts oben umgestellt werden. Danach müssen alle nachfolgenden Blöcke nachgebaut werden. Die Farben der Blöcke sind ein Hinweis darauf, in welcher Meta-Kategorie dieser Block zu finden ist.
Variablen initialisieren
Dort sollten nun die nachfolgenden Variablen erstellt werden:
Die Zahlen, welche für light_rx_input bzw. humidity notwendig sind, sind unter “Math” zunfinden, die false-Operationen für bspw. light_rx_crit unter “Logic”, die Strings wie für serverURL unter “Text” und die leeren Listen wie für dataList unter “Lists”.
Zu aller erst müssen Variablen erstellt und initialisiert werden.
Variablen sind unter dem Reiter “Blocks” zu finden:
Dort sollten nun die nachfolgenden Variablen erstellt werden:
Die Zahlen, welche für light_rx_input bzw. humidity notwendig sind, sind unter “Math” zunfinden, die false-Operationen für bspw. light_rx_crit unter “Logic”, die Strings wie für serverURL unter “Text” und die leeren Listen wie für dataList unter “Lists”.
Als nächstes muss eine Kondition für die Komponente liveCheckBox angelegt werden, welche Ausgelöst wird, sobald die Check Box geklickt wird. Dies ist nötig, damit die App per live Überwachung Veränderungen des Zustandes mittracken kann, wie etwa eine Bewegung im Raum, die Störung der Barriere oder einem Temperatur- bzw. Luftunterschied.
Zu finden ist dieser Block innerhalb der liveCheckBox:
autoRefresh kann unter den Variablen gesetzt werden, indem im Dropdown Menü der entsprechende Name ausgewählt wird:
Die liveCheckBox wird wieder innerhalb der Blöcke für diese Komponente auf checked gesetzt.
Sobald die Applikation gestartet wird, ist ein Screen zu sehen. Wird dieser initialisiert – also ständig -, so soll die liveCheckBox automatisch auf jenen Wert gesetzt werden, welcher zuvor ausgewählt wurde. Dies muss mittels auto-refresh ständig überprüft werden, damit es zu keine Verzögerungen kommt. Auch die Methoden serverUrl und readData müssen zyklisch neu geladen werden, um live Daten ablesen zu können.
Um nun zu wissen, wie regelmäßig die Daten aktualisiert werden müssen, benötigt man die Methode timerClock.
Nun muss auch noch bestimmt werden, was mit der Applikation geschieht, wenn ein Fehler geworfen wird. Um es möglichst unkompliziert zu halten, wird die Applikation einfach beendet, sobald ein Error auftritt.
Tritt nun ein Fehler auf, so wird auch das autoRefresh auf false gesetzt, nachdem dies bei einer beendeten Applikation nicht mehr benötigt wird. Auch die liveCheckBox wird auf falsch gesetzt, und es soll eine Fehlermeldung auf dem Endgerät angezeigt werden.
Als nächstes wird eine Funktion für den goButton geschrieben, welche ausgelöst wird, sobald der Button gedrückt wird. Dabei solle die vorhin erstellte Methode readData und die richtige serverUrl aufgerufen werden. Danach wird der Status des goButtons überprüft. Ist dieser “Off”, so wird er zunächst auf “On” gesetzt, wonach eine Verbindung mit der bereits initierten server Url hergestellt wird. Von diesem Server werden die Daten ausgelesen.
Sollte der Status des goButtons auf “On” sein, so wird er lediglich auf “Off” gesetzt.
In der nächsten Abbildung wird die readData() Methode gezeigt, welche als einzige einen Unterschied aufweist, je nachdem welche Version verwendet wird. Für die Version 1 muss nichts verändert werden. Für die Version 2 ist es notwendig, den Text mit „The light in your room was turned on“ mit dem Text „The barrier was broken.“ zu ersetzen. Dafür wird der Text per Drag and Drop verschoben.
Um die Daten lesen zu können wird erst die globale Server Url auf die am Anfang festgelegte Url gesetzt. Danach wird diese Url auch im Web aufgerufen.
Als nächstes, in der if-Bedingung, werden die erhaltenen Daten der Units abgelesen und verwertet. Als erstes wird geprüft, ob die Luftfeuchtigkeit, welche vom Motionsensor gemessen wurde, über 30 ist. Gleichzeitig muss auch die Variable humCrit auf falsch gesetzt sein. Ist dies der Fall, so wird eine Warnung ausgesendet, dass die Luftfeuchtigkeit zu hoch ist, und humCrit wird auf true gesetzt.
Sollte die Luftfeuchtigkeit (wieder) kleiner-gleich 30 sein, so wird humCrit auf false gesetzt.
Die nächste If überprüft, ob die Lichtschranke durchbrochen wurde, dabei wird gecheckt, ob light_rx_input gleich 1 ist und light_rx_crit false ist.
Auch hier wird wieder eine Warnung ausgesendet, während light_rx_crit wieder angepasst wird.
Zu guter Letzt wird bestimmt, welcher Text in der Applikation angezeigt werden soll. Dafür muss erst sicher gestellt werden, dass eine stabile Verbindung zum Server besteht, weshalb der responseCode abgeprüft wird. 200 steht dabei für OK. Danach wird die globale dataList mit den erhaltenen Daten befüllt.
Mobile Applikation - Überblick
Das Krisenmanagementsystem weist die im Abschnitt Vorbereitung für das Programm beschriebenen Komponenten, Units und Codes auf. Eine Beschreibung wie die Applikation funktioniert wird in der Abbildung rechts gezeigt.
