Hi,
In my app i am allowing user to schedule local notification. The user also has the ability to modify the notification at a later stage. When the user modifies the notification, i need to:
Cancel old notification
Schedule the new notification.
I am struggling to implement cancel notification feature. As per API, i can use
system.cancelNotification(notificationID)
I just learned that notificationID is of the type: userdata, which is kind of a pointer to C/C++ object
At the first place, when the user schedules a new notification, i do get a handle to userdata notification id using the following code
local notificationId = system.scheduleNotification()
My struggle is how to persist this userData object. Because, the user could come back after 2 days to modify a scheduled notification. I need to persist the old notification id(userdata objects) to cancel them using system.cancelNotification
Has anyone encountered this or has any suggestion how to handle this.
The only other option is to cancel all notification and then reschedule them again…But then what is the use of the parameter notification in the cancelNotification function.
Hoping everyone is back from their vacations and active on the forums. Could anyone help me with this…I am clueless about handling this scenario
My simple question is how to cancel a notification which was scheduled in the past…Since the notification id (returned by system.scheduleNotification) is a USERDATA, i cannot store in the database for future reference. I need the notification id to cancel the notification.
Any help would be appreciated. I have not seen anyone discussing this in the forums. Am wondering if anyone has tried cancelling a notification?
I’m hoping that someone can give a definitive answer on this. I need to get the actual ID of the notification when it is set. i need to store this in a local DB so that if the notification is rescheduled i can find it and cancel it. Im really not fond of the idea of canceling everything and then trying to re build all of the local notifications. Seems that i am missing something. I have looked over all of the examples and they all seem to be missing a way to actually get the ID. Instead they all either call cancel all notifications or pass in a reference to the notification object that was just set.
if anyone can tell me what I’m missing it would be greatly appreciated.
Shawn - Unfortunately there is no other way to do it. You will have to cancel all notification and then reschedule it. I am still not sure why this limitation is there but this is the only way out…I know it sucks…
It will be great if someone from corona can explain if this is a short term issue or there is no way to get a pointer to the local notification on the device…
Bump, canceling all notifications and rescheduling them is Stupid. We should get an id that is actually usefull and can be persisted. This forces us to write less efficient code.
I’m not trying to argumentative, but can you clarify some more specific use-cases why this is a problem? How many local notifications might you have “active” at any time? If you have several, how “should” they persist? For the OS-determined life of the app? If so, what happens if the OS closes the backgrounded app to free up memory for newer-loaded apps? Then the “active” ID would be lost. So, in a way, you’re forced to store active notifications in a SQLite database, text file, etc. and then retrieve them if the app doesn’t know them (on cold start).
Again, I would like to hear some more details on this and why it’s causing such problems. Then maybe I can figure out a more elegant solution.
The short answer is that we’re given a userdata type which doesn’t seem like it wants to persist to a text format when we try. We can keep a table that will be cleared up when the app closes, but then we have no data related to its id when the app is started.
Any scheduling app will have multiple notifications and needs the ability to cancel and recreate specific ones. If a user makes a notification and then later decides to change the time at which it fires having the ID would be very helpful as it could be tied to that specific event, and only cancel that single notification, to recreate the new one, or cancel ONE specific notification we no longer want to send to the user.
But if we have say hundreds or more events, it means that we now have to persist all data associated with those events, use the cancel to destroy them all, and then iterate over our local copies of them and recreate all the ones we really wanted to keep.
For the time being I’ve written my own lib to encapsulate all this management and logic, but would prefer that corona provide a more easily used type that can easily be persisted in string based storage.
I am also having this identical problem. i have an app of mine that needs to schedule a bunch of alerts but some actions could cause 1 or 2 of the alerts to change times…
I can try that but in order to encode it do i not need the variable : notificationId to be something other then Nil? right now all that i get back from corona says that variable is a NIL. so how can i manipulate it at all?
bad argument #1 to ‘b64’ (string expected, got userdata)
stack traceback:
Any additional help from Corona would be appreciated here. again, according to your documentation we should be getting a return from the system.scheduleNotification API that we can store and be able to use it later to cancel the notification we are creating.
The Lua userdata that is returned by the system.schedueNotification() API is a C/C++ pointer (ie: a memory address). You should *never* save it. The reason is because when you restart your app, that memory address will become invalid (aka: a wild pointer) and will cause a crash if you attempt to use it. The reason Corona returns it as userdata/memory-address is because iOS does not actually provide an ID for local/scheduled notifications. So, there is nothing you can use to save to file other than what you’ve put into its custom data property. Unfortunately, Corona does not provide any means to fetch scheduled notifications on iOS.
Bump, canceling all notifications and rescheduling them is Stupid. We should get an id that is actually usefull and can be persisted. This forces us to write less efficient code.
I’m not trying to argumentative, but can you clarify some more specific use-cases why this is a problem? How many local notifications might you have “active” at any time? If you have several, how “should” they persist? For the OS-determined life of the app? If so, what happens if the OS closes the backgrounded app to free up memory for newer-loaded apps? Then the “active” ID would be lost. So, in a way, you’re forced to store active notifications in a SQLite database, text file, etc. and then retrieve them if the app doesn’t know them (on cold start).
Again, I would like to hear some more details on this and why it’s causing such problems. Then maybe I can figure out a more elegant solution.