About a year ago, I wrote an article on "why Web 2.0 doesn't cut it for mobile devices." My basic argument was that because wireless web connections are intermittent and unreliable, a completely thin client architecture for applications won't work. (A thin client application is one in which the code for the app stays on a server, and all you have on your PC or mobile device is a little user interface widget. Every time you do something with the web app, your device has to talk to the server. Almost all web 2.0 apps are thin client apps.)
So here I am riding the BART train out of San Francisco, after spending the day at the Web 2 Expo. I'm using a Pantech/Sprint EVDO card in my computer, which gives the rough equivalent of low-speed DSL connectivity all over the city. Even though it cuts my notebook's battery life in half, I still think it's cool as ice cream in July.
Anyway, I'm having a good time working on a couple of blog posts, using the thin client Blogger interface, when the train goes through a tunnel. Guess what, no connection. Then we come out of the tunnel at a station, and my connection comes back for 30 seconds. Quick! Load that page! Then we go back into the tunnel again. And on, and on, and on.
Think of it as Bloggus Interruptus.
I guess I could ding Sprint for failing to extend its network to the subway tunnels, but this sort of problem is ubiquitous around the world for high-speed data networks. They have much less coverage than the voice networks, and that's changing only gradually. Even as we get more coverage, it won't be possible to depend on always having the connection when you need it.
The way mobile web apps need to work is that they download the full app and a copy of your data to your device, so you can work independently. Then in the background, they should sync the data whenever you're connected. That's how RIM's e-mail works, and it's still the state of the art for giving you the illusion of always-on wireless connectivity even though there's no such thing in the real world.