Why do Android developers do not make money?

Okay now. Don't expect me to bring some new reasoning here. This is probably known to a lot of us (if not all). Even I have heard about it before many times. But only a few days back, I sort of got it (Eureka! Eureka!).


A friend of mine had bought an iPad 2 just few weeks back. He intended to buy an Android tablet (Asus Transformer) but somehow things worked out differently (that is another story and does not have a place here) and an iPad 2 landed on his lap. He has been using it for sometime now. A point to keep in mind is that he owns a Android Motorola Defy for quite some time and uses it a lot and likes it a lot (already rooted and flashed).


We were talking about apps on iPad (since I have been using one for sometime, I am considered a locally available subject matter expert - I suppose in the country of blind, the one eyed man is the king) for reading PDFs. Good Reader came up as a possible choice and we talked about the fact that its costs a few dollars and is not free. Then it happened...


My friend said: "I need a good app for reading PDFs and since I have already put in the credit card information into the iPad 2, I might as well buy a good app".


I heard that but it did not register first. And then it hit me! My friend has owned an Android phone for a very long time and has never bought an app in the Google Play store. He has never entered his credit card information in his Android phone till date. And he probably will never do it.


When an iPad 2 is registered with an Apple id for using the app store, one is mandated to enter credit card information. Google Android phones on the other hand allow the user to skip that part. That means that as a user, my friend never entered his credit card data in the Android phone but he entered it first thing in the iPad 2. I am sure he must have felt forced and wronged when he had to put the CC information in the iPad 2 and would have liked not to do it. But over a period of time, this just became a matter of fact for him. 


Eventually what matters is that Apple has his credit card information within just a couple of days of him having a Apple product and that has opened the door for his spending in the App Store within weeks. Where as Google still does not have his credit card information and he has not spent a dime in the Google Play store for close to a year.


Like I said, what I am saying is nothing new. I have heard it many times. But when you experience things first hand, it has a way of making things very clear in one's head. That is what happened with me and I had tell it everybody.


What should Google do? Should it force the consumer to enter her/his credit card information upfront? Will that push the consumers to spend on the Play store? Will that make Android a better platform for developers to develop apps? What do you think?.


  

What is SPDY?

Lately there is a lot of talk about the SPDY protocol (pronounced as Speedy). The recent launch of Firefox 13 with SPDY available by default is very welcomed. Though created by Google, a lot of large entities (amazon, twitter, mozilla etc.) are interested in this protocol. Google has submitted this as a draft to IETF as the next gen replacement Http. Even microsoft is interested and they have also submitted a parallel proposal, which is very much inspired by SPDY.

Now that I have built up the interest on SPDY as the next gen http (hopefully), you might ask: "What is wrong with HTTP? Why should I care?"

Problem with HTTP

HTTP has served us well for a long time and in many ways it was never conceived to be used. Today the content which flows through the internet is very rich with images, dynamic scripts, videos. Some of HTTP's early decisions are not good enough any more in terms of performance. For example

• One request per connection at a time - Everything a server has to send to the client comes in a serial manner - send one and then the other and then the next. Too slow. Browsers circumvent this by creating parallel connections to the server (creating new connections is not cheap at all).
• Request always initiated by client only - HTTP works by the principle that client initiates the request and the server responds to it. Even if the server knows that the client would need these resources, it can't really do much about it (neither pushing content nor providing hints).
• HTTP Headers keep sending redundant information and that too in uncompressed form.

All these mean that HTTP makes the web experience much slow (at least at the rate at which we want it today). That said, HTTP is very prevalent and it handles various kinds of content very nicely.

In comes the SPDY

SPDY as the name suggest is a protocol aimed at changing the performance aspect of HTTP. It preserves the application usage aspect of HTTP and tries to solve the performance issues. It sits on top TCP and provides a session layer. It tries to:

• work with many concurrent HTTP requests in a single TCP session/connection in the form of streams. A new frame format helps doing this
• reduce bandwidth usage by using compressed headers and removing unnecessary headers
• create server initiated streams (push or hint)

SPDY also tries to ensure that content does not have to change to achieve this. This is important because with the amount of web content available in the world, this would just be unreasonable. The idea is to change the user agent (browser) and the content provider (server) to provide support for SPDY.

Another thing to note is that SPDY stays at the application protocol (HTTP is one) layer and does not move into the transport (TCP) layer. This is not because there is no optimization possible at that level. It is more to do with the fact that such changes would need the entire internet infrastructure to change and that will make the protocol a non-starter in terms of its acceptance. 

SPDY also prefers to work with SSL. This does cost on performance, but the idea is to promote a more secure way of interaction between client and server. 

SPDY Implementation 

Google has worked on implementing this protocol and testing it extensively. Their browser (guess which one) supports it and their server infrastructure supports it as well. That itself is a good testing bed for SPDY. A lot of details about their testing is provided in the SPDY white-paper if you interested to check out.

Of course other companies are getting involved as well as I mentioned before.

Development Support

The SPDY project page refers to a lot of frameworks and server software that support SPDY. Some interesting ones are

• Jetty: 
• http://wiki.eclipse.org/Jetty/Feature/SPDY
• http://www.infoq.com/news/2012/03/jetty-spdy
• http://www.smartjava.org/content/how-use-spdy-jetty  
• Netty (contributed by twitter)
• http://netty.io/blog/2012/02/04/
• http://www.smartjava.org/content/how-use-spdy-jetty 
• apache
• http://code.google.com/p/mod-spdy/
• node js
• https://github.com/indutny/node-spdy

There are lot more servers and libraries supporting it - please refer the project page mentioned above.

Conclusion

SPDY is already there in the wild now. It makes the web interaction faster for consumers/producers like us. It has picked the interest of other big entities who are trying to improve it further. Google itself is very much involved and is doing a lot of testing. It also wants to involve the open community on it. May be its time we get to know more about it and contribute to it in whatever way we can.