android

Mobile Sites Outpace Native Apps… But What About Web Apps?

Posted by Mike Brittain on February 05, 2010
Mobile / Comments Off on Mobile Sites Outpace Native Apps… But What About Web Apps?

I was excited to read this article about mobile web sites growing faster than native apps, a trend I believe will continue in the future.

Taptu estimates that there are 326,000 Mobile Touch Web sites worldwide, which they say compares to 148,000 iPhone apps in the App Store and 24,000 apps in the Android market. Taptu expects the browser-based mobile web market to grow much faster than the app market.

I’m excited about browser-based apps and the potential of HTML5 as a platform for cross-platform app development.  It’s too bad there’s not a distinction in these numbers between web applications and content sites that simply have layouts customized for display on mobile devices.

Mobile-Friendly, Web Apps, and Native Apps

When the iPhone was launched, Safari became the first mobile browser to really represent web sites as you would see them on a desktop browser.  Before then, surfing from your phone’s browser was a clunky experience with unsupported HTML and CSS features, and web proxies that would reformat or strip out content deemed unfriendly for the mobile browser.  On rare occasions, you might stumble into a site that would push your phone’s browser to a version of the site formatted specifically for display on a small screen.  Today, the term “web app” gets confused with “mobile-friendly” web sites.  I say they are wholly different products.

Native apps are touted for their advantages over web-based apps, which include: 1. better exposure to hardware- or platform-specific APIs, 2. potential for instant revenue streams (payment via app stores), and 3. ability to operate in an offline capacity.

It’s difficult to argue against native apps and games that tie into platform-specific APIs unavailable to web apps.  However, there are plenty of services available for making payments to web sites, but developers need to keep in mind their competition in native apps.  You can’t charge $5/month for access to your web app when a similar app sells for a one-time $0.99 fee through an app store.  Finally, the point of offline access is fairly ironic given that so many native apps are simply wrappers for network APIs and cannot run without a network connection.

So when I talk about web apps, I don’t just mean a mobile-friendly web site.  Rather, I’m talking about the potential to build rich applications that can run in a browser.  Using HTML5 capabilities like offline data storage and object caches, web apps can mimic many of the same features built in native apps but have the ability to reach across platforms and devices.

My own definition of web app an application that:

  1. Is written with core web technologies and runs in a browser,
  2. Provides more utility than simply reading pages of content,
  3. Is responsive to user interaction and gives the same impression that an installed app gives, and
  4. Is device and platform independent, indeed it should be irrelevant whether it is displayed on a mobile phone, a desktop computer, or any other device.

The Web App Findability Problem

Platform-specific app stores have risen up as clearing houses for apps. Users are being conditioned that the term “app” means something you download and install on your phone.  App stores are backed by big marketing dollars and ad campaigns because they provide a competitive advantage for their platform and create new revenue streams.  Web apps, on the other hand, provide neither.

There are online directories of web apps to solve this problem, but these don’t have nearly the visibility or marketing of today’s app stores.  It would be difficult for consumers to even consider web apps when they have a nice, easy shortcut to their platform’s app store built right into their phone. Even Apple, who claimed at the release of the first iPhone that web applications were enough, do not provide a means for finding web apps from their phone.  Indeed, their own web app directory doesn’t render in a mobile-friendly format.

Visibility is a key barrier for web apps.

Where Will Web Apps Get Their Exposure?

I’ve thought over a few possibilities for building the web app market, which are outlined here.

First, app stores could expand their listings to include web apps. There are already plenty of free apps in the stores.  Web apps would not create any new low price points.  I see business concerns with this direction, though.  App stores have their own services to charge for paid apps at the point of purchase.  A web app is never downloaded, so it is difficult to charge a toll for access.  Furthermore, web apps might require subscriptions or usage fees, but would be open to choose from a variety of payment gateways.  Owners of app stores would likely see this as losing out.

Search engines could provide niche listings for web applications in the same manner that news, shopping and image search reasults are handled by Google.  Search engines are supposed to provide unbiased rankings and could probably fit an app directory well.

The last idea would be to identify web applications using a new “.app” top-level domain, similar to the .mobi TLD used for mobile compatible sites.  The term “app” has already become part of the vernacular and its use as a TLD could easily identify a URL as a pointer to an application (desktop or mobile) as opposed to just mobile-friendly web pages.

