Reading Push Notifications

[simon.schvartzman]

Hi, after several tries I got Push Notifications working on both Android & iOS but I have some doubts / questions regarding the behaviour on both platforms which I'm not sure if it is:

• to be expected
  a bug
  an undocumented difference between the platforms
  my lack of knowledge

My App is just one command line

Code: Select all

on pushNotificationReceived tMessage
   answer "Notification:" && quote & tMessage & quote with "OK"
end pushNotificationReceived

1 - Just One notification received while the App is not running
--- Android: When the App runs it shows the notification (pushNotificationReceived is called)
--- iOS: When the App runs no notification is shown (pushNotificationReceived is not called)

2 - Several Notifications received while the App is not running
--- Android: When the App runs it shows just the first notification while resets all the badges on the status bar
--- iOS: When the App runs no notification is shown. Notifications alerts remain untouched.

3 - Just One notification received while the App is running
--- Notification is shown in both platforms (pushNotificationReceived is called)

4 - Several Notifications received while the App is running
--- On both platforms the notifications received while the previous one has not been acknowledged are lost.

I'm probably missing something. In short I'd like to know if there is some way to read all the "notifications received" on both platforms on both conditions (app running or not)

Thanks and sorry for the long / confuse post.

[Mikey]

ios only because we're not doing android at this time

A. There are multiple feature requests for push on ios in the quality center, so you might want to read those since push doesn't work as well as we'd like. Also note that APNS does not guarantee delivery, so it's up to you to manage your data separately, including the payloads, in case they don't make it (or, as you've discovered, they payload is dropped).
B. To your questions
1. Correct. Use iphoneNotificationBadgeValue() to determine if you have an unhandled push notification (of course when you push, you would need to set the value, then, too).
2. See #1
3. Correct.
4. Correct. One of the bug reports I filed was on silent notifications, which may resolve this, but really what you should do is have your app poll your server, and then mainly use push to coax your app or the user of your app into action.

[simon.schvartzman]

Hi Mikey, many thanks for your useful answer. Still confused about a few things:

1. Correct. Use iphoneNotificationBadgeValue() to determine if you have an unhandled push notification (of course when you push, you would need to set the value, then, too).

I can easily check if the Badge > 0 but I don't understand what to do next, from where (or how) should I retrieve the payload? The following code, needless to say, retrieves an "empty" notification

Code: Select all

on openStack
   if (iphoneGetNotificationBadgeValue() > 0) then
      pushNotificationReceived
   end if
end openStack

4. Correct. One of the bug reports I filed was on silent notifications, which may resolve this, but really what you should do is have your app poll your server...

How can the app poll the server? I couldn't find any command to do so...

Thanks and regards

p.s.: working with notifications is far from being trivial as you said in an answer to a previous post and it seems LC has room to improve how it handles the subject

[Mikey]

One other thing to remember, because sooner or later this will bite you: On iOS, the pushID of the device WILL change periodically (and the user might also disable push notifications, so the pushID would be empty). It can happen when the device gets wiped, when there is a major OS update, when the user uninstalls/reinstalls your app, and I don't know when else. All I know is that it will change, and in the cases of some devices, multiple times in a fairly short period. At startup we therefore grab the push ID, compare it to the old push ID, and if it's changed we notify our server. If the user uninstalls and reinstalls your app, there's a good chance the app data got wiped, too, so just keep that in mind.

Starting with your P.S., I don't know the mechanics of it. It might be that LC can't do anything more than what it does (but obviously I don't know that).

When you launch the app, all you can do is check the badge. After that you have to decide what to do. What I would suggest is you have your app poll your server to see what's up.

Since Dropbox is quick, cheap, and easy to use with LC (and conceptually easy), what I suggest is this:
1) When your server decides it needs to notify a mobile, it can write a file to Dropbox. Alternatively, on the server you can have a DB that keeps track of the mobiles and knows what needs to be sent to the mobile.
2) Push. Don't expect the message to arrive, or for the payload to be of any use. Set the badge, though. Your server can, as part of tracking the mobile, know the last value of the badge, and increment it, if you like.

Then in the app,
1) When you start, check the badge. If the app is already running and it gets a notification, you'll get a payload, which you can use
2) Either prompt the user to poll the server, or do it automagically. If you are prompting the user, you can add a "sync" button for them. This is our preferred way to do things because we assume poor network connectivity and "I've got better things to do than wait for this thing to phone home". If your users are on a phone, then maybe the poor network connectivity might not be an issue. For wifi devices in a warehouse or off-site, their normal mode will be poor or no network.
3) When you want to hit the server, if you're using Dropbox, grab the file for the device and see what it says, or if you're hitting you own server, log in and see what you're supposed to do.
4) If you're going the Dropbox route, your app should remove or otherwise mark the file, and reset its badge to 0. If you're using your own server, your server can push an empty payload with a "0" badge when it is satisfied that the app has completed its tasks (you could also let the app do this, of course).

[simon.schvartzman]

Thanks again Mikey...

One other thing to remember, because sooner or later this will bite you: On iOS, the pushID of the device WILL change periodically ...

Great hint, I'd never had guessed it.

Starting with your P.S., I don't know the mechanics of it. It might be that LC can't do anything more than what it does (but obviously I don't know that).

I'm a great LC fan but sometimes (and this is one of those times) is really frustrating to find out serious limitations as this one and reach the conclusion that there is so much than can professionally be done with the tool... I seriously doubt there is nothing LC can do about it

Since Dropbox is quick, cheap, and easy to use with LC...

Your "hybrid" Notification + Dropbox schema is a brilliant workaround and I'll follow that path.

Cheers!