After yesterday's revelations on the future need for digital signing I thought I should find out little more about Java Verify. Java Verify is a new program that sets out some basic tests which all Midlets will need to pass. The specification has largely been developed by the big handset manufacturers. The tests are quite basic, things like does the Midlet start, pause, and exit correctly. Some of the test requirements are less clear. The user interface is supposed to follow good UI design guidelines. Its mostly common sense, but may be open to testing house interpretation.

The testing process requires submitting code and an executable to the Java Verify website where some automated tests are preformed. The the user interface must be tested by an approved testing house. The website provides links to such testing houses. Upon successfully passing all tests a digitally signed executable is created. Of note any changes to the app will require re-testing, although apparently only a subset of the tests needs to be run for small changes.

I also went to a couple of sessions on Machine 2 Machine communications; basically getting vending machines or vehicles to talk to the corporate network.

Orange is developing a proprioritary system which they are beginning to roll out, but its only on Orange networks, and only in three countries at the moment. In talking to some other attendees it seems there are third parties who already intergrate these kinds of services over many operators and many networks.

Java has also put forward a standard for this type of thing, called IMP 1.0. Its MIDP 1.0 without the UI packages. I think this is mostly being pushed by Nokia which has an OEM mobile phone module (Nokia 12) specifically targeted at the M2M market and supports IMP 1.0

I also attended an overview session on GPRS, which was vey informative. For a similar over view see TS 23.060 by the 3GPP. It is quite amazing how many servers, switches, etc are sent wirring every time one hits the WAP button. In fact its almost a bit ridiculous, but that's cause GPRS is a bit of a hack on top of the GSM voice system.

With regard to bandwidth the Network providers still see most of their revenues from voice and are reluctant to dedicate bandwidth to GPRS, thus the intermitant connectivity. Bandwidth and access are very much affected by how many users are using GPRS within a given cell. Realistic data transfer rates are around 25Kbits/s on new phones supporting GPRS and much slower on early GPRS phones.

Further to the problems with GPRS is that TCP and GPRS are not good friends. TCP was not designed to deal with low bandwidth short connections, and thats entirely what GPRS is about. To improve this situation various hacks exist. The most interesting of which is html filtering. To reduce the amount of data being transfered, html is filtered and certain infomation is thrown away. For instance comments are chucked, and based on the browser type, browser specific info is also thrown away. So html over GPRS may not work as expected, and there were some complaints that the HTML filtering mangled JAR files sent over GPRS.

I also some quite interesting discussions over lunch. Yep, I was networking.

AppForge is a VB based system which allows smartphone, and pda apps to be developed in VB. They provide a set of libraries which insulates development from the details of the platforms. I heard a few raves for it.

LogicaCMG is I think a UK based company doing some really neat stuff. They can use the camera on a phone to read 2D barcodes. No more typing in long urls just put barcodes on documents or even read them off of the computer screen. They can even show barcodes on the screen of a mobile and read them using a normal laser barcode scanner. Also in holland and soon possibly in the UK they are monitoring traffic congestion by tracking mobiles as they move from cell to cell along the highway. The operators are apparenly happy to provide this kind of info as it does not identify particular users. Lots of interesting ideas surround this kind of technology.

Whoops - a slightly overdue introduction. For the first time ever, I've invited a guest-blogger to post for the next few days. Michael is one of our developers, and is attending Orange Code Camp in France for a few days...

The first day at Orange Code Camp began with a rather long bus ride from Paris, but otherwise has gone really quite well.

The opening speaches focused on Orange's new born commitment to developers. They admit they may have done a poor job in the past, but they believe their future depends on developer partners. The business analogy of the moment is ecosystems. The idea being that Orange, customers, developers, and device manufacturers are all interdependent, and for survival and success all of these relationships need to be nurtured.

Orange's reason for Code Camp is to foster its developer reations. To this end Orange has centralised its developer support. There is now one point of contact for developers world wide, and the back end interfaces are in the process of being standardised across the world. In theory an Orange application developed in UK will work on Orange network world wide.

As for the customer end of the spectrum Orange has identified a lot of market segments, teenagers, parents, executives etc, and are targeting specific phones and service bundles. They beleive it is important to differentiate their user expeience from that of other network providers. They have spent a lot of time creating a consistent, cross-device, user experience, and claim that this approach has created substantial revenue increases. As part of this approach they have a set of signature phones tailored to the orange experience.

As for the device end of things Orange is partnering with all sorts of device and OS providers. The big sponsor of the event is Nokia, and Mircosoft, Sybian, PalmSource, etc are also sponsors.

Apart from Orange's business plan the most interesting tidbits of the day were B2B, and Digital Signing.

Business to business services (B2B) are a growing area. One novel example is a UK insurance company which is now providing 'pay as you drive' insurance. The idea being an onboard computer tracks your location and milage, and your insurance fees are calculated based on the amount and locations where you drive.

And perhaps the most interesting tidbit came out of a session on digital signing of phone applications. It seems the next generation of phones are going to implement security features which require applications to be digitally signed. These features are already partially implemented on current handsets, but are not being used. Getting a digital signature will require submitting applications to a testing process as dictated by the network providers, at some cost to the developer. Current costs are around $500 (USD) per executable. Without signature applications will not run!!! The reason for signing is to prevent viruses and other malicious code, prevent excessive user support costs due to poorly designed applications, and to ensure a positive user experience. At the moment the testing and certification process is quite different for different OSs and network providers, with standardisation expected over the next 5 years.

And finally, the food is really good.