Tags: , , , , , ,

Browser Testing for Mobile Web Applications

Posted by Mike Brittain on January 31, 2010
Misc / Comments Off on Browser Testing for Mobile Web Applications

Developers working on mobile web apps need to be able to test their apps or sites in all of the major mobile platforms.  Unfortunately, there are not a lot of good resources online for how to go about this.  You could pay for a service from a mobile testing company, like DeviceAnywhere, who provides access to a wide selection of real devices (using a virtual client).  Or you could go the free route by installing a variety of SDKs and mobile phone simulators.

Base Setup

I’m developing on a Mac.  Many of these emulators are Windows-specific.  Additionally, this could end up being a lot of work to setup, so putting all of these tools onto a Windows virtual machine will let me move the VM to another machine in the future and save me from reinstalling from scratch.  On my Mac I’m running Parallels Desktop with a copy of Windows XP.

The only exception is the iPhone SDK which includes a simulator for the iPhone.  The iPhone SDK is only available for installation on the Mac OS and I’ll be leaving it out of the instructions below.  I also haven’t installed or tested the 3.2 (beta) yet which includes an iPad simulator.

Java

Big surprise that Java is used for some of these SDKs and simulators, so we might as well get started by installing the JDK and runtime if you don’t already have it installed.  You should be able to download a copy of the JDK from here:

http://java.sun.com/javase/

I grabbed “JDK 6 Update 18”.

Android

Download the Android SDK from Google’s Android Developer site and run the enclosed SDK Setup program.

Unzip the .zip package you download and put in a location you want to keep the files (perhaps within Program Files) and then run the SDK Setup program.

In the “Installed Packages” section of the setup program, click “Update All…” to download the platforms and APIs that will be run by the SDK.

To create an emulator for a specific version of the Android OS, select the “Virtual Devices” option, then click the “New…” button.  In the dialog box that opens, enter a name for your emulator and select a target OS (e.g. “Android 2.0.1”).  Then click the “Create AVD” button.  Select your new emulator from the list and click the “Start” button.  When the emulator starts you’ll find an icon for “browser” on the main screen.

Symbian

In the past, I have setup Symbian emulators and SDKs to do local testing.  When I returned to their site to download new software I was pleased to find that they now provide a service for accessing virtual devices over the Internet using a Java application.  Visit http://apu.ndhub.net/ to register and access a wide selection of devices.

Easy!

BlackBerry

BlackBerry simulators for various models and OS versions can be downloaded from their developer site.  Each simulator is downloaded as its own installer package.  So download all of the  emulators you want to test (Storm, Bold, Pearl, etc.) and run their installers.

http://na.blackberry.com/eng/developers/resources/simulators.jsp

This seems simple enough, but if you start up one of these simulators and open the web browser you’ll quickly find that you’re missing a critical piece: network access.  To access the web from these emulators you need to also download the MDS Services Simulator package.  Find a link for this download from the resources page:

http://na.blackberry.com/eng/developers/resources/

Also note that BlackBerry makes available some documentation specific to web application development for the BlackBerry platform.  You can find these resources at the address below (registration required):

http://na.blackberry.com/eng/developers/browserdev/

Palm webOS SDK

The Palm SDK includes a web browser within its phone simulator which is useful for testing the browser that runs on the Palm Pre and Palm Pixi.

Go to Palm’s developer site and look for a button or link to download the SDK.

The emulator runs within Sun’s VirtualBox software.  There is a link from the Palm download site for downloading VirtualBox.  Follow the instructions and install VirtualBox first.

Next, download and install the webOS SDK.

Once you’ve completed the installation, you can start up Palm emulator from your Start Menu: Programs > Palm > SDK > Palm Emulator.

When you run VirtualBox, it may prompt you to download an updated version.  The Palm Emulator (as of January 30, 2010) will not run on the latest version of Virtual Box.  Stick to the version that you download from the Palm Developer web site (3.0.10).

Wrap up

This should get your started with a testing environment for a few of the top mobile browsers on the market today.

If you’ve got other tips to share about testing mobile browsers, share them in the comments below.

Tags: , , , , , , , , , , , ,

A Web Without Flash?

Posted by Mike Brittain on January 31, 2010
WWW / 1 Comment

