Mikko Pervilä has released a thesis for his MSci at the University of Helsinki titled Performance of Ajax Applications on Mobile Devices:

This thesis evaluates the presentational capability and measures the performance of five mobile browsers on the Apple iPhone and Nokia models N95 and N800. Performance is benchmarked through user-experienced response times as measured with a stopwatch. 12 Ajax toolkit examples and 8 production-quality applications are targeted, all except one in their real environments. In total, over 1750 observations are analyzed and included in the appendix. Communication delays are not considered; the network connection type is WLAN.

Results indicate that the initial loading time of an Ajax application can often exceed 20 seconds. Content reordering may be used to partially overcome this limitation. Proper testing is the key for success: the selected browsers are capable of presenting Ajax applications if their differing implementations are overcome, perhaps using a suitable toolkit.

There is a large amount of detailed information here across several vectors.

Mobile device / platform differences

Mikko has gone into detailed testing on the Nokia 800, N95, and the iPhone. Within the N800 he tests Opera, Mozilla, and WebCore. On the N95 he tests Opera Mobile and the mini map interface.

Ajax libraries and their support

Here Mikko compared a large number of libraries:

• Prototype
• Script.aculo.us
• jQuery
• Yahoo! UI
• Dojo
• Ext JS
• Gears
• DWR
• MooTools
• moo.fx
• ASP.NET Ajax
• Frost Ajax library

Comparing large websites on mobile phones

Here Mikko runs up against properties such as:

• Gmail
• Google Maps
• Yahoo! Mail
• Flickr
• myAOL

You can look through the study to see the details, but what about conclusions?

One can not yet assume that applications sup-
ported by the desktop browsers would be consequently supported by the mobile
browsers. Browser fragmentation seems to flow over to the mobile devices
with the shared code bases of the mobile and desktop user agents.

If we take a look at the grouping of grades for the various tests, you see that the browsers in question are across the map. All of them have issues, across the board.

Mikko does have this to say about the browsers:

By far, the fastest browser is Opera Mobile on the N95. This seems to be well in line with the overall worst capability in the capability evaluations. This combination seems to be indicative of ignored program directives, meaning that the browser gains speed by not executing some parts of the application code. Safari’s high number (14) of slow results is caused by the browser’s distinctive performance variation, specifically of pairwise high and low values. This phenomena has not yet been satisfactorily explained.

The two things that strike me are:

• Mobile browsers are very different, and I hope they get closer (feels like a few years back with desktop browsers)
• There is room for a mobile specific toolkit (or a mobile piece of a current toolkit) to help out like they did in desktop land. Frost is an early library here.

As you go through the thesis you will see a great set of graphs that show you the performance characteristics of micro elements of the Ajax experience on the phone. Thanks for the work Mikko!

Hmm, what if you could run a server on your mobile? Jetty, the lightweight Java HTTP server has been ported to Android as i-jetty.

You can use Jetty to run server logic and Servlets right on the phone itself.

For example, you could take a Web based application and deploy it on the phone, and have the phone’s browser talk locally. Jetty also supports Comet style Web development, so your little Web browser based application could get some PUSH.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="org.mortbay.ijetty">
    <application android:icon="@drawable/icon">
        <activity class=".IJetty" android:label="@string/app_name">
            <intent-filter>
                <action android:value="android.intent.action.MAIN" />
                <category android:value="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
</manifest>

When Ars Technica first took a look at the Android SDK they had a few complaints.

Luckily, they came back, and took a look at the most recent release and were able to see improvements:

One very noticeable change in the Android user interface is the addition of transition animations. The animations show up in many places throughout the system, generally when windows, dialogs, and menus appear. They are very subtle and add some additional elegance without becoming a distraction.

I tested several of the applications that come with the SDK, including the mapping program, the contact book, and the web browser. I also tested the experimental Google Talk chat integration feature. I was able to connect to Google Talk and receive messages, which are displayed as items on the notification panel. The performance and usability of the bundled applications is pretty decent.

We have heard that Flash is coming to the iPhone even since before the iPhone launched. Gear Live say that it is definitely coming.

Why isn’t it on the iPhone now? They make out that it is due to business decisions, but my guess is that this isn’t the case. The iPhone came out swinging that “the browsing experience is full.” The browser is a desktop-esque browser. No WAP here please.

This means that you would expect to see true Flash instead of Flash Lite, which you often see on a mobile phone. However, Flash does eat up a lot of memory, CPU, and thus battery, so I think that the Apple folks have been playing with Flash and making it fast and economical enough to run on the device.

At certain times it has been frustrating not to have Flash. You feel crippled. On the other hand, it has also often been nice. No silly Flash ads etc.

If it finally does make it on the phone, it will open up the world of iPhone development to Flash developers which will be a big thing.

Wayne Shea and Tenni Theurer have continued their performance series by delving into the iPhone and its poor little cache.

I always wonder why the cache is so small. It is typical Apple to not allow an expert mode where you can tweak it. I would rather have a few less songs and have a large cache. But, Steve knows best

The end result of the article is that you should follow this ideal rule:

Reduce the size of each component to 25 Kbytes or less for optimal caching behavior

