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.

[MaikuB]

@icavanaugh95 Could you create a fork and make changes to example there? Could then take a look from your fork and probably issue a PR from there too once resolved

[icavanaugh95]

@MaikuB Yup just did that. Everything is set up. The new button schedules a few notifications at 10 second intervals starting at 45 seconds then cancels each one 20 seconds after the last is scheduled.

[MaikuB]

Thanks a lot for that as I was able to reproduce it. Turns out to be a silly mistake in the Java code due to how equality checks are done in Java and wasn't something I had been aware, having not done Java for a while and trying to translate my C# skills across :) Thought there was some smarts happening behind the scenes given using the equality operator was fine for the sample code I had.

Anyway, I believe this should be fixed now in 0.3.7 that I've just uploaded as the fix seemed to work on your fork. Let me know how you go.

Sidenote though, based on the sample you had made, I would recommend you try to await the completion of asynchronous code in general.

[icavanaugh95]

Oh ok thanks I will. I am still getting used to asynchronous code.

[MaikuB]

Yeah I originally tried to see if I could push changes to your fork but forgot there'd be permissions issues but in general, it's just to put await before every function that returns a Future (onPressed() {... } could then be changed to onPressed() async { ... }), otherwise you may end with a bunch of nested code so it's harder to read and could free up the thread to do other work in the mean time. Not to mention there are operations where you need to wait for something to be done before you can continue e.g. have to wait for a file to be opened before you can actually write to it but I think that's probably a given :)

[icavanaugh95]

Oh yeah thats why I thought I didn't have to await because I didn't need whatever function they were doing anymore.

The update does work on my end btw. The older notifications still pop up but no new ones are showing up after reboot. So after I clear the app data it should be good!

[MaikuB]

Good to hear :)
I'll wait to see how @SuitMonkeyB goes before I close this off.

[SuitMonkeyB]

Updated the package earlier and just finalized testing. I can confirm that the issue is now resolved. I'm able to schedule notifications that use larger notification ID's without them rescheduling on reboot despite being cancelled.

Repeating notifications reschedule on reboot as expected, continue to repeat, and only stop when outright cancelled like they should.

It works flawlessly.

Thanks a lot @MaikuB and @icavanaugh95

[MaikuB]

Awesome :)