Eu poderia projetar esse sistema para aproveitar algum tipo de estado persistente, visto que ele opera ao longo de muitas horas, se não dias. Isso permitiria a saída e a reentrada do aplicativo sem afetar seu curso de ação.
Para ativar essa funcionalidade, o seguinte pode ser suficiente:
- Status do dispositivo (no momento do cheque), junto com o carimbo de data / hora UTC.
- Ação tomada (usuário notificado, juntamente com o motivo: erro / recuperação), juntamente com o carimbo de data / hora UTC
Eu, então, escrevo várias consultas para determinar qual ação futura devo tomar para qualquer dispositivo, executar essa ação e registrar a ação de acordo. Registrar a ação alteraria o resultado da consulta e indicaria que a ação não é mais necessária.
Suas consultas e determinadas ações seriam pareadas com as seguintes:
-
Para determinar
required notifications for level 1 users
, localize todos os dispositivos nos quais olatest alarm time
é maior que olatest level 1 notification time
e maior que olatest non-alarmed time + 15 minutes
. -
Para determinar
required notifications for level 2 users
, localize todos os dispositivos nos quais olatest alarm time
é maior que olatest level 2 notification time
e maior que olatest non-alarmed time + 24 hours
. -
Para determinar
required notifications for non-alarm status
, encontre todos os dispositivos nos quais a últimanon-alarm time
é maior que a últimanon-alarm notification + 1 hour
Envie as notificações e faça o log de acordo. Repita quantas vezes for útil por acordo de nível de serviço.