Tuesday, 11 November 2008

Mobile Gmail rocks!

Quick post about mobile Gmail.

For about a year now i have been using the mobile Gmail application and i recently upgraded to version 2.0. With all the media attention on the user interface for iPhone, Android, Blackberry's and Nokia's with touchscreens its easy to miss what is probably the worlds most frequently downloaded and used mobile java application.

Several things about mobile Gmail are striking:
  1. Simple, usable interface (No attempt to be an iPhone)
  2. One application - all devices. Same application runs on most devices with only minor adaptations to use device specific softkeys.
I really like this because it is a concrete example of how independent software developers (i.e. not aligned to networks or handset manufacturer) can deal with user interface and device fragmentation issues.

Simple usable interface
With all the handset manufacturers falling over each other trying to mimic the iPhone user interface its good to see an application that does not resemble the iPhone at all and is still cool and easy to use. Whether you use mobile Gmail on Windows Mobile, Nokia S60 Nokia S40, Sony Ericsson or Blackberry it looks the same and is completely intuitive. The lesson here for software developers is to keep the user interface consistent - don't try and have different user interfaces on different devices.

One application - all devices
There are several strategies that software developers can follow when writing mobile applications. The ' fragmentationists' as i call them think you should develop seperate applications for each handset type. So fragmentationists will write a symbian application for nokia s60 devices. A dot.net compact application for windows mobile etc. The j2me-polish postcompiler is an example of fragmentationist thinking.
The 'integrationists' on the the other hand think it is better to write one application which adapts to the device it is running on. Mobile Gmail is an example of the latter. It is a java application which runs on most phones and adapts its navigation and user interface as little as possible to suit the device it runs on.
There are of course benefits to the fragmentationist approach. Cool features (camera viewfinder or cell id retrieval for example) are often easier to access using a handset specific programming language. Implemention of Java API's is often incomplete and unreliable.
However integrationist development is cheaper (one codebase instead of several) and more future proof than fragmentationist development. Today's fragmentationist technology (i.e. Symbian or Windows Mobile) could easily be tomorrows Psion (remember them?). If more software developers pursue this strategy it might tempt handset manufacturers to implement Java ME more consistently on their devices. And Google has proven that it is a viable strategy.

Tuesday, 26 August 2008

LWUIT, TWUIK and YahooGo

In past months there has been a lot of buzz around two user interface toolkits for mobile java applications; TWUIK is a commercial toolkit that provides a snazzy user interface with cool transitions and pixel perfect graphics. Yahoo Go is supposed to be 'the best Internet experience for your phone'. And LWUIT is an open source toolkit that provides a snazzy user interface with cool transitions and pixel perfect graphics. But first: why should we bother with these toolkits in the first place?

Why bother with a user interface toolkit in the first place?
The answer is simple; building a user interface using java mobile edition is really hard and gives disappointing results. Either you program all user interface widgets yourself (writing code to draw textboxes is nostalgic, but not very productive) or your interface looks quirkily different on every device type.

TWUIK by Tricastmedia looks cool, but i've known people who tried to buy it and got no response (phone or email) from them. You can't test drive a demo version of their toolkit or download it. So my conclusion is they aren't serious about their product.

YahooGo is Yahoo's product to create an ecosystem of mobile apps and widgets. Strictly speaking, its not a UI toolkit, but a app/widget creation tool.

LWUIT is a fairly recent addition by Sun microsystems and adds a Swing type programming to java micro edition. Seeing as LWUIT provides a demo application i was able to test it on a number of KVM's. The proposition that LWUIT offers is that it offers the same cool user interface on any device (although it requires CLDC 1.1 which rules out 50% of devices currently in use). Here's how it fared on a number of Java Micro Edition runtimes:
  • Sony Ericsson JP5 (K750i): runs perfectly
  • Nokia S60 (6121): runs perfectly
  • HTC/QTek 9100 Tao Intent KVM: Some quircks.
  • IBM J9: Fails miserably.
  • RIM BlackBerry (8100): Fails miserably.

