Beispiel Remember URS |
In diesem Beispiel wird gezeigt, wie eine Erinnerungsfunktion programmiert werden kann. Sie soll den Anwender dazu verleiten, die App regelmäßig zu öffnen.
Anforderungen:
Die App kennt somit vier Zustände:
App geöffnet | Ausstehender Alarm |
Ausstehender 2. Alarm |
Benachrichtigung angezeigt |
2. Benachrichtigung angezeigt |
|
---|---|---|---|---|---|
1 | X | - | - | - | - |
2 | - | X | X | - | - |
3 | - | - | X | X | - |
4 | - | - | - | - | X |
Benutzeroberfläche der App | Generierte Benachrichtigungen |
Die App hat keine Funktion. Sie kann nur ausgeschaltet werden.
In dem Projekt sind folgende Instanzen der Komponenten angelegt.
Typ | Name | Funktion | |
---|---|---|---|
UrsAI2NotificationChannel | Channel | Benachrichtigungskanal. | |
UrsNotification | AlarmNotification | Die Benachrichtigung, die zum Alarmzeitpunkt erzeugt werden soll. | |
UrsNotification | UrgentNotification | Die Benachrichtigung, die die erste zum späteren Zeitpunkt aktualisiert. | |
UrsIntent | RememberUrsIntent | Intent, der den Screen Screen1 öffnet. | |
Clock | Clock1 | Timer zum regelmäßigen Aktualisierens des Alarmzeitpunkts. |
Der Code ist nicht sehr schwierig. Er besteht aus einer Prozedur, die einen Alarm anlegt bzw. einen bestehenden Alarm zeitlich verschiebt. Diese Funktion wird einmal beim Start der App aufgerufen. Entweder wird dadurch ein neuer Alarm erzeugt oder ein evtl. bestehender wird angepasst. Ein zweites Mal wird diese Funktion immer wieder, gesteuert durch einen Timer, deutlich vor Ablauf der Alarmzeit aufgerufen. Das passt den bestehenden Alarm an, so dass er nicht ausgelöst wird. Ein letztes mal wird der Zeitpunkt des Alarms beim (aktiven) Schließen der App angepasst.
Man könnte meinen, dass es ausreichen würde, den Alarm beim Schließen der App auszulösen. Dies reicht jedoch nicht. Wenn die App extern, z.B. über die App-Übersicht (Historie), geschlossen wird, erfährt die App nichts davon. Es würde also kein Alarm erstellt. Dadurch, dass der Alarm beim Start der App gestellt und immer wieder hinaus gezögert wird, wird auch dieser Fall abgedeckt. Beim Schließen der App über einen externe Mechanismus fällt die regelmäßige Hinauszögerung fort und der Alarm wird zum erwarteten Zeitpunkt ausgelöst.
Genau genommen sind es zwei Alarme. Der zweite erfolgt mit der doppelten Verzögerungszeit. Beide Alarme müssen separat voneinander existieren, benötigen also unterschiedliche IDs (RequestCode). Die zweite Benachrichtigung soll die erste ersetzen. Damit dies funktioniert, müssen beide Benachrichtigungen die gleiche ID (NumberID) besitzen.
Theoretisch wäre man mit einer UrsNotification-Instanz ausgekommen. Channel.CreateAlarm übernimmt die Daten aus dem UrsNotification-Objekt zum Zeitpunkt des Aufrufs. Nachträgliche Änderungen an dem Objekt hätten somit keine Wirkung. Man hätte die UrsNotification-Instanz vor dem zweiten Aufruf von Channel.CreateAlarm in der Prozedur CreateAlarm passend für die weitere Benutzung per Code einrichten, also den Titel und den Text anpassen können. Da die Prozedur jedoch mehrfach aufgerufen wird, hätte man die Werte auch wieder zurück setzen müssen. Da ist die Benutzung von zwei Instanzen einfacher.
Die globale Variable Delay enthält den Wert für die Verzögerung für die Alarmzeit (hier 10 Sekunden nach Schließen de App). Der Timer wird auf eine Zeit deutlich kleiner (2 Sekunden) als die Verzögerungszeit eingestellt. Kürzere Zeiten wären möglich, würden aber das System belasten. Danach werden evtl. bereits angezeigte Benachrichtigungen gelöscht. Zuletzt wird der Alarm erstellt bzw. ein bestehender angepasst.
Regelmäßig und beim Schließen der App wird der Alarmzeitpunkt aktualisiert.
Genau genommen sind es zwei Alarme. Der zweite erfolgt mit der doppelten Verzögerungszeit.