Will the G1 Android Phone be an iPhone Killer?

...we'll take your calls. There has been a great deal of comparisons between the humble G1 by HTC and Apple's mighty iPhone. What caught my attention was the recent talk about how "revolutionary" the iPhone was on the now infamous "The Java Posse" Episode 207 where Joe Nuxoll and Dick Wall seemingly nearly came to blows over whether or not Apple's phone UI was a revolutionary feature, Joe insisting it was and Dick holding his ground that it was an improvement but not revolutionary.

The argument, at least as made by Java Posse proponents, is that the usability of the iPhone allows user's to do things that they may have never done before, or at least never wanted to do with any prior phone, citing examples such as browsing the internet and text-voice-mail (no idea how this works as I don't own an iPhone). The point was that it was not the features but the implementation that mattered. Prior to the iPhone there were many phones with browsers but none that implemented the browsing experience well enough to compel users to use it regularly. To be fair to Joe and the others, they were not making comparisons between the iPhone and the G1 and Joe (despite being an admitted all-things-apple-fanboy) made the point that he wanted to use it prior to passing judgement.

However, since the announcement of the G1, there have been numerous articles and blogs written about why the G1 does not measure up to the iPhone or other competitors. The most agregeous that I saw was one published by Macworld UK called10 fails for the T-Mobile G1 (Google Android phone). In the article, it discusses 10 features that the G1 doesn't have that it should. According to this article, the G1 fails to measure up because it doesn't have things like Multi-touch, desktop syncing and Exchange email. These are nice features of the iPhone that the G1 doesn't have, therefore the G1 is inferior.

I think these folks are missing the point entirely, as Steve Jobs himself said, "Inovation is not about saying yes to everything. It is about saying no to all but the most crucial features." The point is that the G1 will succeed or fail not based on what features it has but based on how well it implements the crucial features. it doesn't implement multi-touch, well maybe it doesn't need it with the keyboard and scrollball. It doesn't have Exchange email. Well for me Gmail is all I need and using Gmail and google Calendar to manage my contacts and schedule sounds like a God-send. I think Gmail may be the best application ever built, not because it lets me get my email and manage contacts online but because the implementation is freakin' fantastic! Other application I love are google maps and google calendar, all of which are supposed to have first-class implemenation in Android. I would be happy NOT to have to use any sort of desktop syncing if it's all automatically synced with my gmail.

I'm suggesting that you wait until you have held a G1 in your hands and used it for a few days before you make any judgement. Oh, and as an aside, if Apple/ATT or HTC/T-Mobile would like to send me one of their fine communication devices so that I, as an impartial observer, can write a review on it, I would be willing to bear this cross.

Do AJAX Web Applications Break the MVC Pattern?

Recently at work we have been having the discussion about using AJAX (Asynchronous Javascript And XML) to help us out with certain usability issues on some of our applications. I had an interesting discussion with a colleague about whether or not using AJAX breaks the MVC (Model View Controller) design pattern that we are all so comfortable with. The application we were discussing was using Struts and so followed the MVC pattern without implementing any of the functionality using AJAX.

If I understood his argument is was basically that if anything but the controller handles an event then the MVC pattern has been broken. Clearly we do this in an AJAX application where some user events would be handled by Javascript libraries and others would ultimately make requests to the application and therefore be handled by the controller.

It seems to me that the same argument could be made of any web application that uses DHTML that reacts to user input. So even graphical buttons that change state based on whether a user is hovering over it or clicking it is an event that causes a change NOT handled by the controller. Even something this trivial would break the MVC pattern.

So maybe the more important question is to what degree or in what fashion is it okay to break or modify the MVC pattern. From my point of view it makes sense for events that invoke ONLY view logic to be handled by the view. So to have sort of a "Smart View" instead of the traditional dumb document or form that is usually returned in an MVC web application. This allows for much more responsive views that will immediately respond to user input. This level of responsiveness is not generally possible in a web application where events are processed over http.

So where do you draw the line? A "Smart View" should only contain view logic. There are obvious security risks to allowing business logic to be handled in the view so obviously that road is closed. I'm curious if this has been a common theme to others implementing AJAX on their web apps.