I sat down and coded a ruby client for the HTTPush API, our hosted gateway to the Apple Push Notification service, using the excellent HTTParty gem. The whole client weights in at 45 lines of code and excercises every call from the API.
You can request an invitation to the API here and download the client from here. You need to be a registered iPhone developer and need an invitation from HTTPush to use this client.
23 May 2009
15 May 2009
What to do with Apple Push Notifications (Part 1)
This article is part of a series in which I cover use cases for the Apple Push Notification Service. Bigcurl runs a hosted gateway: Bigcurl HTTPush that frees you from running you own servers to make use of those notifications. It is rest based and can be called via plain HTTP from almost any language. You can sign up at push.bigcurl.de. Indepth documentations about the different api calls can be downloaded from within your HTTPush account.
In this series I'll cover more in depth about the different use cases and how to archive them in your app. The first one deals with the situation where you do not want to run your own servers and want to reach all your customers with the same message at the same time. You can easily archive this with HTTPush. With some Google App Engine trickery you might not need to run a server at all. I want to show you on a high level, how you would implement this using the HTTPush web service.
An application that wants to reach all users at the same time
Say you are building an app for a local band. Your app shows news from the band and mixes that up with tour dates and behind-the-scene pictures. Whenever there is news from the group itself or they have a new gig, you want to send out a notification to the users, letting them know that something is new and they should launch the app to be up-to-date. The primary source for news are a bunch of rss feeds that get called every time the app launches.
Registering a recipient
Your users launch your app for the first time and they register for the device token (more about how this works after the NDA is lifted). The device token is a unique identifier for the device similar to a phone number, which enables Apple to reach that phone.
With the received token, you call the api method
with the HTTP verb POST, to add that user to the general recipient pool of the application.
Call this method every time, the app is launched because you can not be sure if the token changed or not. You SHOULD NOT however store the token somewhere on the device. Just call the method.
Send notifications
To gather the news, pictures and tour dates for your app, you call several rss feeds from within the app. You'll need to outsource this logic to a server machine in order to know when somethings has changed in the feeds and you want to send out a notification.
Have a look at Google App Engine for running your script. The limits should be sufficient for a small script like this and you can HTTPush from there. Use App Engines cron feature to call your script periodically and send a notification from there to the api.
Call
with the HTTP verb POST, to reach all users in your app.
No notifications anymore please!
If a user chooses to opt-out of notifications, simply call
with the HTTP verb DELETE, to get him out of the recipient pool.
As you can see it is very simple to use the api and with a little trickery you do not need to run a server on your own to make use of push notifications. If you have more complicated needs for your server script, contact Bigcurl. We do all things server side for a living and are happy to work with you on your app.
In this series I'll cover more in depth about the different use cases and how to archive them in your app. The first one deals with the situation where you do not want to run your own servers and want to reach all your customers with the same message at the same time. You can easily archive this with HTTPush. With some Google App Engine trickery you might not need to run a server at all. I want to show you on a high level, how you would implement this using the HTTPush web service.
An application that wants to reach all users at the same time
Say you are building an app for a local band. Your app shows news from the band and mixes that up with tour dates and behind-the-scene pictures. Whenever there is news from the group itself or they have a new gig, you want to send out a notification to the users, letting them know that something is new and they should launch the app to be up-to-date. The primary source for news are a bunch of rss feeds that get called every time the app launches.
Registering a recipient
Your users launch your app for the first time and they register for the device token (more about how this works after the NDA is lifted). The device token is a unique identifier for the device similar to a phone number, which enables Apple to reach that phone.
With the received token, you call the api method
http://push.squidshot.com/:account/v2/recipient/registration.jsonwith the HTTP verb POST, to add that user to the general recipient pool of the application.
Call this method every time, the app is launched because you can not be sure if the token changed or not. You SHOULD NOT however store the token somewhere on the device. Just call the method.
Send notifications
To gather the news, pictures and tour dates for your app, you call several rss feeds from within the app. You'll need to outsource this logic to a server machine in order to know when somethings has changed in the feeds and you want to send out a notification.
Have a look at Google App Engine for running your script. The limits should be sufficient for a small script like this and you can HTTPush from there. Use App Engines cron feature to call your script periodically and send a notification from there to the api.
Call
http://push.squidshot.com/:account/v2/recipient/notification.jsonwith the HTTP verb POST, to reach all users in your app.
No notifications anymore please!
If a user chooses to opt-out of notifications, simply call
http://push.squidshot.com/:account/v2/recipient/registration.jsonwith the HTTP verb DELETE, to get him out of the recipient pool.
As you can see it is very simple to use the api and with a little trickery you do not need to run a server on your own to make use of push notifications. If you have more complicated needs for your server script, contact Bigcurl. We do all things server side for a living and are happy to work with you on your app.
Labels:
Google App Engine,
iphone,
ipod touch,
push notifications
12 May 2009
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.
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.
Labels:
Apple,
hosted api,
httpush,
notification,
push,
service,
web service
Subscribe to:
Posts (Atom)
Posts
