Dear Corona Labs,
It is next time I face this problem where in documentation you do not include essential informations or parts of it and you write it only in guides or developer learns this after digging forums.
The part I’m referring now are notification. You write that when one schedule Notification, he gets reference id which can be used to cancel notification. But you skip important part which should be in documentation. If you write ‘id’ developer usualy expects it to be number or even string, but it’s userdata type! What’s more, information that if application restarts, this ‘ids’ are no longer valid because there were parts of program (pointers probably) runtime memory and not something stored on os level, also isn’t mentioned (found it on forum - but it’s crucial I think). If developer assumes (as I) that ‘id’ type is some normal kind and will try to save it to file (I had it on android), application doesn’t print errors but some parts of program beceomes corrupted.
Please do not write something so vague as ‘reference id’ (even it is true in C/C++ layer) because it is really misleading!
Can anyone from Corona Labs elaborate why it’s this way?
When you see a type of userdata, this is data that comes back from a C/C++ library call. It’s a chunk of memory that Lua can address (a pointer) to get to children structure members (if the userdata is a structure) but because it’s a memory reference to an object that won’t be available the next time the program runs, it’s not savable. This if course leads to the question “Well can’t you give me an id I can save and reference later?” and the answer there is with a high degree of certainty, no. We are frequently restricted at what we can do by the native SDK’s that we call.
As for the documentation, there are buttons at the bottom where you report issues, like bug reports, this is how work gets to the team that updates the documentation. We can read your posts and send emails in, but at the end of the day, those buttons are what drives documentation fixes. I agree there probably should be a reference to userdata mentioned there. I will see if I can get it updated.
Rob
I know this all 
The point was that documentation was missing even short notice about this fact, because “reference id” is a bit too vague. I bet that almost nobody ever checked what type of data it is, expecting at least some number
Thank you very much for adding “Android notification handling” to documentation. I hope it will help people in future
Can anyone from Corona Labs elaborate why it’s this way?
When you see a type of userdata, this is data that comes back from a C/C++ library call. It’s a chunk of memory that Lua can address (a pointer) to get to children structure members (if the userdata is a structure) but because it’s a memory reference to an object that won’t be available the next time the program runs, it’s not savable. This if course leads to the question “Well can’t you give me an id I can save and reference later?” and the answer there is with a high degree of certainty, no. We are frequently restricted at what we can do by the native SDK’s that we call.
As for the documentation, there are buttons at the bottom where you report issues, like bug reports, this is how work gets to the team that updates the documentation. We can read your posts and send emails in, but at the end of the day, those buttons are what drives documentation fixes. I agree there probably should be a reference to userdata mentioned there. I will see if I can get it updated.
Rob
I know this all
The point was that documentation was missing even short notice about this fact, because “reference id” is a bit too vague. I bet that almost nobody ever checked what type of data it is, expecting at least some number
Thank you very much for adding “Android notification handling” to documentation. I hope it will help people in future