Cancel_all works ok, but cancel doesn't seem to work:
import notification
n=notification.get_scheduled()
print 'initial num notifications:', len(n)
notification.schedule('test',120)
n=notification.get_scheduled()
print 'added one: ', len(n)
notification.cancel(n[0])
n=notification.get_scheduled()
print 'after cancel', len(n)
The result:
initial num notifications: 3
added one: 4
after cancel 4
Thanks, I'll look into it.
A delay after cancel helps, e.g. time.sleep(1) works on my iPad version 3.
Good luck!
Cherubjk
Well, I have two notifications that simply won't delete, it has been a few days!
In case it matters, the two have the same message and action, no sound, slightly different fire times. Here's the result of get_scheduled. I was trying to prune notifications of the same name. I think it must sometimes work, otherwise I'd probably have more of these.
[{u'action_url': u'pythonista://renewbooks?action=run', u'sound_name': u'',
u'message': u'renew books', u'fire_date':1396594740.000119},
{u'action_url': u'pythonista://renewbooks?action=run', u'sound_name': u'',
u'message': u'renew books', u'fire_date': 1396594740.000122}]
Also... In the code above, I have found that if you store the result of schedule(), you are able to cancel it. But when schedule is called without outputs, no go.
I'm running ios 7.1, ipad 2.
Original code works fine for me.
IPhone 5s, ios 7.1
initial num notifications: 0
added one: 1
after cancel 0
Try creating several notifications and then see if you can replicate the problem.
It is strange, sometimes it works, sometimes it doesn't.
What seems to reliably fail... Create a notification. Then, kill the app.
Then, launch again and try to cancel the notification.
I think this may also happen when the task gets killed in the background when memory runs low.
I made a couple more tests.
I have put your code, JonB, into a loop except the initialization. Then I checked under what conditions the cancellation fails. Comparison of the fire date in the return value of notification.schedule with the corresponding value in the last element returned by notification.get_scheduled showed a tiny difference in every case of failure, and no difference in all cases of success.
Managing the results of notification.schedule in an own list and using these elements for cancellation always works.
I guess this cannot be circumvented in a script.
@omz: Fantastic app though!
Chears