Admittedly, i've known more applications to fail on RIM Blackberry initially due to its deviant threading model, so that might just be that the demo code wasn't written properly for BlackBerry.

So is this real progress?
Well not quite yet. On the devices it worked on, LWUIT looked great and if you are targeting high end smartphones and don't care about BlackBerry's it will probably work for you. But if you are looking for a toolkit that will enable you to distribute cool looking applications on the majority of devices in use today you will be disappointed. But as older devices are replaced by newer ones in a year or two we could find ourselves wondering how we ever coped without LWUIT.

Wednesday, 16 April 2008

File access from Java Micro Edition

This article describes how to access files on a mobile device from a Java Micro Edition application. In particular how to access files that are at a random location on the device such as in the 'My Documents' folder on a Windows Mobile device.

The first hurdle you need to take is to determine whether the Runtime Environment will allow you to access files. Generally this will require that the Java Micro Edition Runtimes implements JSR-75. If you have a smartphone with a pre-installed Java Runtime you can look up the specs on the manufacturer's site, but don't raise your hopes. If you are using IBM J9 you are in luck, JSR-75 is supported.

To enable JSR-75 for IBM-J9 you need to (taken from Markus Brosch's blog):
  1. Get this jar file http://service.boulder.ibm.com/ibmdl/pub/software/pervasive/updates/571/techs/features/com.ibm.weme.wm2003.arm.pdap-fc.runtime22_5.7.1/wsdd5.0.jar. It contains a folder fixed with Personal Profile and MIDP subfolders and under that a directory structure analogous to the directory structure of the J9 runtime.
  2. Copy: fixed\ive-2.2\runtimes\wm2003\arm\midp2\bin\fileconn.dll into this folder on you mobile device: YourJ9Folder\bin\
    Copy: fixed\ive-2.2\runtimes\wm2003\arm\midp2\lib\jclMidp20\ext\fc.jar into this folder on you mobile device: YourJ9Folder\lib\jclMidp20\ext\
  3. If your Java Runtime was running, restart it.
You can then access files using the javax.microedition.io.file package.

Monday, 4 February 2008

The future of applications on mobile phones

The mobile industry is developing at an enormous pace. For consumers and industry professionals alike there is a lot of uncertainty as to where things are heading. Customers, friends and co-workers frequently ask me what is going on with xyz technology so i've decided to write down some of these questions and attempt to answer them systematically. If you have any questions, post a comment and i'll try to answer them.

Q. Doesn't the iPhone mean the end of all other manufacturers mobile applications and mobile browsing?
A. The iPhone is a huge marketing and sales success in absolute terms, but relative to the size of the market for mobile devices, mobile applications and mobile internet it is still a small player. From the market reports i have seen on the internet less than 1% of devices in the US is an iPhone. I see the iPhone as being comparable to the iPod. The iPod is very successful, but there are still many other succesful music players around. The iPhone and iPod are comparable in another way; the iPhone is a completed closed device. Development of third party applications and content is rigidly controlled by Apple just as iTunes is completely controlled by Apple. If you want a device on which you can install a random MP3 fragment (as a ringtone for example) then you won't be getting an iPhone.

Q. Isn't Windows Mobile the mobile business platform for the future?
A. Windows Mobile has increased its market share dramatically during 2006 and 2007 and is increasingly being used for business applications. That said, it is still a minority player in the mobile devices arena. Nokia's Symbian platform and Apple's iPhone have sold far more units in the same period. In the PC world the last 20 years has seen one dominant platform (microsoft) and several small players (IBM with OS/2, Apple and Linux). The mobile industry is in the same stages as the PC industry in the early 80's. There is NO DOMINANT industry party with respect to operating system or hardware platform. In the last 10 years we have seen Psion and Palm go from market leader to irrelevant. Windows mobile has not even been market leader but is already being surpassed by Apple's iPnone. And there is more to come, open standards based Linux phones are starting to emerge. It will be interesting to see where that will be heading.

Q. Can you browse regular websites on mobile phones.
A. Short answer: No! Long answer: Mobile devices generally have the computing power of a 1993 PC computer. Try and remember (if you were over 12 at the time) what internet browsing was like when you first heard of it:
  • Buggy browsers called Netscape or Mosaic.
  • Pictures taking forever to load.
  • No fancy effects.
  • No audio, definitely no video.
  • Lots of waiting.

On your desktop there a a few varieties of browser software most notably MS Internet Explorer, FireFox, Safari and Opera. Incompatibilities between these browsers have caused many problems for users and developers alike over the years. The situation with mobile browsers is much much worse. There are dozens of varieties; each with its own quirks and bugs. Websites for mobile devices have to take this into account.

The waiting was due to the limited network bandwidth. And while desktop users are now used to high speed dsl or cable connections mobile networks still have limited bandwith. Regular webpages are generally just too big and take forever to load over a mobile network.

The limited features were due to the limited processing power of the hardware. While deskop (and laptop) hardware grew more powerful, the websites we visit became more complex and contain all sort of program scripts / code. Mobile hardware just cannot cope with this, so mobile phones are given restricted browsers that ignore a lot of what is going on on todays websites. In effect you can't use the websites.

Q. Shouldn't we aim to make the same web pages for all hardware (both desktop and mobile).
A. This is known the 'One web' theory. I would like for this to be true, but the reality is that most websites contain stuff mobile browsers cannot handle. I also think that this is not going to change soon. Desktop and Laptop PC's evolve at the same rate as mobile devices so the gap is going to remain. Already many websites use extensive javascript coding (which doesn't work on most mobile browsers) to make them more interactive and that trend is set to continue.
There is also a usability issue. Regular websites are generally designed for screens with 1024x768 pixels. If you reduce the window size to 178x120 and imagine you have no mouse and only the numeric part of your keyboard you will get an idea of how difficult it is to use regular websites on a mobile device. This warrants designing seperate pages for mobile devices.

