We just have a few questions

[somefakeuser]

Hi Arley,

Thanks for the great library. We just have a few questions:

1. Is it safe to continually register the device or should the token be persisted and then checked to prevent multiple registrations?
2. We have some questions about receiving notifications between the different platforms. Please refer to the gist. This is mostly due to our lack of understanding between the platforms.
3. At what point is a notification created. e.g. For android, does the module make a notification in the action bar or do we do that? If the module is responsible, can we customize the look and feel of the notification? What about for iOS?
4. If the app is running in the background, how does receiving the notification work? I guess we would be responsible for opening the correct part of our app to respond?

Thanks!

[arleyandrada]

Hi,

Sorry by delayed response.

Check below for answers to your questions.

Regards,

Arley

1) Yes, it's totally safe and recommended.

My module deals with a persistence to previous registered key and also treats issues like changing the version of the app that may require a new registration key.

2) All the callback events can occur both in Android as in iOS.

To an iOS app receive an MODE_BACKGROUND callback event it's required to use the new "remote-notification" feature from iOS 7. http://hayageek.com/ios-silent-push-notifications/

MODE_FOREGROUND => Your app is active and in foreground when the push notification arrives; No sound, no message is showed in notification tray; You decide what to do whith received info.

MODE_CLICK => Your app is not in foreground; Can be active or stopped; An message is showed in notification tray and/or with sound, vibration, lights, etc... according to your sent payload data; When the user clicks on the showed message in the notification tray, your app is started or putted in the foreground and this callback is fired with all payload data;

MODE_BACKGROUND (Android) => Fired when your app is active but is not in foreground; Does not prevent the MODE_CLICK event is triggered later when the user clicks on the showed message in the notification tray;

MODE_BACKGROUND (iOS) => Fired when your app is not in foreground (active or stopped) and you used the new "remote-notification" feature from iOS 7; Does not prevent the MODE_CLICK event is triggered later when the user clicks on the showed message in the notification tray.

3) When your app is not in foreground (active or stopped) an message always will be showed in notification tray for iOS or Android.

You can choose from some behaviors to the received notification through the sent / received payload data, according to my documentation: sound, vibrate, lights, title, message...

Unfortunately with iOS (even native) you can't customize the message showed in the notification tray; You are limited to choose the "alert" (text message), an optional "sound" and an optional "badge"; Always displayed with the same icon used in the application.

To iOS 8 (native) you could use a better interactivity with the notification, but this is still not supported by my module.

With Android (native) you could customize in many others ways, but still with my module you will be limited to use the documented options through the sent / received payload data.

Please, let me know if you need any special / specific behavior or customization.

4) I believe that my previous answers already answered this question.

The callback events is everything you need to code any behaviors to your app.

Sorry by my poor english.

[somefakeuser]

Hi Arley,

Your English is great!

Thank you for the clarifications. We've done some quick testing on android and the only thing we can't get to work properly is the "PushClient.MODE_CLICK" callback type.

We register the callback in our alloy.js file on app start. When clicking on the notification, our app starts, however, the callback is never fired.

Any suggestions?

Thanks,

[arleyandrada]

Hi,

I could not reproduce this behavior.

Try to click on the message in notification tray with your app in background and also with your app stopped (kill it before to click).

Please, send to me the full Titanium console log after these tests.

What is the Titanium SDK version? What is the device used and his Android version?

Maybe also could you share your entire project with me (or a minimal version of it)?

Regards,

Arley

[arleyandrada]

Hi,

Have you solved the problem by yourself?

Please let me know if you need some help.

Regards,

Arley Maria

[somefakeuser]

Hi Arley,

Not yet but I've gone on holiday for a week. I'll get back to you after. Thanks!

[somefakeuser]

Hi Arley,

I'm just following up to this issue.

We basically have our own prototype wrapper that is sets up the listeners. We set them up in Alloy.js.

I have included the log output as well. We can get foreground and background working in android without any issues. However, on clicking the notification in the action bar, our app is opened, but the click callback is not fired.

Instead of the click callback, the foreground callback is actually executed several times.

This was performed on a Nexus 5 running Android 4.4.4. We're compiling our app with 3.2.3.GA and alloy 1.4.

Your help is greatly appreciated!

Thanks.

[arleyandrada]

Hi,

Where in your source code did you put the PushClient registration and event listeners?

It's required to put it in alloy.js or main controller (index.js) and ensure that the module is registered, event listeners are registered and registerPush method is fired at every app startup.

Try it out and call me back.

Regards,

Arley

[somefakeuser]

Hi Arley,

