The four most common use cases for push notification

Since the Bigcurl HTTPush web service was opened to a few individuals, first feedback is starting to trickle in. What follows is the essence of the feedback we received so far.
We identified four patterns of how developer want to use push notifications in there own app. Most applications will do a combination of them.

The Bigcurl HTTPush web service handles two of those cases out of the box without the need for extra machines. Later this month we invite you to test v2 of the api, which sports some new calls to support the use cases discribed. If you are interested to learn more or receive an invitation sign up at http://push.bigcurl.de.

The first two use cases are mostly triggered by an external source, like a script. The later two are mostly triggered by the users themselves.

1. A single application wide topic

What do I mean by a topic.
Lets imagine an application for a specific conference. People would download the app, subscribe to receive notifications and when ever there are news regarding the conference or a particular talk, a new notification is send to the api and received by all users of the app. The user would start the application and see what has been updated.
It is very similar to a feed (rss, atom). A Topic means basically a broadcast: One source, many recipients that get the same text.

The trigger can be anything that has access to the same data, the application wants to display and simply fires a notification to the api when the data changes. This can be either a script or coupled a content management system.

Since all user get the same notification anyway, you do not need to know much about your users. You don't even need to be able to identify a single user. As we see later this is not always the case.
So the developer should not bother the user to pick a username and sign up. Just create a random string and store it on the device. We only need this username in case the user wants to de-register from receiving notifications. The only thing we do need to store is the token for the device that is interested in such a notification.

Except from the trigger part, you can fully use the api to support this use case in your app. We store the token for you and provide you with an access point to reach all users with a single request. Depending on how you want to trigger the notification you might just need to host a script.

2. Many application wide topics
If we spin the conference application idea a little further, it would be nice if a person only receives a notification if an update happens on a talk he/she subscribed to.

Now we need to store a little bit more information to make many different topics happen. We need to store the token for the device and we need to store which topic the device wants updates for.

As you can imagine that sending the notification now becomes a little more complicated because our trigger needs to know which group wants an update for a specific event.

The api enables you to send a message to a predefined group and the api figures out who should receive the notification. We still do not need to know a lot about the user. Just the device token and which topic a user is interested.

This use-case is also fully supported by the api without running own infrastructure besides a script that triggers the message for a certain group. The whole token registration, group membership thing is handled by the api. You specify a group at the management website and you can subscribe or unsubscribe your users from within your app. You should think of the topics here like preferences in an application.

There are two ways for a developer to support this use case. Either take advantage of the api for storing the device tokens and groups or do the whole registration, topic membership logic them self and fire of individual notifications if something happens.


3. Individual Messages
This use case is probably the first one that comes to mind when thinking about notifications. An individual sending a notification to another individual, like a text message. To stay with our conference app, we now want to enable that users can invite each other to topics. The notification should display the request to invite to a topic and the app should handle an acception or decline.

To allow a user of your application to send notifications, you need to identify who sent the message and detect if he/she is allowed to do so. This means you need some kind of sign up, you need to authenticate a user (a server that stores username and passwords) and you need a discovery mechanism to find users (search).

You as a developer are responsible for handling sign up, authentication and search.
We only support this case partially by either letting you send a message to a username, which means we do the token registration for you or by letting you send a message to a token directly. In this case you store all the data and do the device registration yourself but let us handle the direct connection to apple.

4. Individual one-off topics
A client sends a message to a group that is not predefined and only exists for one message. This is similar to a text message (sms) where you can send the same message to a number of people. You rarely send another message to the same group of people again.

Since this is a not predefined group, your application should fake such a group by sending individual notification for every identifier on the list.
Like with sending individual notifications you need to handle sign up, authentication and searching for other users. If there is demand we might create such an api in the future.


If you need help here with building an online community contact Bigcurl. We do custom development for all things server side for a living and are happy to work with you on your application.