Push vs. Pull and the Twitter Client
Posted on | June 25, 2009
Not long ago I exchanged a couple of twits with @makonja about the possibility of having push notifications in an iPhone twitter client. Since I saw that there is a bit of confusion around push and pull/poll techniques of providing server data to the client I decided explain this first. I think it is possible to create a Twitter client that will leverage Apple’s push tecnology for the iPhone, but in a different architecture than is used for current clients - a more complicated one.
The Basics
Push technology, or server push, describes a style of Internet-based communication where the request for a given transaction is initiated by the publisher or central server. It is contrasted with pull technology, where the request for the transmission of information is initiated by the receiver or client.
source: Wikipedia
To make it even clearer - in a server-client setup the client can get data in two ways. The first way is by issuing a request each time a set of data is required. The second way is by sitting back with an open door in order to recieve the data when the server feels like sending it.
The Twitter API
Twitter’s API is a REST based API which is meant to respond to specific API calls. This means that your application (in this case a client) needs to make requests (poll each X minutes) to the Twitter uber-servers and wait for the response which contains some data. Twitter does not push any data (never), it just responds to your requests. So in order to see changes in your twitter stream you need to wait for the next request. I hope this is clear 
The Usual Twitter Client
Most twitter clients (Tweetie, Twhirl, TweetDeck, Twitulater…) work directly with Twitter and its API. Their only way to get fresh data is to make a new request and wait for the response. Since the guys at Twitter understand that too many requests may lead to more Fail Whales they usually limit the number of API calls per account/hour. I think the limit is currently set to 100 requests per hour for each account, meaning that you can have fresh twitts fetched to your client every 0.6 minute (36 seconds). Not quite real time, but close enough.
The second important point (which should actually be the first) is user authentication. In this “usual client” scenario users’ credentials are posted from the client directly to Twitter - there are no proxies or middle-mans involved, so there are fewer chances of reusing/stealing your credentials.
The Usual Twitter Client Meets the iPhone
Twitter clients on the iPhone can not run in the background because of the sandbox approach Apple decided to use. This means that the clients can only make requests to the server when they are active in the foreground. The logic described above does not apply and the client can not make a request every 36 seconds, but it needs to wait for the user to turn it on.
iPhone (Apple’s) Push Technique
Since Apple does not allow background applications on the iPhone (mainly because of battery life issues) they promised to enable push notification via an Apple controlled push server. I did not know the details of Apple’s magic server but there are two main approaches that can be taken. One is to have an active connection between the client and the server, the other is a background application listening to specific events that can be sent to this application imagine a small server that is waiting to be contacted by a client - so the roles are inverted. Since Wikipedia has an answer for (almost) every possible question there is no need for my guessing
The Apple Push Notification Service is a mobile service created by Apple Inc. that was released with iPhone OS 3.0 on the 17 June 2009. It uses push technology through a constantly-open IP connection to forward notifications from the servers of third party applications to the iPhone or iPod Touch; such notifications may include badges, sounds or custom text alerts. (source)
Now what are the implications of such an architecture. If Apple would sell 50 million devices and all those devices would have “push notification enabled” Apple should handle 50 million constant connections. Not a trivial problem and that might be the reason why they are delaying the push notifications so much. Secondly this connection requires some exchange of data between the mobile device and the notification servers (the so called keep alive messages) which will be billed to the user if she does not have a flat rate data plan.
In my humble oppinion Apple could have opted for a different approach, but who am I to question them and why should you care, the important thing is that now we both understand the architecture behind
The (Magic) Push Enabled Twitter Client
So far I have described all the components in the architecture and how each of this components works. A push enabled Twitter client should have a server that would fetch your twits each 36 seconds and inform Apple’s push notification service about the potential update. Apple’s notification service would forward this notification (via the constantly-open IP connection) to the iPhone which would display a message containing the new twits or just update the counter of unread twits on the badge or/and play a specific sound alert.
Compared to a “usual” Twitter client you would need an additional server (or many of them if you plan to have more than 5 users). In addition to that all your users will have to give you their credentials so your server would have access to their Twitter profile and their new twits.
A Quick Final Note
I know you must be tired if you read the whole post but there are still some final notes I would like to make. I think a push enabled Twitter client is easily feasible as a proof of concept but I think the costs of maintainance for an implementation of this kind of service would be to high compared to the benefits. I might have got some things very wrong, so please correct me if you see a mistake or a wrong understanding, I will be happy to correct the post.
1kdaysontwitter.com - #FridayProject
Posted on | June 18, 2009
Last Friday we had our first #FridayProject day and I wanted to share with you the process of creating a small web application.
Shower idea
While having my morning shower I was thinking about Twitter and its API (yeah I know…) and how to make a small but funny application that would provide some fun and challenges for my teammates but would be useful and funny for its users. I was thinking about when twitter launched - my memory suggested that this was near 3 years ago, so right about 1k days. Secondly I remembered using When did you join Twitter? a while ago and found it quite funny (for the record: I joined Twitter on 10 August 2007).
Coffee and IM
The team usually gathers at Marand from 8AM till 9AM, so I used that time to prepare a preliminary wireframe design on a sheet of paper I can’t seem to find anymore (will post a pic if I do). Meanwhile I was looking at the Twitter API in order to find out what kind of data can be retrieved for each user and @ghaefb knew the answer in a bit (xml for @tomazstolfa).
The next step was to create a basic design and decide which data we are going to use for our mini app.
Concept, design and implementation
Overall design (Logo, Main Container, Footer)
The main goal was to mimic Twitter’s interface, but with some small changes in order to optimize the user experience. Of course the first thing to create was the logo - extending the Twitter text is not a hard task. Use the Pico font, add a stroke of a couple of pixels and you have a perfect clone of the Twitter logo typeface.
After having an idea of how to create the logo we switched to the main container and footer, and tried to replicate the Twitter look & feel - again, no science here.
Landing Page
We wanted to have a clear landing page, that would be very very intuitive. I know. It is just one text box and some text, but you can mess it up nevertheless. That is why we opted for large fonts and a two color scheme - one for the text and the other, brighter for the text box.
In addition to that a good copy was needed. We went through some iterations and the current question sounded the most “intellectual”
Results page
A quick glance at the available data suggested that we could replicate the look & feel each user has on twitter. However this is a bit harder than it might look. If you check the XML carefully you will notice that you can not determine if a user decided to hide his background image. Twitter should fix this asap. This means that you need to use a nasty trick to check if the background image should be visible or not. We head to the user’s twitter page and parse the html to find out if we should show it or not.
Secondly we decided to show the avatar and username similarly to the way it is done on the original user page. Font colors are also personalized according to the data we get from the API.
The main part of the result page are the big YES and NO messages that are accentuated in order to have a comic effect. We tried a couple of different fonts and color combinations for the YES/NO results, but at the end we opted for Helvetica as it appears nice even at that size.
Well since the service is all about finding out if the user reached the 1k days on Twitter mark, we decided to provide some additional information - the number of days to go and the exact date when the milestone will be hit.
At the bottom we added a small button that allows you to tweet your result and let all your followers know if you passed 1k days on twitter or not. This is done easily - you just point the link behind the button to “http://twitter.com/home?status=write+what+you+want“. If the user is already logged into Twitter her status box will be filled automagically.
404
The Fail Whale is one of the Twitter synonyms and we decided to make a spoof about it by creating a fail octopus. The first iteration sucked, so @doen provided the second (beautiful) one.
The Domain
The domain name was not a difficult choice, but I know we might have made a mistake by choosing such a long domain name. At least it is straight to the point and it differentiates quite substantially from other servicess like this. We bought the domain in at Domenca but we had to wait till Monday to get our payment processed.
Quick marketing
Of course we tried to let the world know about our little app as soon as possible. We pushed the word via Twitter, StumbleUpon and Digg, however we did not expect a huge amount of traffic. In any case, we recieved some good traffic and we were surprised by the amount of traffic StumbleUpon sent our way.
End notes
All in all I must say we had some great fun creating this small application and we learned some new tricks, but most importantly went through the whole process from the idea, implementation and launch really quickly. The great job was mostly done by @ghaefb, but almost all the team members contributed in one way or another. I must say I am already looking forward to our next #FridayProject.
#FridayProject
Posted on | June 12, 2009
- Image by millzero.com via Flickr
Fridays are regarded as cool days because they happen before the weekend. Some companies allow their employees to dress casual on Fridays.
We at Marand love small, innovative and fun projects that can be completed in a really short amount of time. These project serve as a great practice and can help build the skills required to deliver the big, fat ones - which are usually the ones that pay for our living.
That is why we decided to launch an internal initiative called the #FridayProject. Each second Friday, all the members of MarandLab will be allowed to suggest an idea for a one day project. They will be able to pick up other MarandLab members they need in order to complete the project on that Friday. If the project is not completed the team must keep working on the project, but not at the expense of the “big, fat” projects.
All the #FridayProject-s will be launched publicly since this is one of the main components of the training. The team will have to promote the project as good as it can and will get all the required support from other team members.
By doing this we want to get some inspirational pushes and learn new skills. I am sure it will be a fun ride
connect
Twitter Funk
- Smoothie and headache. Priceless. 7 hrs ago
- Partying in Ljubljana after a long time. #zeleniZajec is a perfect place to have a great time. Supreme absinthe and great music. 15 hrs ago
- .@jssr I am having a great time at Zeleni Zajec but I am missing a new round of Absinthe #Supreme for all the nice folks that are still here 17 hrs ago
- Pri #ZeleniZajec mi dajejo nekaj hudobnega, a dobrega za pit. #supreme (via @opica) 19 hrs ago
- Walking around Ljubljana with @anjarenko. Might go to #ZeleniZajec for a drink or two :) 19 hrs ago
- More updates...
Posting tweet...