Please take a look at the following gist: [ link removed ]

You should see that in Alloy.js we call our own prototype. Within that prototype (pusher.listen();), we setup the listeners. The listeners work except for the "click" listener. Instead of the click listener firing, the app starts, and a foreground callback is executed.

log1.txt shows that we can successfully trigger the callback in background. log2.txt shows that we can trigger the callback in foreground. log3.txt shows that when app is not running at all, we successfully trigger the callback from the background (line 32); however, when clicking the notification, our app starts, but the click callback is never triggered. Instead, we receive multiple foreground callbacks. (line 556, line 583)

The last file in the gist at the very bottom, pusher.js, is our wrapper around your library. In particular:

Pusher.prototype.listen - where we setup the listener. Pusher.prototype._handlePushNotification - where we handle the callbacks which is just logging right now.

Thanks for your help!

[arleyandrada]

Hi,

Related to multiple foreground callbacks, have you checked if your app is not registering the PushClient listerners multiple times? (pusher.listen();)

When the user clicks on the received notification, from a pendingIntent definition, a custom "invisible" activity defined within my module is fired to handle the push data, wake the app and foward data to the callback listener with MODE_CLICK argument.

Maybe you could share with me a minimal sample project with your code and with this problem, because I'm unable to reproduce your problem.

I'm thinking in to fires a broadcast instead of an activity when the user clicks on the received notification... and maybe this can fix your problem... but I need to reproduce your problem first.

Attached Click Here is a sample project with full working module and callbacks. Please test it in your environment.

Regards,

Arley

[somefakeuser]

Hi Arley,

I have attached some modifications to the test project to make it more closely resemble what we have. I am able to reproduce the problem using a Nexus 5 and the attached project. Foreground and background callbacks work, but upon clicking, only the app is opened - no click callback.

Please let me know if you are able to reproduce this with the attached code.

Thank you for taking the time to do this!

Regards,

[ attached file removed ]

[arleyandrada]

Hi,

Now I can reproduce your problem and I found one solution:

As I explained before, my module expects that the registerPush method is triggered at every app startup, even if the device has already been registered before.

I suggest that you move all the PushClient eventListeners and registerPush to within your Pusher listen method.

There is no problem in calling the registerPush method multiple times.

The module can (through registerPush method), among other things, handle the MODE_CLICK callback, check whether you need to update the device registration, eg, an update of the app version or need to renew an "expired token"...

Please, let me know if is everything ok now.

Regards,

Arley

[somefakeuser]

Hi Arley,

Thanks for your help. We restructured our workflow to execute your registerPush method as per your suggestion.

The only other suggestion I have for the module would be to allow for custom notifications. It would be nice to build different looking notifications based on the information that is passed through the push. For example, if I put some extra data in the push like type => 1, or type =>2, then it would be nice to change the icon in the notification to be different for each type. This applies more to android I guess.

It would be nice if we could create our own notifications simply based on the incoming data as per: http://docs.appcelerator.com/titanium/3.0/#!/guide/Android_Notifications OR by Ti.App.iOS.scheduleLocalNotification

Perhaps an option for customNotification => true, could allow for something like this and be processed in a similar manner to how you have setup the foreground event...

Just a thought.

Anyway. Thanks for your support and hard work on this module.

Cheers,

[arleyandrada]

Hi,

Thanks for the feedback.

I have plans to release a new version of my module in the next weeks with some improvements and your suggestion will be one of the new features.

You will be notified about this new version.

Thanks,

Arley

[somefakeuser]

Will do. Looking forward to seeing the new version. Thanks again.

Cheers!

[somefakeuser]

Hi Arley,

We just dropped in the v1.5 of the module. I'm just curious what the reason was for this new version? Is there a CHANGELOG somewhere?

Does the new version work with iOS 8? I noticed some new permission requirements for iOS8...

[somefakeuser]

Whoops. Sorry. I hit send before I finished.

Here's the link http://docs.appcelerator.com/titanium/release-notes/?version=3.4.0.RC#register

I'm just hoping that the module will still work on iOS8?

Thanks,

[arleyandrada]

Hi,

We have good news!

I just released a new PushClient module version and it will be available at Appcelerator Marketplace in next days.

Version 1.6:

• Titanium SDK 3.4.0 compatibility with backward compatibility;
• Enabled to iOS 8 interactive notifications;
• Updated documentation and sample.

Version 1.5:

• Fix to multiple received notifications click on Android;
• Use iOS badge info from payload to set number at Android;
• Included new largeIcon option to Android.

Have fun!

Regards,

Arley

[somefakeuser]

That's awesome. Thanks!