Example Remember URS |
This example shows how a reminder function can be programmed. It is intended to induce the user to open the app regularly.
Requirements:
The app has four states: :
App opened | Pending alarm |
Pending 2nd alarm |
Notifiaction opened |
2nd Notifiaction opened |
|
---|---|---|---|---|---|
1 | X | - | - | - | - |
2 | - | X | X | - | - |
3 | - | - | X | X | - |
4 | - | - | - | - | X |
User interface of the app | Created notifications |
The app has no function. It can only be switched off.
The following instances of the components are used in the project.
Typ | Name | Funktion | |
---|---|---|---|
UrsAI2NotificationChannel | Channel | Notification channel. | |
UrsNotification | AlarmNotification | The notification to be generated at the time of the alarm. | |
UrsNotification | UrgentNotification | The notification that will update the first one later. | |
UrsIntent | RememberUrsIntent | Intent that opens the Screen Screen1. | |
Clock | Clock1 | Timer for regularly updating the time of the alarm. |
The code isn't very difficult. It consists of a procedure that creates an alarm or postpones an existing alarm. This function is called once when the app is started. An new alarm is generated or an existing one is adapted. This function is called up a second time, controlled by a timer, before the alarm time has expired. This adapts the existing alarm so that it is not triggered. The time of the alarm is adjusted again when the app is (actively) closed.
You'd think that it would be enough to create the alarm when the app is closed. However, this is not sufficient. If the app is closed externally, e.g. via the app overview (history), the app will recognize this. So no alarm would be created. This case is covered by setting the alarm when the app is started and repeatedly delaying it. If the app is closed via an external mechanism, the regular delay no longer applies and the alarm is triggered at the expected time.
Indeed there are two alarms. The second iks triggered with twice the delay time. Both alarms must exist separately from each other, so they require different IDs (RequestCode). The second notification is intended to update the first. For this to work, both notifications must have the same ID (NumberID).
Theoretically, you could managed this behavior with a single UrsNotification instance. Channel.CreateAlarm takes the data from the UrsNotification object at the time of the call. Subsequent changes to the properties would therefore have no effect. Before the second call of Channel.CreateAlarm in the CreateAlarm procedure, the UrsNotification instance could have been set up appropriately for further use by code, i.e. the title and text could have been adjusted. However, since the procedure is called several times, the values must have been reset. Using two instances is easier.
The global variable Delay holds the value for the delay for the alarm time (here 10 seconds after closing the app). The timer is set to a time significantly shorter (2 seconds) than the delay time. Shorter times would be possible, but would stress the system. Any notifications that have already been displayed will are deleted. Finally, the alarm is created or an existing one is adapted.
The alarm time is updated regularly and when the app is closed.
Strictly speaking, there are two alarms. The second is created with twice the delay time.