launchArgs.notification not set when tapping icon rather than tapping the actual notification

Solar2D General Questions/Discussion
#1

In post: http://forums.coronalabs.com/topic/36167-i-dont-get-remoteregistration-event/

Rob Miracle says, On an app cold start: "If you start your app by tapping it’s icon, launchArgs.notification won’t be set.   If you tap the notification and the OS starts your app code, then you get launchArgs.notification.

So the issue I’m having with this is

My icon is there, showing a badge of 1 …  so doesn’t it make sense, like with any other App, the user might see the notification, but instead tap on the icon where they see the badge? Perhaps the notification disappeared at the top of the screen – perhaps the user doesn’t even know how to use the notification center.  They see the notification, they see a badge of 1, so they tap on the app.

But then, when the App starts, there is no information returned about the notification.

It just seems strange that you would start up an App with a pending notification, but then give us no way to know the notification is there pending.

So then the user will just see the badge number there, and they will have to eventually go into their notification center, locate the push message and tap it?  There’s no other way for them to have the App respond with the appropriate response to the message’s payload?

Doesn’t seem right.  It seems that launchArgs.notification SHOULD BE SET if the App is launched from a cold start with a pending badge and a pending notification.

I have confirmed it does work the way Rob says, but I’m unaware of any other App that works this way.

How can I access LaunchArgs or notification event from an App cold start with a pending notification?
 

#2

