What future for Java ME mobile banking?

The mobile banking applications I worked on during 2008 and most part of 2007 gained a little spotlight on May issue of Wireless4Innovation italian magazine. The magazine is very marketing oriented, so the article itself has not much appeal from a technical point of view; yet it gives me some satisfaction.

In the last year or two, interest in mobile financial services is constantly increasing leading to a demand of (web or standalone) applications that can meet the user's usability and security needs.



"The future of Mobile Banking", which is part of the article's title leads Java ME developers to an unsolved and well known problem: certification and secure data transmission.

The post "How MIDlet signing is killing J2ME" on Javablog, despite some arguable cost calculation and conclusion, hits some point. From my point of view, MIDlet code signing specification that doesn't give the Big Ones (you know, manufacturers, carriers, both traditional and MVNO) a list of mandatory certificates that MUST be supported is simply meaningless. As you can read in some of my previous posts, every code signing certificate available on the market cannot be used on Motorola devices, it can be used on some Samsung device and are fully supported only by Nokia and SonyEricsson devices. No news about LG devices: you just have to buy one, try your signed app and pray. This, until some carrier or manufacturer (what about RIM?) decides the "they" want to sign your application in order to make it executable on their phones. This is where certificates fragmentation issue reaches the madness apotheosis: even if you buy all the code signing certs you can find on the market, you won't be able to cover enough devices to satisfy some important customers such as banks, insurance and financial companies.

The extreme solution, then, seems Java Verified Program, a commercial program where you pay people in order to test and sign your MIDlet.

Now, since you can't modify an application after they've signed it, unless you want to pay again for it, this implies that you have to give to these people a banking application that uses a real user with a real banking account: is this acceptable? Of course, it is not.

You could put in your application a dynamic URL configuration module, just to let them test and sign it on a pre-production enviroment. But, if you don't have planned to do it for for your own purposes, doing it just for passing the JVP is such an absurd idea that it does not even deserve a thought.

Edoardo Schepis tells us very well how can be expensive and frustrating this process.

And, then, after you've signed your application it comes the HTTPS certificate compliance problem...

Many developers, far more expert and important than I am, explained these things in detail many times: I just add one more goodnight thought.

Java Me could be a mature technology for business applications, not just for games and widgets. It had years to conquer a market for which mobile web application were not fit: wap sites were almost unusable (I hate them...sorry!) while MIDlet can provide fast, usable and functional UIs with a very light data exchange, based on XML messages. Its only weak spot was delivery, but it was something that it was possible to work on.

Now it seems to me that this great chance is going to be lost: the iPod touch/iPhone browser offers a new user experience and it will give birth to a whole new generation of mobile web applications that are fit for business services. Faster to develop, with less fragmentation and certification issues.

What about MIDlets, then?

If MIDP 3 - if we'll live long enough to see it - will fail to solve this fragmentation issue and won't simplify its security model (which doesn't mean make it insecure), I'm afraid Java ME will be a leading technolgy just in the games industry and in those niche markets where peculiar device features are involved (ie: sensors, BT, GPS and so on..).