NativeScript / NativeScript/plugins

[@nativescript/local-notifications] Scheduling a notification using the "at" property results in the notification being severly late

Abierto
#529 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Lenguaje dominante
TypeScript
Estrellas
206
Forks
123
Merge medio
2 d 1 h
PR fusionados (30 d)
1

Descripción

  • Android 13, targeting API level 33
  • @nativescript/core 8.5.7
  • @nativescript/local-notifications 6.1.1

This has not been tested on iOS yet, but will be soon, and I'll update this issue with the results once that has been done. It has been replicated on both a Samsung phone and tablet.

While trying to make use of the LocalNotifications.schedule() functionality, the notification arrives as expected, but ends up being significantly late. For instance, when trying to schedule a notification a minute into the future:

public async addScheduledNotification(notificationId: string) {
    const notification = NOTIFICATION_TYPES.find((n => n.id == notificationId));
    const targetStart = new Date(new Date().getTime() + 60 * 1000);
    console.log(`target start: ${targetStart}`);
    console.log(`getTime: ${targetStart.getTime()}`);
    console.log(await LocalNotifications.schedule([{
        id: Number.parseInt(notification.id),
        title: 'My App',
        body: notification.body,
        // interval: 'day' as ScheduleInterval,
        channel: 'MyApp',
        priority: 2,
        at: targetStart
    }]));
    console.log(await LocalNotifications.getScheduledIds());
}

Output:

  JS: CONSOLE LOG: target start: Tue Sep 05 2023 21:30:00 GMT-0400 (EDT)
  JS: CONSOLE LOG: getTime: 1693963800000
  JS: CONSOLE LOG: [0]
  JS: CONSOLE LOG: [0]

the notification will arrive about 1 minute and forty five seconds from the time the code runs. I've tried different use cases and the delay can be as large as 15 minutes to an hour. Lowering the delay to ten seconds after the code runs results in it arriving on time. Leaving the at parameter out results in the notification being shown immediately as expected. There doesn't seem to be much of a difference whether the screen is on or off when the notification is supposed to fire. Seeing as the screen is often on and there's still a delay, I don't suspect the issue is due to a battery saver or Doze.

From my reading of the Android documentation and this plugin's source code, exact alarms are being used with RTC_WAKEUP so there shouldn't be much of a delay in the showing of the notification.

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Comienza reproduciendo el retraso en Android 13 con el ejemplo de programación en JavaScript/TypeScript proporcionado, usando @nativescript/core 8.5.7 y @nativescript/local-notifications 6.1.1. Compara la hora at solicitada con la hora de entrega real en los dispositivos indicados; se considerará terminado cuando se haya identificado y corregido el retraso de programación y se haya verificado el comportamiento para intervalos cortos y largos.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
android, javascript, typescript
Área
mobile-dev
Tipo de issue
Error
Dificultad
4/5
Tiempo estimado
3-5 días
Estado de actividad
Estancado
Claridad
Necesita aclaración
Aptitud para principiantes
28/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.