Allow for multiple notifications in Android

[thenewmr]

This allows for multiple notifications to be displayed on Android. Simply add data with key "notId" and an integer value when sending via GCM. Differentiate between different notifications by setting different notIds. Defaults to 0 if no key supplied.

[scotthooker]

This seems a sensible approach. However, shouldn't the default behaviour be to stack the notifications. It doesn't feel right that I would have to set the ID as I don't know which ones the user has read etc... already so if I'm sending for example 100 notifications I'd have to maintain a log of the ID throughout the day?

Or am I misunderstanding this?

[thenewmr]

You're not misunderstanding. I wanted to maintain the current behaviour if people update their code from github and don't change how they're sending notifications. You make a good point but I think it depends on the use case. Other people may want to always replace the notification that's in the drawer.

You could maintain an int in your server code that increments on each send. Or, if you're okay with changing the client code, you could do this in the Android code.

As I said, I think it largely depends on the use case. Anyway, the system I did works a charm for me and my use case so it's there if anyone wants to merge it in :)

[bobeasterday]

Instead of an int. Consider using a string containing an UUID. Easier to manage on the server end. Those who want to stack notifications will always supply a new UUID. Those who don't care can either supply the same UUID always, or an empty string. A UUID will also allow them to manage the stacking behavior on a per client basis, so you could for example, let the client decide.

[thenewmr]

The second parameter of the .notify method requires an int which is why I did the way I did. Though I see what you mean by using a UUID and I like the idea, I'm not sure if a UUID is the right thing to use here.

I feel that those who want to stack in an organised manner can do so by keeping track of ints. Those who want to stack regardless can increment their int (using modulo arithmetic to make sure it goes back to 0 eventually) and those who don't want to stack can just not send the id or always send the same id.

[abe-pleasant]

Android already has something called collapse keys. I might be wrong, but I think we should be able to use that and not worry about another "notification id".

[thenewmr]

I think collapse key refers to whether or not one push message should replace another in the cloud. Not on the device. I got mixed up with this too until I read about collapse key at the following link.

http://developer.android.com/google/gcm/server.html

The stuff about how to differentiate between notifications on the device can be found here:
http://developer.android.com/guide/topics/ui/notifiers/notifications.html

[8enmann]

@abe-pleasant Yes, it has collapse keys, but that doesn't let 1 application have multiple different outstanding notifications. Consider a Facebook like app, where it could have 1 notification saying "Your photos were uploaded" and another at the same time that says "You got a message from Jim". This case would be supported by this request. I vote merge.

[abe-pleasant]

Thanks @thenewmr for the implementation. I would have preferred to simply have stacking by default without any changes, but it makes sense to keep default behaviour unchanged, since that's how (unfortunately) PushPlugin has been handing multiple notifications.

@bobeast Is it possible please to merge this code?

[abe-pleasant]

Sorry to be annoying, but is it possible to please expedite this particular addition? Are there any major problems with the provided implementation? I am a phonegap build user and I can't use this code until it is available for PGB. I'm definitely not the only one who wants the feature.

Thanks 👍

[thenewmr]

You're welcome @abe-pleasant and anyone else who might benefit from it. I'm happy to contribute. Gives me a warm fuzzy feeling inside :)

[dbaq]

👍 for this feature

[8enmann]

Maybe we should create an "official" fork of this plugin so we can all continue to iterate and add features. The current owners of the repo appear to be completely unresponsive.

[abe-pleasant]

@8enmann, that could be problematic. Who will be responsible for maintaining that repo?

Also we would still need to submit to phonegap build and get approved (non-build users can already change the code as needed). It looks like each successive update to the plugin would have to go through the approval process. And it looks like that approval process could take a while, it might be influenced by how many users are using a certain plugin.

This plugin's updates seemed to be approved immediately (probably because the repo owner works for phonegap build).

Further, phonegap build users generally won't have a local build environment setup, so won't be able to contribute much code. non-PGB users won't have as much of an incentive to contribute (?).

Instead, I think a better solution would be to give the appropriate access to one or more contributors from the community so they can push commits and make tags etc. That way the only thing we would still depend on the single owner of the plugin for would be submitting updated versions to phonegap build.

[8enmann]

@abe-pleasant that sounds like a good idea, but we will need at least promotion of a community member to a project moderator, and we have had 0 interaction for over a month.

[tricki]

bump @EddyVerbruggen

[manuelfc1]

After investigating a little bit, the solution would be to modify the line:
PendingIntent contentIntent = PendingIntent.getActivity(this, 0, notificationIntent, PendingIntent.FLAG_UPDATE_CURRENT);

to this:
PendingIntent contentIntent = PendingIntent.getActivity(this, notId, notificationIntent, PendingIntent.FLAG_UPDATE_CURRENT);

[stevierar]

To add to @manuelfc1 's comment, merely changing the 0 to notId will fail as notId has not been defined at this point. Simply move the whole block that defines notId:

int notId = 0;

        try {
            notId = Integer.parseInt(extras.getString("notId"));
        }
        catch(NumberFormatException e) {
            Log.e(TAG, "Number format exception - Error parsing Notification ID: " + e.getMessage());
        }
        catch(Exception e) {
            Log.e(TAG, "Number format exception - Error parsing Notification ID" + e.getMessage());
        }

To the top of createNotification(). This got each individual notification working for me. Thank you to @thenewmr and @manuelfc1 for their work on this.

[thenewmr]

Glad this got merged. My first pull request to be merged on GitHub :)

@manuelfc1
I wasn't using URLs so didn't spot this during development. Good spot though. You should submit a pull request.

You are most welcome @stevierar And thanks to you too for extra info.