Monday, 14 January 2008

Location based Java Micro Edition part 2

I got bogged down in work, but here is the next installment on Location based service in Java Micro Edition.

The Location API
In theory the Location API is the ideal solution for getting location information in a java program. A working demo with source code is included with the Sun Wireless toolkit (from version 2.5 onwards). You can deploy the demo on a real phone and chances are it will work. But here come the nasty details:
  • The location API is not implemented on the majority of devices.
  • If you are thinking of determining at runtime whether you can use the Location API: in most cases you cannot, because the Location API requires CLDC1.1, whereas a large number of devices have CLDC1.0. So you cannot compile an application for CLDC1.0 with Location API references and even if you could, it would not deploy.
  • Location API implementations are of mixed quality. Devices i have seen with inbuilt GPS receivers such as the Nokia N95 tend to have good implentations. But most implementations default to looking for a Bluetooth GPS device. This is reasonable since Bluetooth GPS receivers are cheap and abundant. However the way in which the Location API handles communication with a Bluetooth device can not be influenced by a java application. For example once a GPS device is selected it tends to stay selected. There is no user interface or API for unselecting it or selecting another device. Another example is how the location API handles connection problems. Should it use a timeout in the event a gps device sends rubbish or is turned off and if so how long should the timeout be? Should it try to reconnect? If you use the Location API you will have no control over these matters. Most likely the only advice you can offer users with problems is; reset your phone and try again please (because we don't know what your phone is doing)!

So unless your target devices are ultra modern smartphones with inbuilt gps receivers it is best to give the location API a wide berth for the moment. So that leaves you with two options for developing location based applications; Bluetooth and Com port.

Coming next ... the wonderful world of Bluetooth communication in Java Micro Edition