iPhone could change mobile browsing

Nokia has had a phone that supports Safari for a while. A Nokia chap was at the first Ajax Experience in San Francisco last May showing off the phone. It had the same features that Safari on the iPhone has (zooming around web pages).

Opera Mobile is also very popular on various makes of phones. With the huge market that mobile represents, and the fact that we are still growing up wrt high speed access on these devices, it will be interesting to see the mobile browser war progress (and how it may differ: IE vs. FF on desktops, Safari vs. Opera on mobile).

We can’t simply develop Ajax apps and expect them to work great on the mobile form factor, and we have
talked in the past about how Ajax could be a pain here (updating an area of the application that the mobile user can’t even see).

Joel Webber pinged the GWT google group about how GWT could help out in building applications that work across boundaries:

It’s great that these browsers are modern and fully functional, but the devices aren’t just like desktop PC’s. They have different (smaller) form factors, input methods, and (probably) use patterns. And the two browsers involved are the two that usually get supported *last* (if every) by most web developers, but that you get pretty much for free with GWT.

Perhaps what we need here is the concept of ‘device profiles’ in hosted mode, that will help you try out your applications in different scenarios, to see how different users will see and interact with your app. Let’s say the Wii has no good keyboard support (just by way of example, I have no idea whether it does or not) — if you want Wii users to use your app, it would be a really good thing to put yourself in their shoes. This would also be helpful for automatically trying out different screen
sizes (a lot of people are still on 800×600 or 1024×768 screens).

One of the great things about GWT (IMHO) is that it makes it easy to switch out implementations of classes using deferred binding. I know this feature is not as fully documented as it should be (yet), but suffice it to say for the moment that it would make it really easy to precompile different versions of your app for different browsers. Imagine that you want to support the iPhone, but its 480×320 screen size really needs a different UI than the one you display to normal web users.

Well, why not define two EntryPoints that use different subsets of your application’s UI, and let them be selected depending on the device running it? The beauty of this is that, if you’ve divided your app nicely into Composites, it’s really
only small amount of different code, and each device pays only for the code needed to run its UI. Formalizing the concept of device profiles and automatically integrating it with deferred binding could make this process relatively pain-free.

Fun stuff to think about.