Cancel Local Notification by passing notification id(of type UserData)

Solar2D General Questions/Discussion
#1

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:

  1. Cancel old notification
  2. 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.

Any help is appreciated.

thx,
Bejoy
[import]uid: 84539 topic_id: 19833 reply_id: 319833[/import]

Cancel a weekly local notification
#2

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?

thx,
Bejoy

[import]uid: 84539 topic_id: 19833 reply_id: 77326[/import]

#3

Please see this thread for resolution

http://blog.anscamobile.com/2011/09/local-notifications-now-in-daily-builds/comment-page-1/#comment-6326
Essentially you have to use cancelNotification() to cancel all notifications and reschedule all notifications again…
[import]uid: 84539 topic_id: 19833 reply_id: 77386[/import]

#4

I’m sorry - apparently this got a bit buried!

My apologies that you had to wait - and my congrats for solving the problem.

Peach [import]uid: 52491 topic_id: 19833 reply_id: 77498[/import]

#5

Thanx for following up Peach… [import]uid: 84539 topic_id: 19833 reply_id: 78948[/import]

#6

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.

thanks in advance

Shawn [import]uid: 89018 topic_id: 19833 reply_id: 108282[/import]

#7

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…

thx,
Bejoy [import]uid: 84539 topic_id: 19833 reply_id: 108317[/import]

#8

Bejoy,

Thanks for the update. I agree, if someone from Ansca could let us know why we would ever need to call

system.cancelNotification(notificationID)

if you cannot get an actual notificationID. Makes no sense to me.

Shawn [import]uid: 89018 topic_id: 19833 reply_id: 108334[/import]

#9

This is a 1 year old thread, but we are still facing this problem, and this is extremely stupid.

#10

This is a 1 year old thread, but we are still facing this problem, and this is extremely stupid.

#11

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.

#12

Hi all,

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.

Regards,

Brent

#13

Brent,

  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.

Thanks for responding,

Chris

#14

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…  

but they have already been scheduled.    

now according to the Corona Docs on this page:  http://docs.coronalabs.com/api/library/system/scheduleNotification.html

is says " Returns a reference id that can be used to cancel the notification."  however using Corona Labs own example on the same page.  

notificationId = system.scheduleNotification( utcTime, options )

which is find but if you add a simple print statement after it you will get an error

notificationId = system.scheduleNotification( utcTime, options ) print("notificationId is: ",notificationId )

this print statement says it cant print a NIL.    but if you watch your logs in xCode, its actually a userdata object.

If i can’t print the value and i cant store the value in the database that it returns…  THEN how can this statement be true?

" Returns a reference id that can be used to cancel the notification."  _ ~Corona _

#15

Have you considered base64 encoding the userdata and saving that?  When you base64 decode it, you should end up with the object again.

There is a base64 encode/decode pair in the “mime” library or tons of b64enc type functions as lua string recipes that you could google

#16

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?

#17

Ok i have tried to base64 encode the results and still get an error.

 Jul 15 09:57:08 Learning-Gems-iPad3 1306-MyEvents[5114] <Warning>: Runtime error

    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.  

#18

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.

#19

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.

#20

Hi all,

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.

Regards,

Brent