Given that the wireless network speed on iPhone is limited and the browser cache is cleared across power cycle, it is even more important to make fewer HTTP requests to achieve good performance than in the desktop world. To reduce the number of HTTP requests, Safari on iPhone supports image map, CSS sprites, inline images and inline CSS images. Take advantage of the browser cache whenever possible. If an external component can be shared across multiple pages in the site, remember that each individual component has to be smaller than 25 KB to be cacheable. Also, the maximum cache limit of all components is 475 - 500 KB. Minify all the JavaScript, CSS and HTML. For components that aren’t shared across multiple pages, consider making them inline.

This of course is quite painful if you like to package JavaScript in One Large File for other performance reasons, or if you use a library that is larger than 25KB!

The iPhone can tell us a bunch of things about a site. If I go to TechCrunch for example, it drives me batty as it does a bunch of JavaScript to load in the CrunchBase widgets, and the iPhone keeps thinking it is loading. The blue bar keeps going, and the browser isn’t as responsive. I hate those Crunchbase widgets

Opera has given a teaser announcement on Opera Mobile 9.5 where they have told us what to expect, but we don’t get to play with it yet:

• Uses the new Presto engine, so it should be faster
• Zoom around a la iPhone
• Flash support (Flash Lite only)

You can see a video tour.

What is most interesting is that it supports Opera Widgets, so you can develop one form factor and have it work as a widget for the desktop and the mobile phone.

With the new WebClip feature, you can put Web pages on the iPhone / iPod Touch home screens. Instead of using favicons and morphing them in some way, you need to create a 57×57 PNG icon which gets automatically rounded and glassy, as mentioned on the http://apple.com/apple-touch-icon.png, and a set of “special” people seem to have built in icons.

Perst has certified an object oriented embedded database for Android. SQLite is already on the device, so why would you want to use something else?

Why use Perst in software for Android? Because Perst helps developers create small-footprint embedded Java applications that are fast, reliable, and cost-effective to develop and maintain. Perst can do this because it is:

Object-oriented. Perst stores data directly in Java objects, eliminating the translation required for storage in relational and object-relational databases. This boosts run-time performance.

Compact. Perst’s core consists of only five thousand lines of code. The small footprint imposes minimal demands on system resources.

Fast. In McObject’s TestIndex benchmark, Perst displays one of its strongest features: its significant performance advantage over Android database alternatives.

Reliable. Perst supports transactions with the ACID (Atomic, Consistent, Isolated and Durable) properties, and requires no end-user administration.

Rich in development tools. The Perst API is flexible and easy-to-use. The breadth of Perst’s specialized collection classes is unparalleled. These include a classic B-Tree implementation; R-tree indexes for spatial data representation; database containers optimized for memory-only access, and much more.

McObject also provides TestIndex, an Android-ready database benchmark application that measures performance using both Perst on Android, as well as Android’s bundled SQLite database system. You can download TestIndex with complete source code, no registration required.

SiFR, a provider of GPS-powered location platforms, announced that

It will rapidly implement key end-to-end location-awareness features needed to enable mobile devices powered by the Android(TM) platform to provide an optimal location awareness experience for consumers.

SiRF is actively working on the Android platform to include some of the more innovative features of Secure User Plane Location (SUPL), a standards-based protocol that allows a mobile handset client to communicate with a SUPL Location Platform (SLP), including transport layer security (TLS) for location privacy and multiple session capabilities to provide the most compelling user experience. SiRF is also implementing support for Android-based assisted GPS (A-GPS) handsets, including mobile station based (MSB) and mobile station assisted (MSA) positioning methods to facilitate the Android platform passing Open Mobile Alliance (OMA) and 3GPP conformance testing for third-party certification.

Location is huge, and it appears that 2008 is going to be a break out year for location-aware services and applications.

We also heard about a prototype for Android using the HTC Qtek 9090.

The New York Times has a piece (login required): Google Sees Surge in iPhone Traffic.

It starts off talking about the title itself:

On Christmas, traffic to Google from iPhones surged, surpassing incoming traffic from any other type of mobile device, according to internal Google data made available to The New York Times. A few days later, iPhone traffic to Google fell below that of devices powered by the Nokia-backed Symbian operating system but remained higher than traffic from any other type of cellphone.

The data is striking because the iPhone, an Apple product, accounts for just 2 percent of smartphones worldwide, according to IDC, a market research firm. Phones powered by Symbian make up 63 percent of the worldwide smartphone market, while those powered by Microsoft’s Windows Mobile have 11 percent and those running the BlackBerry system have 10 percent.

But, then you get to the important piece from a developer perspective:

“Consumers are going to demand Internet browsers” as good as Apple’s, said Vic Gundotra, a Google vice president who oversees mobile products.

Mr. Gundotra said Web browsers as capable as the iPhone’s could also prove a boon for developers of mobile software, who have long struggled to adapt their programs to different types of phones. As it does on the PC, he said, the browser could provide a more homogeneous “layer” for programmers.

“The reason no one considered this seriously is that the Web layer on mobile devices was terrible,” he said. Google has taken advantage of the capabilities of the iPhone browser to create a product, internally called Grand Prix, that it says provides easy access to many of the company’s services, including search, Gmail, Reader and Picasa.

Google, which developed the first version of Grand Prix in six weeks, is introducing a new version on Monday, just six weeks after the first one. That is a speed of development not previously possible on mobile phones, he said.

2008. The year that developers swarm onto mobile phones through the Web floodgates.