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

Monday, 17 December 2007

Location based Java Micro Edition

My first encounter with location based services was in 2000 when working for a telco back when the internet bubble had not burst and life was good! Several months later the telco shelved the technology due to lack of enthousiasm of customers to pay for knowing where they were. And that is probably still the case today. Unless you are offering something fantastic (like on-board car navigation for example) nobody is going to pay for location based content.
Nonetheless the last year has seen a revival of location based chatter on the web and i don't seem to be able to escape from it. Last year we field tested location based java micro edition software on regular phones and bluetooth gps receivers. Then this year three seperate companies asked us help them with their location based software. All three were having difficulties with the technology so it's safe to say it's not as easy as some might portray.
First off, there is very little on the web in the way of working, open examples that you can take apart and examine. Countless sites have a code fragment that works for them, on their hardware. And then there were a bunch of authors who wrote about something they made in the Sun WTK emulator but never tested on a real phone. These 'look at me, my boss gave me time to read the tutorials and now i'm a guru' authors always annoy me because they always say things that are wildly wrong. For example at a local Java conference in the Netherlands there was someone lecturing on location based services who made the bold claim that 'Your mobile will determine which location based services are available and use them, so if you do not have a GPS receiver it will use the telecom networks positioning information. And yes you can actually use that right now!' not knowing that at the time there were no network operators that had that service switched on.

Anyway dragging myself back to the topic; part of the enthousiasm on the web has been due to the fact that a number of device manufacturers are starting to implement the location based API (JSR-179). It's been around for a while, but there used to be only two phones (guarded in finland by dragons) that had any sort of implementation. And needless to say they both had a different implementation all together. But Nokia and Sony Ericsson have been introducing enough models with a JSR-179 implementation to make it fairly widespread in the high-end segment of the phone market (in Europe anyway). This is a good development, but there are still a few problems with the Location API JSR-179 implementations:
  1. There are few phones that actually have an inbuilt method for location determination. The Nokia N95 must be the most popular, but most phones just do not have GPS hardware.
  2. The hardware that does have inbuilt GPS chips and antenna's tends to be exactly the hardware that is running an operating system that is hard to run java on. For example all the windows mobile devices that are popular for (among other things) in-car navigation. And what about all the Garmin, Becker and TomTom hardware that people are buying in busloads. Ever tried to run Java on one of those?
  3. A JSR-179 implementation dictates CLDC 1.1. So if you are developing for a number of devices here is another fragmentation issue. If you want your software to install on a CLDC 1.0 device (and there a tons of them) you cannot use JSR-179. So now you have two code-bases.
  4. The JSR-179 implementations are still new and therefore buggy. For example an implementation we tried automatically tried to search for GPS bluetooth devices the first time we tried it, but had no facility to change which GPS bluetooth device was selected. Great if you buy a new GPS receiver!

Generally speaking there are three strategies for getting location information in Java Micro Edition:

  1. Use the location API
  2. Use the bluetooth API (JSR-82) and bluetooth serial port protocol to read from a GPS bluetooth receiver.
  3. Use the serial port protocol to read from a COM port on the device.

Each strategy requires completely different code. I've tried em all, and they can all be done, but not on all hardware.

It's late... I'll get back to this soon.

Friday, 23 November 2007

What does MIDP, CDC, CLDC etc mean?

What are MIDP, CDC, etc.

Someone posted a question as to what MIDP, CDC, CLDC etc are. At the cost of getting very technical we need elaborate on the java architecture to explain exactly what the differences are.

Java Virtual Machines
Java programs are compiled into a machine independent pseudo-code, that is called bytecode. To run this bytecode you need a so called virtual machine. A virtual machine is a device specific program that takes your bytecode and translates it to instructions the hardware understands. This seperation makes Java portable between operating systems and machine types. Most software developers only encounter the garden variety of Java Virtual Machine (JVM); the type you run on a PC or server. But this is where it gets nastier for mobile developers.

The three musketeers
There are three varieties of JVM:

  1. Regular Java Virual Machine (JVM).Used by Java Enterprise Edition (J2EE), Standard Edition ( J2SE) and Connected Device Configuration (CDC). Allows you to access native code on the machine it is running and does cool stuff like verifying your java bytecode to make sure it doesn't do anything it shouldn't (like format your hard drive). The Connected Device Configuratio (CDC) is intended for high end PDA's/smartphones and contains a fair amount of the standard Java packages.
  2. Kilobyte Virtual Machine (KVM). Intended for small devices with crappy processors and a pathetic amount of memory. To get the virtual machine to run on these devices they decided to rip a lot of stuff out: Most notably lots of useful packages and classes and the bytecode verifier. So programmers have to run a seperate verifier to make applications for this virtual machine. Also they removed the capacity to run native code. Java configurations that run on the KVM are called Connected LIMITED Device Configurations (CLDC). If you want to start programming for CLDC beware; programmers are left with a bare minimum of classes - its java in 1998 all over again.
  3. Card Virtual Machine (Card VM)They ripped so much out of this virtual machine that it can run on a smart card (i.e. in the chip on your credit card or on your SIM card). I've never tried it, and hope i never have to. Supposedly you can do really cool stuff with RSA encryption.

In summary: CDC refers to java that runs on one type of virtual machine (JVM) and CLDC refers java that runs on another type of virtual machine (KVM)

In the embedded and mobile arena they (the organisations that lumbered us with Java Micro Edition - i always envision them as committees sitting around formica tables drinking coffee from plastic cups) decided to make life easier by introducing profiles. A profile is aimed at applications of a specific type. The main profiles are:

  1. Mobile Information Device Profile (MIDP). Translates as Java for cellphones. Manages the lifecycle of programs on the cellphone: installation, security, startup, running, pausing, stopping etc. The main entity in this profile is called a MIDlet. A MIDlet is the thing that you install, run etc. Security is writ big in this profile. Anything remotely interesting (like doing an http request to a server) will result in the cellphone asking the user to verify they want this to happen.
  2. Personal Profile (PP). Translates as Java for Windows Mobile / Palm devices. The main entity in this profile is called an Xlet. An Xlet is the thing that you run etc. Installation and security are not managed much in this profile. You can copy across your class files and run them using the Personal Profile virtual machine.