On restart, all previous notifications reschedule themselves despite being dismissed before.

[SuitMonkeyB]

Hi MaikuB,
I seem to be encountering an issue where when notifications are displayed and manually dismissed, upon restarting the device, when the phone boots up, all previous notifications that occurred while the phone was turned on suddenly all come in all at once. It's as if they were never really dismissed.

If I set a notification to fire at a specific time, it, fires, then I manually call "CancelNotification" on that single notification with that ID, even though this successfully removes the notification and dismisses it from the status bar, when I restart the phone, it reappears as if it were never canceled.

If I use "CancelAllNotifications" however, it does truly "cancel" it and previously dismissed notifications don't reappear upon restart, but obviously, I can continuously call "CancelAllNotifications" for a single notification because it will remove all the other unrelated notifications iv'e set up as well.

Any idea about this?

[MaikuB]

Afraid not and couldn't reproduce the scenario you've mentioned using the example either where I've scheduled a notification to appear 5 seconds later, let it appear, cancel it and rebooted. If you follow those steps using the example app do you experience the same issue? If you can, try to fork the repo and create an example that can reproduce the problem

[SuitMonkeyB]

Hmm, I cant seem to reproduce it in the example, which leads me to question if my setup is wrong. To set up iv'e imported the package, made the changes to my android manifest file, copied over the initialization:

`FlutterLocalNotificationsPlugin flutterLocalNotificationsPlugin;

var initializationSettingsAndroid =
new AndroidInitializationSettings('app_icon');
var initializationSettingsIOS = new IOSInitializationSettings();
var initializationSettings = new InitializationSettings(
initializationSettingsAndroid, initializationSettingsIOS);
flutterLocalNotificationsPlugin = new FlutterLocalNotificationsPlugin();
flutterLocalNotificationsPlugin.initialize(initializationSettings,
selectNotification: onSelectNotification);`

and defined the futures necessary for the functions to work. Am I missing something? This is on android btw.

Oh i totally forgot to stress that this seems to only be happening with "_scheduleNotification()" and apparently repeatNotification().

Also, the way my app is set up is that a notification is tied to an object. That object has a unique ID which is the ID pass to the notification. This is done so when I remove a specific object, I can then cancel any notifications scheduled for that object because the notification will share that ID. But upon restarting the device, they just reappear as if they were never cancelled or dismissed, eventhough they were successfully dismissed and cancelled while the device was on. The issue seems to be anything schedule related.

[MaikuB]

Can't really tell based on you've shown. _scheduleNotification() and repeatNotification() aren't functions in this plugin though I get which ones you meant. As mentioned earlier, I'd suggest forking to reproduce the problem. You could also try grabbing the source code for the plugin and reference a local copy in your app to debug to see what's going on.

[SuitMonkeyB]

Ok so I think I found the issue.

When scheduling notifications like for example using flutterLocalNotifications.schedule(...), I'm using a unique ID for each notification and not using the default ID interger value of this function which is set to '0'. Instead I'm passing my own unique ID that I can reference later.
That' logic is all fine.

The issue where notifications reappear upon restarting the phone seems to only happen for notifications where the ID passed is larger than a certain amount. It's probably around the number 200 or so, maybe even lower than that, but since restricting the IDs I'm passing to the function to bewteen 0 and 99, I don't have the issue.

Originally my IDs were unique 9 digit intergers for example "160001728"... notifications with ID's like this would immidiately appear on restart despite being cancelled, so I changed to 3 digit ID's like say "634".... The issue still persisted, so finally I limited all my ID's to 2-digit integers, for example "56", and now they function as expected and behave similar to how they do in the example.

So, I don't know if it's the logic (which is fine as far as I'm aware), or an internal issue with Android where having notification ID's larger than a certain interger causes them to never truly dismissed or behave incorrectly, but that's what fixed it for me. Literally the only difference between the example and what I was doing that caused the error to occur was the IDs being used.

Thanks a lot MaikuB.

[MaikuB]

Hmm perhaps you've run into a a quirk with how Flutter handles passing int values via platform channels https://flutter.io/platform-channels/

Will investigate and see

[MaikuB]

Nope just tried with the values you've listed and they come through as integers on the Java side and is within the range in that I mentioned. Makes sense given you've been able to cancel them too. Not sure what's happening in your case. Out of interest, what version of Flutter and the notification plugin are you using?

[SuitMonkeyB]

Android Studio 3.1, Flutter master channel v0.5.8-pre.163, Flutter Local Notifications 0.3.6.

I switched from beta to master channel during testing but it made no difference.

[MaikuB]

Ok so you're on similar builds to mine then. I might have to close this as I can't reproduce it based on the values you're using it and haven't heard of similar problems to yours. If you (or someone else) are able to provide a sample that reproduces the problem (and even better provide a PR to fix the issue if one is found) then that would be great. I'd imagine it's something you might not have time to look into?

[SuitMonkeyB]

Yea unfortunately no more time to dig any further. That's completely fine, close away; maybe someone else might have better luck. It seems to be an isolated issue only affecting my project, but I'm satisfied with the workaround.

[icavanaugh95]

No SuitMonkeyB you're not alone I was just looking into the same issue with my project. I had the same issue with the example as well. However I did change the example a little so that may be on my end. I am doing the same thing as well using large integers for the channel id. I will let you guys know if I find anything.

[MaikuB]

thanks @icavanaugh95. i'll leave this open in the mean time then

[MaikuB]

@icavanaugh95 btw what values are you using? I don't know if you've seen the link I posted above (https://flutter.io/platform-channels/) but when numbers get too large they may end up being translated to be a long. Notification ids on android need to be an int though. Might be something i'll need to add to the documentation

[SuitMonkeyB]

Yea it's a strange one. Having a 3 digits shouldn't affect an interger's behavior. I will try to get around to testing it some more to pinpoint the cause.

[icavanaugh95]

@MaikuB originally I was using numbers that would be long in java the the plugin throws an error. So you have to use a number that would be an integer in java. My project is using numbers that have 9 digits but the max java int is 10 digits. Attached is a screenshot of the notifications that are showing up on boot after they've been canceled, the notifications display the used channel id. I used your example app and your code. All I changed was the notification content and schedule times. Not sure if it makes a difference but I only got this error to occur if I dismissed the notifications, as in swiping it off the screen, before the notifications were canceled.

The notification not displayed is another 5 digit channel id.