Notifications not getting scheduled

[mk-dev-1]

Describe the bug
When scheduling multiple notifications in a row, individual notifications get swallowed (i.e. do not get scheduled). When adding a tiny delay of 15ms everything is working as expected.

As far as I can see this issue started appearing with one of the latest revisions. I had trouble recreating the issue consistently, particularly as in my app I was running the scheduling routines asyncronously and even in separate isolates. When creating this simple test app, I could consistently reproduce the issue every time.

To Reproduce

1. Hit Schedule with await
2. Hit Check
3. Check console output listing which IDs have not been scheduled

Expected behavior
Expecting to see all notifications scheduled

Sample code to reproduce the problem
https://github.com/mk-dev-1/flutter_local_notifications_sample/blob/master/lib/main.dart

[MaikuB]

Thanks will take a look. My first guess would be it would be due to this PR

#980

With what you described though, I believe the notifications should still be scheduled and that the issue is that the results from finding the pending active notifications is incorrect as that data comes from reading from shared preferences as Android doesn't actually have an API specific to scheduling notifications or an API to query which ones are scheduled

[MaikuB]

Unfortunately I can't reproduce this on my own device (Pixel 6) or emulator. I am trying to source a cheaper device with lower specs but would take some time to arrive though I don't know it would help with reproducing the issue. What device/emulator were you testing this on and could you include the output of running flutter doctor -v?

One thing I would suggest trying is to see if you can fork this repo, make changes to how data is saved to shared preferences so it's done similar to how the Flutter shared_preferences plugin does this (see https://github.com/flutter/plugins/blob/5bf7fb0360aa70571c46d5b0ac64949fc81a0dfd/packages/shared_preferences/shared_preferences/android/src/main/java/io/flutter/plugins/sharedpreferences/MethodCallHandlerImpl.java#L137) to see if it'll fix the issue

[mk-dev-1]

I am using a Pixel 3a Android 12 emulator on an M1 Macbook Air. Here is the Flutter doctor output:

[✓] Flutter (Channel stable, 2.5.3, on macOS 12.0.1 21A559 darwin-arm, locale de-DE)
[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
[✓] Xcode - develop for iOS and macOS
[✓] Chrome - develop for the web
[✓] Android Studio (version 2020.3)
[✓] VS Code (version 1.61.2)

Will see if I can reproduce it on an actual device.

Edit: If I understand correctly, the only way to get the ID of a notification is to set it yourself and/or rely on the pendingNotificationRequests, correct? Is it safe to say then that if I do not capture the ID anywhere it is impossible for me to cancel all notifications, evening using cancelAll? Reason I am asking is because I am still getting spammed on the emulator with notifications that I would have expected to be cancelled by cancelAll... Am I missing something?

[MaikuB]

If I understand correctly, the only way to get the ID of a notification is to set it yourself and/or rely on the pendingNotificationRequests, correct?

That or you can include it in the payload. You could serialise the content that matters to you as a JSON string.

Is it safe to say then that if I do not capture the ID anywhere it is impossible for me to cancel all notifications, evening using cancelAll?

cancelAll should cancel all notifications without the IDs. I believe I've found the issue though where the Future on the Flutter side has completed but the Android side hasn't actually completed. This is due to an issue with the code where the PR mentioned before put in a change where it flagged the platform channel call as succeeded before it was done. I've pushed a commitAsync that should fix this issue you're having. Could you help test this e.g. by pointing your example app to that branch? If this works, I'll publish a prerelease so that hopefully others in the community can also help test this for a period and then include this in a stable release

[MaikuB]

FYI whilst I've not heard, I've released 9.1.1 with the changes as it looked fine from my own testing

[mk-dev-1]

I can not recreate the issue with 9.1.2, but in 9.1.3 its back again, which is what I would have expected....

[MaikuB]

@mk-dev-1 could you help test a fix that I've got in the sharedPreferencesApply branch? this was something I was looking to include in a 10.0.0 prerelease but thought it'd best if I could get some feedback first.

You should be able to use a Git dependency by specifying the following in your pubspec.yaml file

  flutter_local_notifications:
    git:
      url: https://github.com/MaikuB/flutter_local_notifications.git
      path: flutter_local_notifications
      ref: sharedPreferencesApply

[mk-dev-1]

Will try to test over the weekend

[Ahemad7429]

Any updates on this?

[MaikuB]

@mk-dev-1 did you get to test branch?

[MaikuB]

@Ahemad7429 you could also help by test by using the branch I've mentioned

[JeroenvdV]

The following may relate to this: #1448

I can show the above problem in the emulator, so I'll test the branch from this thread.

[VirtualAstronaut]

sorry for reporting too soon so I changed version but did not use flutter clean after that it was showing updated IDs.

Hello i am trying to schedule like 6 notifications at same time in for loop but it gives wrong pendingNotificationList length so i added like 100ms delay now it shows correctly should i open another issue?
as 9.2.0 changelog i assumed it's fixed but I still get wrong length.
IDs from logs
so notification with same ID gets stacked or something and first identical comes when second one is triggered.
[1, 2, 2, 3, 3, 4]

[MaikuB]

You should bump your dependency first. 9.2.0 isn't the version with the fix. GitHub should've showed which PR closed this issue. You can also subscribe to the repo to find out when there are new releases

[VirtualAstronaut]

yp

You should bump your dependency first. 9.2.0 isn't the version with the fix. GitHub should've showed which PR closed this issue. You can also subscribe to the repo to find out when there are new releases

yes I am using latest dependency, Okay I will subscribe Thanks for reply 😄 .