Scoble has an interesting post asking Can Flash Be Saved? His central point is that developers will make use of whatever technologies that are widely available to their users which, of course, makes sense.  He draws an analogy between the growth of the iPhone OS, which does not include Flash, and Firefox, which does not include Microsoft-centric technologies like ActiveX.  Within the first years that Firefox began to steal share from Internet Explorer in the consumer market, developers changed the manner that they coded their sites by embracing Web Standards.

The interesting thing about that change was that Firefox’s growth was fairly slow outside of the developer community.  Many developers loved Firefox, but it took a few years for the general public to get hip to the browser.  I would have to say that the iPhone has far higher brand recognition and uptake.  You could attribute this to Apple’s strong marketing machine.

Mobile web browsing is still a small market compared to desktop browsers.  It’s a tiny, but growing market that can’t be ignored.  I believe that in just a few years mobile Internet services (including networked apps)  will be more important than the desktop Internet for communication, entertainment, and consuming information.  Devices like the iPhone and iPad are driving this forward.  Android is growing and finally seeing a wider number of devices offering Google’s mobile OS.  BlackBerry is a widely used platform, but it doesn’t contribute much to mobile web usage (yet).

If these (iPhone and Android) operating systems become the leading platforms in the mobile space, developers will build sites and apps based on the technologies available across them, namely HTML5 support that is part of the WebKit engine.  If Flash continues to be blockaded from the iPhone OS, developers will certainly look to other technologies to replace it.

Tags: , , , , ,

How to Improve JavaScript Latency in Mobile Browsers

Posted by Mike Brittain on January 20, 2009
Mobile / 2 Comments

Mobile browsers are really coming along.  Mobile Safari is built on top of WebKit and has just as much capability as the desktop version.  Same with Android’s browser.  Blackberry’s browser, I understand, has improved tremendously over previous versions.  The new offering from Palm centers application development around web technologies HTML, CSS, and JavaScript.

As more applications and data grow to live in the cloud, then access to them via a browser must be easy and fast, which is often not the case with data on mobile devices.  A web site can take many seconds to several minutes to load all of the content required.  And at the heart of many sites these days lie some common elements — JavaScript libraries.

Personally, I have avoided heavy-weight libraries for mobile application development, because I know that they are a burden to the end-user.  This is less often the case for desktop users, who typically have broadband connections at home or at work.  So what do we do to improve this situation?

I propose that the mobile browser makers (or OS makers, in most cases) embed standard versions of common JavaScript libraries within their browsers.  Google already makes a number of these available as a hosted solution for web application developers: jQuery, YUI, Prototype, script.aculo.us, etc.  Other players, particularly in the CDN space, could also become involved in hosting these frameworks.  Nearly half of the libraries that Google hosts are larger than the 25 KB cache limit in mobile Safari (for example).  By embedding a handful of these libraries, mobile browsers could speed up some of the overhead of mobile applications that rely on Ajax or heavy DOM manipulation.

How would you do this?  Likely by inspecting HTTP requests by URL.  Google’s hosted libraries include version numbers, which allows developers to peg their work to a specific version, not having to worry about quirks in future versions that could upset their apps.  When an application makes use of one of these embedded libraries, the browser can simply execute the JavaScript library without having to make an external request.  If the application uses a newer version that is not embedded in the browser, the HTTP request would proceed as normal.  End users would get a slower experience than with an embedded framework, but that experience would be no worse than we have now.

I’m interested in hearing others’ thoughts about this idea.

Tags: , , , , , , , , , , , ,

Why Android is Important

Posted by Mike Brittain on January 20, 2009
Google, Mobile / 2 Comments

I was in a conversation the other day about mobile platforms and the topic of Android, Google’s mobile OS, came up.  The general outlook was: new, interesting, but too few devices to be concerned about.

I’ve read a modest amount of material about Android, but the sense I have is that Google is at the tip of the iceberg right now.  Sure, only one device has been rolled out to date, and only through T-Mobile (bleegch).  But more devices seem to be in the works, currently abroad, but certainly more in the United States soon.

The thing that is interesting, however, is that this is an OS that is (or can be) geared for devices other than cell phones, including netbooks, TVs, and kitchen appliances.  It has great reach potential, which has not been demonstrated (yet) by other players.  That is something to be considered by developers who are thinking about the next big mobile application to develop — because you might just find yourself playing Scrabble on your fridge while you’re waiting for the water to boil.

Tags: ,