Developing J2ME application on Linux

csak — Thu, 07 Jun 2007 23:27:49 +0000

We are starting up prototyping on a new project I’ve mentioned in this article. Our aim is to provide a proof-of-concept implementation of a simple off-line application running on the PDA’s we have.

The PDA’s of today are quite well equipped, they come with ample processor power and enough RAM for running medium sized applications. We’re supplied with some rugged Symbol PDAs, running Windows CE 2003 (I might be wrong there, as I haven’t laid my hand on one for longer than 5 minutes)
Just to make things clear, I never done any J2ME development and I’m not very familiar with the concept of configurations or profiles either.
Going through the Net and checking the scene I’ve found that there are only few options for J2ME development other than vi. The most favored recommendation seemed to be the Netbeans Mobility Pack, but I said I’m not touching that with a six foot pig-teaser pole. For the first run I’ve opted for using EclipseME instead.
EclipseME 1.6.8 is a pretty simple solution, and can use Sun’s Java Wireless toolkit 2.5.1 seamlessly under Linux.
In a couple of minutes I was able to bang together a simple HelloWorld midlet, being pleased with myself. This was going better than I thought, so I went on with extending the application. I banged together a simple form display using SAX based xml parser and the lcdui controls. After I had my first form with a couple of controls displayed I went out to the Net to see which embedded language I could use to store and evaluate the logic parsed from the XML. I went to see the usual suspects, BSF, Groovy, Jython, JavaScript and my favorite BeanShell. There were traces on the forums that some people have already struggled with this out there, this didn’t make me feel more secure, but at least I knew I was not alone. After hours of reading it turned out that BSH has the smallest footprint of this all (cca. 145Kb) but whatever I do the language will use reflection to access the host objects. This was hardly a surprise, but the surprise came when I realized MIDP and CLDC do NOT support reflection. This was the time when I realized that I was using the wrong environment all along.
No problem! – I thought – I just switch over to CDC and Foundation or Personal Basis Profile and I’m all set!
This was when my hair started graying, I went through the Internet to find a single CDC implementation that can run on Linux, but no luck. Sun, Nokia, Motorola, Sony just to name a few, even though all strongly support Linux don’t provide any development environment for any OS other than Windows. This basically means that once you want to develop for any PDA in J2ME you are resorted to use a Windows based machine.
There seems to be a touch of light on the end of the tunnel though, IBM does provide a solution even if it’s quite dated, that is Linux compatible. See the Websphere Studio Device Developer site to get a trial version. I thought Eclipse 2.0 is something I’ll never see in my life, but this is something I give a hearty welcome to! For our current project this is a reasonable alternative to use, but buying this for any other project seems unreasonable. As far as I can see this product is already discontinued, so I don’t expect to have it around for much longer.

Off-line SWT application

csak — Wed, 09 May 2007 23:02:05 +0000

One of our current Customers have a very interesting requirement for an upcoming project. The nature of the project requires mobile clients and frequent (or even instant) database updates, but there is no guarantee to have constant connectivity. We more or less have full control on the choice of tools to use for this application, but since our developer resources are limited, it would be great if we could use the architecture from a previous project. We’ve been working with András on this for quite a while and it seems we found a pretty interesting way to do this.

The current architecture looks like this:

The RCP client connects to the application server using Axis based web services that uses our framework to call the business logic which accesses the database through Hibernate.

As the application currently uses web services to access the framework containing the business logic and this is already separated in the application it’s relatively straightforward to modify this dispatcher to access the business logic.

When online the modified application works just like the one above, and during the online period the application will synchronize its database with the server using DB2 Everyplace.

When the application is off-line the actions will perform the actions on the locally synchronized database, and send MQ messages of these actions through the local MQ Everyplace. Thus the application will see the local database as it’s own and perform the actions on it’s local database. The requirements allow for this, as the data is distributed among the users, (it’s more of a data collector, than business application) and there is only a very little chance of simultaneous updates.

When the client goes on-line again first the MQ messages will be sent to the server, the client will then wait for all the sent messages to be consumed by a message bean on the application server. After the messages are consumed the local database can be synchronized with the server so the data modified by other clients will be reflected on the client.

We’ve also considered using the features of the Lotus Expeditor platform, which works similarly, but decided against it. Our two main concerns were, that firstly we have limited resources and learning a new platform is time consuming, especially for such a new framework, the other was that Lotus Expeditor’s works offline like the original Lotus Notes platform (this is our assumption, based on a very short research) has the preconception, that noone is allowed to use the same database at the same time. If someone does the records are marked as save conflicts that must be reconciled manually.

Our way would permit the business logic to handle these updates gracefully, by either simply applying the updates on the given record in sequence, or refusing the update using either a version- or timestamp, or in workflow like cases statuses.

I’m sure this is not the only, and very likely not the best way to do this, but it’s most certainly the one that would require the smallest effort.

The images suck, I know, but I’m not in a drawing mood right now.

ITworks » SWT

Developing J2ME application on Linux

Off-line SWT application