You can get the current badge number from your app using the native.getProperty() API call (see: http://docs.coronalabs.com/api/library/native/getProperty.html).

If you see you have a positive badge count, your app can contact your service that’s generating the push.  For instance, when we had Corona Cloud, it could send you pushes to let you know you have moves.  But from the app, you could contact the server and say “give me my latest moves”, “give me my latest invitations”, etc.   So depending on what you’re doing, there may be an “out of notifications” way of finding out what is trying to communicate with your app.  However if you’re using  a service that  just broadcasts messages and doesn’t have two way integration, then a cold start of your app has no way to get that notification.

#3

You can get the current badge number from your app using the native.getProperty() API call (see: http://docs.coronalabs.com/api/library/native/getProperty.html).

If you see you have a positive badge count, your app can contact your service that’s generating the push.  For instance, when we had Corona Cloud, it could send you pushes to let you know you have moves.  But from the app, you could contact the server and say “give me my latest moves”, “give me my latest invitations”, etc.   So depending on what you’re doing, there may be an “out of notifications” way of finding out what is trying to communicate with your app.  However if you’re using  a service that  just broadcasts messages and doesn’t have two way integration, then a cold start of your app has no way to get that notification.

#4

To summarize:

  1. even with a positive badge # showing on the app icon
  2. if the app is not running (inactive and unlaunched)
  3. and the user launches it thru it’s icon or badge (not thru the notification alert)
  4. then launchArgs will NOT be set/passed

In the above scenario, at launch time, you have to:

  1. detect that you have a positive badge #
  2. network.request your own server to ask whats up
  3. respond accordingly to the results of your REST call
  4. clear the badge (to zero)

Did I get all that right?  Please confirm.

And if so, you REALLY should add this clarification to the docs

Thx

D

#5

The docs seem to say what this needs to say.  Yes it’s a bit terse, but the info is there.  We also discuss it a bit more in the notifications guide: http://docs.coronalabs.com/guide/events/appNotification/index.html

The badge number is kind of irrelevant it’s just an adornment to the icon.  If you tap the icon on an inactive app, the OS doesn’t know that you want to deal with the notification, so it just starts normally.  This is why the suggestion that you can check the badge count to see if you have pending notifications.

If you interact with the notification and your app is not running, then the app gets “launched”  and you will get information through the launchArgs.  If your app is backgrounded, its brought to the foreground and the notification event fires with the information the notification is carrying.  If the app is forgegrounded, you get the notification event but since the app wasn’t “launched”, no launch args.

So yes, you’re scenarios are correct.

#6

Rob, thanks for the validation.   And yes, you are right, the info is there…and if it was “clear-enough” there would be fewer of these posts (that you have to respond to) where people are posting problems or asking for clarification.  To make your life easier, and our productivity higher, I’m in favor of taking this really-well digested learning from the forums, and continually feeding it back into the documentation…thats just my 2 cents…you guys do whatever you think is best.

Thanks again.
Dewey

#7

I’ve had exact same reaction many a times and was told to provide feedback through the “I Hate it” button on the docs pages. It appears that there is not that much of proactive documentation improvement based on the discussions on this forum. It is up to us whether we want to flag API docs for potential improvement & corrections. I simply don’t most of the time due to time constraints.

#8

Well I wouldn’t “I hate it” if you don’t hate it.  I prefer the “I like it but” button myself.

If you do have issues with documentation, be it something not clear, the example not working, etc. by all means hit the button at the bottom and let us know.

While we love the forums and think we have an awesome community, it’s the most inefficient way of tracking work needs.

Rob

#9

Hey Rob…I totally agree with you that forum content makes a TERRIBLE “to do” list…it is really inefficient…I totally give you that.

At the same time, this forum content is a STRONG “TELL” about what is not clear, or obvious (or even missing) in the official docs…it is the best feedback you/CL have about where your developers (all smart people) are getting lost or stuck.

And every time we get stuck, it costs CL time, money and goodwill…not to mention more Corona apps going out…

Even if every single developer in this thread were to go to the page I linked above, and click the “I like it but” button to provide feedback, what we entered (as individual complainers) would NEVER be able to express the clarity, simplicity and succinctness that one can derive (as I did) from this whole thread in its entirety…and honestly, it’s not our job to do that.

This thread represents a “gestalt” of the core ideas that are hard to derive from, or see within, the docs, and I don’t think you will ever get (or act on) such quality feedback from a hodge-podge of individual  “I like it, but…” entries…in fact, whoever reads those multiple, disjointed entries and tries to figure out how to amend the docs in response, will have to go through the exact process of synthesis and digestion that we have already completed here…it’s really a shame to throw this clarity away because someone established an ineffective policy in the past…ok, now I’m at 5 cents but you get the picture :wink:

#10

To summarize:

  1. even with a positive badge # showing on the app icon
  2. if the app is not running (inactive and unlaunched)
  3. and the user launches it thru it’s icon or badge (not thru the notification alert)
  4. then launchArgs will NOT be set/passed

In the above scenario, at launch time, you have to:

  1. detect that you have a positive badge #
  2. network.request your own server to ask whats up
  3. respond accordingly to the results of your REST call
  4. clear the badge (to zero)

Did I get all that right?  Please confirm.

And if so, you REALLY should add this clarification to the docs

Thx

D

#11

The docs seem to say what this needs to say.  Yes it’s a bit terse, but the info is there.  We also discuss it a bit more in the notifications guide: http://docs.coronalabs.com/guide/events/appNotification/index.html

The badge number is kind of irrelevant it’s just an adornment to the icon.  If you tap the icon on an inactive app, the OS doesn’t know that you want to deal with the notification, so it just starts normally.  This is why the suggestion that you can check the badge count to see if you have pending notifications.

If you interact with the notification and your app is not running, then the app gets “launched”  and you will get information through the launchArgs.  If your app is backgrounded, its brought to the foreground and the notification event fires with the information the notification is carrying.  If the app is forgegrounded, you get the notification event but since the app wasn’t “launched”, no launch args.

So yes, you’re scenarios are correct.

#12

Rob, thanks for the validation.   And yes, you are right, the info is there…and if it was “clear-enough” there would be fewer of these posts (that you have to respond to) where people are posting problems or asking for clarification.  To make your life easier, and our productivity higher, I’m in favor of taking this really-well digested learning from the forums, and continually feeding it back into the documentation…thats just my 2 cents…you guys do whatever you think is best.

Thanks again.
Dewey

#13

I’ve had exact same reaction many a times and was told to provide feedback through the “I Hate it” button on the docs pages. It appears that there is not that much of proactive documentation improvement based on the discussions on this forum. It is up to us whether we want to flag API docs for potential improvement & corrections. I simply don’t most of the time due to time constraints.

#14

Well I wouldn’t “I hate it” if you don’t hate it.  I prefer the “I like it but” button myself.

If you do have issues with documentation, be it something not clear, the example not working, etc. by all means hit the button at the bottom and let us know.

While we love the forums and think we have an awesome community, it’s the most inefficient way of tracking work needs.

Rob

#15

Hey Rob…I totally agree with you that forum content makes a TERRIBLE “to do” list…it is really inefficient…I totally give you that.

At the same time, this forum content is a STRONG “TELL” about what is not clear, or obvious (or even missing) in the official docs…it is the best feedback you/CL have about where your developers (all smart people) are getting lost or stuck.

And every time we get stuck, it costs CL time, money and goodwill…not to mention more Corona apps going out…

Even if every single developer in this thread were to go to the page I linked above, and click the “I like it but” button to provide feedback, what we entered (as individual complainers) would NEVER be able to express the clarity, simplicity and succinctness that one can derive (as I did) from this whole thread in its entirety…and honestly, it’s not our job to do that.

This thread represents a “gestalt” of the core ideas that are hard to derive from, or see within, the docs, and I don’t think you will ever get (or act on) such quality feedback from a hodge-podge of individual  “I like it, but…” entries…in fact, whoever reads those multiple, disjointed entries and tries to figure out how to amend the docs in response, will have to go through the exact process of synthesis and digestion that we have already completed here…it’s really a shame to throw this clarity away because someone established an ineffective policy in the past…ok, now I’m at 5 cents but you get the picture :wink: