Network Programming Tips for Mobile Developers (iPhone, Android, Java ME etc)

Among the most important things to master for a mobile application developer is network programming. Every mobile application I have developed has involved some kind of network communication. During the year I have learned a thing or two. Read on to get some tips & trick from me.

Quite often the server is developed alongside the client. This means that you as a client developer have to wait for those awfully slow server programmers. Not every server programmer is slow, but most likely you have to wait for some server functionality. In situations like these, it is handy to roll your own server. But as a client developer, you do not want to spend an massive amount of time to setup a server. In fact, if it takes longer than a couple of minutes most client developers give up. What you need is a server that is very quick and easy to setup. Also it needs to be simple, yet powerful. Many server programmers would recommend you setting up a Tomcat server. The advantage of using a Tomcat server is that it is very versatile. But I do not really like Tomcat. It is to advanced for me. Another solution is to use a Jetty server. This is simpler to setup than Tomcat, but yet rather powerful. It could be executed from Maven. As such is is convenient to use for automated tests. Maven takes cares most of the work, including starting and stopping your Jetty server. But there is a new and rising star, the Sinatra server. The Sinatra server is actually a Ruby library. You use Ruby to program the behavior of your server.   

A simple “Hello World” implementation for Sinatra looks like the one below (from the Sinatra Book).

require 'rubygems'
require 'sinatra'

get '/' do
  "Hello world, it's #{Time.now} at the server!"
end

The file is saved as a file with .rb extension, in our example we save it as “hello.rb”. Then you start your server as simple as this:

ruby hello.rb

You get a nice line saying that Sinatra has taken the stage and that your server uses port 4567. This could of course be changed, if you want to mimic another server without changing your code. It is very easy to extend your server functionality. Ruby is easy to learn and powerful for making your own server without any big hazzle. Take a look at the “Sinatra Book” if you want to master Sinatra.

Another common scenario is that you need to figure out what happens when you make a certain URL request, for example if you do a REST request. Before even writing a single of code, you could use the cURL command line tool. Its available on most platforms, like Unix, Linux, Mac OS, Windows etc. For a matter of discussion, let us assume that you want to check that you programmed your Sinatra web server correctly. Then you the following command:

curl http://127.0.0.1:4567/

The response should look like this:

Hello world, it's Mon Oct 25 20:44:19 +0200 2010 at the server!

So now you know how to implement your own simple server, as well as how to debug your server request using curl. But wait, there is even more tricks I want to share with you. I hope that you feel like reading a little bit more.

I think that XML is a rather misused technologies around. It is used for many things, ranging from describing your builds (Ant, Maven, etc) to describing serialized objects traveling through cyberspace (SOAP, REST etc). When SOAP was introduced, one main argument for XML is that it human readable. What? Have you ever seen a SOAP request that is human readable? If you are about to send and/or receive objects there are much more suitable technologies than XML. Especially when making a mobile client, where XML parsing could take to much time and memory, it is important to understand that there are good alternatives. One good old technology is ASN.1, that is hugely underestimated. It was designed for communicating data between different architectures and CPUs. It is fast even on a 8-bit CPU. The biggest drawback is that it is not widely supported and it requires an ASN.1 compiler. However you could implement your own ASN.1 encoder/decoder quite easy. Another solution that is easier to use, but building on the same principles as ASN.1 is the Hessian protocol. It is a binary web service protocol. The specification is originally designed by Caucho, who did the Resin web server. The specification is open and implemented in many languages, including .NET, Flash, Ruby, Python, Objective-C etc. I have primarily used it for Java ME, where only a subset is implemented. If you use it in Java ME, I would recommend considering using it to store object data in the record store. But now it is more relevant for me to use it on Android or iPhone. The Objective-C variant for iPhone is called HessianKit. It is open source and released under Apache 2.0 license. Thus it is not a viral open source license, which I think is great. I will not describe how to use it, since there already is a good article on the subject “HessianKit Released”. I hope that you will consider using Hessian if you are in the position to decide what web service protocol to use. If you feel the urge to use XML for your web services, you could use Burlap which is the XML version of Hessian. The communication is as simple as it could get using XML.

Another useful tool is a network analyzer. This is good for finding out what happens between the client and server. For example, if you want to take a look at the headers are many times auto generated. I have used Wireshark with great success. It would not say it is easy to use, but when you need to use it is priceless.

These are the tools that I think I use the most for network programming. What are your best tools when doing network programming?

Some Thoughts about Android

As a embedded developer working with mobile phones, there is a new interesting kid on the block; the Android platform. If you are a mobile developer you most certainly had heard of it.

The interesting thing from a Java developer point of view is that all the APIs are in fact in standard Java APIs. But the developers of the Android platform has selected a subset of the Java SE APIs. Thus the implementation is not a fully compliant Java implementation. Further on the code is not executed as bytecode. The source code is first compiled to bytecode. In the second step the bytecode is converted to Dalvik bytecode. The Dalvik bytecode is then executed on a Dalvik Virtual Machine. The Dalvik is optimized for devices with limited power. According to the people behind the Dalvik VM, it should consume less power than a normal JVM.

I have bought a HTC Hero to have the opportunity to use an Android phone and to develop applications for the Android platform. It is possible to execute a Android application on an emulator, but still I think there is a need to be able to execute on a real device. The emulator is real good and I think that it is very close to the reality. My experience tells me that in the end it is always better to run on an actual device.

As of now I have not developed an real Android application from scratch, although I have attended an Android course. I am really looking forward to making an Android application. If its gets good it would be interesting to put it on Android Market, aka Google Market.

But what will happen to Java ME? I think that Java ME will live long and prosperous, although some programmers that are tired of Java ME will move to Android. The devices that are out on the market today are primarily high end phones. Java ME is found on many low end and mid end phones. What do you think? Will Java ME survive now that Android has arrived?

Blu-ray, BD-J, BD Live etc

As you might know I am a cineast and a home theater junkie. I have tried to assemble a decent home theater. From time to time I upgrade it to achieve the ultimate movie experience. For several years now, I have been longing for a Blu-ray player. However I do not like to be a early adopter, at least when it comes to hardware. The primary reason is that it is to expensive, the secondary is that the technology needs to be mature enough for me to buy it. In this case it was in fact Java that stopped me. Why? Let me explain.

A Blu-ray player manufactured today is required to include a Java implementation to adhere to the Blu-ray specification. This is called BD-J. The intention with this is to be able to include more advanced menus, games and interactive contents. A Blu-ray disc can contain one or several Xlet applications. For a more comprehensive article on the subject, please download and read my article "Blu-ray and Java". When the MIDlet specification was released, it took several years before there was a decent implementation available. As it seems, it is the same with Xlet implementation on Blu-ray players. Many independent Blu-ray player reviews shows that Blu-ray discs with Java content have longer loading time. For example, it is reported that loading time up to several minutes is not unusual.

The July issue of the Swedish magazine "HemmaBio" contained a big review of several Blu-ray players. The LG BD370 was dubbed "Best Buy" and at a reasonable price. I searched the Internet and found several positive reviews, like this one. Besides the price, it seemed to have very good Java performance. In fact it is par with the performance of a Playstation 3 when it comes to loading times for Blu-discs. It adheres to the latest BD-J version and also has support for BD live. The BD live feature is used to bring live content to your Blu-ray player, such as trailers. For example, the "Transformer" movie let you connect to the Internet and download the trailer for the following "Transformer" movie. Another nice feature is the YouTube viewer. As you might have understood by now, I bought the LG player.

To try the player I bought two Blu-ray discs. I decided one disc while I let my son decide the other one. My choice was the "Pirate of Caribbean: the curse of the black pearl". This is by many considered as a reference Blu-ray disc. Both the picture and sound are great, but it also contains BD-J content. The BD-J content is used for testing the performance on Blu-ray players, since it is rather big. As mentioned before, it could several minutes to load the content. My son choose the movie "Bolt", just because it contained a game. It was a special edition that also contained the DVD version. So this was perfect to test a Java game and to compare the quality difference between the DVD version and the Blu-ray version. Both the picture and sound is considerable better.

I think it is interesting to see Java on yet another platform. It shows how Java is usable in many different environment. Java is finally used in an environment similar to the environment it was originally designed for, that is set-top boxes.

Here are some pictures from me using the new Blu-ray player.

The main menu when starting the Blu-ray player.

The featured videos on YouTube.

The search screen, while searching for the Jayway video.

The Jayway video in normal screen mode.


The Jayway video in full screen mode.

The Bolt game. Notice the localized version. I have not seen this on many computer games today. In the beginning of the game, the instructions are narrated. This is good for kids that could not read.

Appending to a File in Java ME ( J2ME )

Yesterday I was asked how to append to a file in Java ME. I have never done this before, so I could not give an answer. After some research we found a working solution. This article will go through the different ways to solve it.

I first looked into the JSR-75 documentation, but I did not find any solution there. When searching the Internet, the first solution I found was this:

public void appendToFile() {
try {
 FileConnection fileConnection = (FileConnection) Connector.open(
         "file:///c:/other/textfile.txt;append=true",
         Connector.WRITE);
 OutputStream outputStream = fileConnection.openOutputStream();
 PrintStream printStream = new PrintStream(outputStream);
 printStream.println("Some text to append");
} catch (IOException e) {
 e.printStackTrace();
}
}

At first it looks promising. The Connector class specifies that you could add parameters when opening a connection. However the parameters for JSR-75 are not standardized. This solution was mentioned in the Nokia developer forums, so I guess that it works on Nokia phone. The platform that we uses did not support it. Thus this solution is not portable across different Java ME devices. I recommend that you DO NOT use a solution like this.

The next solution I found looked like this:

public void appendToFileFileSize() {

try {
   FileConnection fileConnection = (FileConnection) Connector.open(
           "file:///c:/other/textfile.txt", Connector.WRITE);
   OutputStream outputStream = fileConnection.openOutputStream();
   outputStream.flush();
   long fileSize = fileConnection.fileSize();
   String textToAppend = "Some text to append";
   outputStream.write(textToAppend.getBytes(), (int)fileSize, textToAppend.length());
} catch (IOException e) {
   e.printStackTrace();
}
}

This works but is rather clumsy and does not look clean. Note that you need to call flush() before you make a call to fileSize(), otherwise the size is not guaranteed to be correct. But wait, there is another solution.

public void appendToFileMaxLong(){
try {
 FileConnection fileConnection = (FileConnection) Connector.open(
   "file:///c:/other/textfile.txt", Connector.WRITE);
 OutputStream outputStream = fileConnection.openOutputStream(Long.MAX_VALUE);
 PrintStream printStream = new PrintStream(outputStream);
 printStream.println("Some text to append");
} catch (IOException e) {
 e.printStackTrace();
}
}

The method openOutputStream(long bytesOffset) open an OutputStream and moves the position the specified offset. When the offset is greater than the file size, the position is moved to the end of the file. This is an clean and portable solution.

Detecting Flight Mode (Kind of) in Java ME on a Nokia Mobile

The other day I wrote an article about how to detect flight mode. But it did not cover how to solve it on a Nokia phone. On a Nokia phone, like a Sony Ericsson phone, there is no system property to detect flight mode. On the other hand, if we asume that what we really are interested in checking if the network is available or not, we have a solution on a Nokia phone. If we check this, we can make the MIDlet smart, e.g. setting it in off-line or on-line mode.

The solution is very simple:

String networkAvailable = System.getProperty("com.nokia.mid.networkavailability");

if(networkAvailable.equals("available")){
// Warn the user that the network is not available and off-line mode is used
}else{
// Network available => we could work as normal.
}

The trick here works on the Nokia S60 platform FP3, or later. I have not found out a solution on a Nokia S40 phone. Does anyone know?

Detect Airplaine/Flight Mode on Motorola and Sony Ericsson Mobile Phones in Java

Many MIDlets communicate with a server and/or connects to the Internet. If the user enables airplane/flight mode, the MIDlet should be aware of this. This way it is possible to set the MIDlet in off-line mode automatically and inform the user when trying to access the net. It is much nicer to get a dialog saying "Sorry you are in flight mode, you cannot this and that", instead of "Failed to connect to server". This article describe how to do this in Java ME (on some platforms).

There is no API that enable a Java ME developer to access the flight mode. The key here is to get a system property via the right key, no pun intended :) This is done via a call to System.getProperty("key"). The key differs from platform to platform.

On a Motorola mobile phone, with Motorola OS, this is done like this:

String airplaneMode = System.getProperty("com.mot.network.airplanemode");

if(airplaneMode.equals("true")){
// We are in flight mode
}else{
// We are not in flight mode
}


On a Sony Ericsson mobile phone it is a little bit different, since there is no system property to detect if we are in flight mode or not. The trick here is to use a key that detects the Radio Access Technology (RAT) used at the moment. This returns null if the radio is turned of, which it always is when in flight mode. The code looks like this:

String flightMode = System.getProperty("com.sonyericsson.net.rat");

if(flightMode == null){
// We are in flight mode
}else{
// We are not in flight mode
}


And that is it! Pretty simple, but still powerful. I hope this trick is useful for you.

Setting the Locale in the WTK Emulator

Sometimes it is useful to how your MIDlet works with different locale settings. One solution is to install the MIDlet on a phone and change its locale. This should be easy to do on most phones. However it is useful to do this on the emulator as well. This article teach youo how to do it.

You have basically two ways to do this:

1. Change the locale of your operating system
2. Change the locale manually in your wireless toolkit.

I have Windows Vista and I have not get the first way to work. There is a dialog called "Regional and Language Options". All the settings are set to Sweden/Swedish, but still the emulator does not change its locale. I have not found out what I am doing wrong. Fortunately the second option is fairly easy to perform.

First you have to find the emulator.properties file. In Sun's Wireless Toolkit this is found in C:\WTK2.5.2\j2mewtk_template\wtklib and in Sony Ericsson SDK it is found in C:\SonyEricsson\JavaME_SDK_CLDC\WTK2\wtklib.

Then you should search for this property:
microedition.locale

In my installation it locked like this:
microedition.locale: en-US

The code consists of two parts; the language code and the country code. These are separated by a dash ('-'). Notice that this is not as in Java SE, where it is separated by and underscore ('_'). The language codes are defined in ISO-639 and the country codes in ISO-3166. In my case I changed it to:
microedition.locale: sv-SE

All you have to do now is to save the file and restart the emulator. Notice that this does not change the locale of the emulator, it only changes what is returned by System.getProperty("microedition.locale"); In my current project we use this to load the correct resources. Thus we need to test how the different strings are looking in different languages and screen resolutions.

Öredev 2008: Sun SPOT, Buglabs, Sun Java ME SDK , Benefits of Open Source Development etc

The first day of Öredev 2008 is over. It has been an interesting day, with many new impressions. There are a lot of exciting things happening within the Java ME community right now. The Java ME platform is becoming available on a numerous platforms and in different flavors. I really liked the Sun SPOT device when it was announced at JavaOne 2006, and the BUG demonstration today was impressive. Both these devices triggers a real "must have now" feeling. If you ever had the opportunity to try out the Sun SPOT, you know what I mean.

Sun SPOT in action at the Waygroup stand. The robot is about to knock down the Jayway mug.

I must remind you all that Microlog works on Sun SPOT out-of-the-box, and has some special classes for Sun SPOT development. These classes are merged from the Microlog4SPOT project.

Another new attention-grabbing technology is the JavaFX framework. Before the presentation I did not have deep knowledge of what it was, but now I think that I have grasped the vital parts of JavaFX. It could be seen as a new Java platform that is put on top of the existing Java platform. It is kind of write once, run everywhere but with a new twist. Looking forward to try it out.

A tool I would like to try out is the new Sun Java ME SDK. It is available as an early access release today. According to the people from Sun the 1.0 release should be available in the beginning of 2009. The new Java ME SDK is a combination of the Sun Wireless Toolkit and the CDC Toolkit. It has been re-worked and uses the Netbeans framework as its foundation. The aim is to have a tool that is useful for all Java ME development. As such it has support for Blu-ray development.

There was also a session about LWUIT, the new UI Toolkit from Sun. It could be used as a better version of the LCDUI. It is inspired by the Swing toolkit, but for Java ME. Please take a look at my article about the LWUIT Makeover demo. I believe there will be reasons to watch out for LWUIT.

Here are some additional pictures from Öredev 2008:

A couple of minutes before the first keynote speech with Ted Neward from ThoughtWorks.

The official Microlog t-shirt. This is a limited edition only used by a couple of developers in the world.

All the mugs knocked out. Again we see the Sun SPOT in action.

A LEGO Mindstorm NXT waiting for some action.

Some advantages of Open Source Software in development.

Some more advantages of Open Source Software in development.

Using Eclipse MTJ for Java ME (J2ME) Development

A while ago I was experiencing pre-verification problems with EclipseME. Rather annoying I must say. I spent several useless hours before getting it right. This is when I decided to upgrade to Eclipse Mobile Tools for Java (MTJ), even though it has not reached v1.0.

Eclipse MTJ is the official Eclipse plugin for Java ME (J2ME) development. I was started several years ago, but did for some unknown reason never took off. On the other hand, EclipseME, developed by Craig Setera, was actively developed. I must say that I am impressed by the work Craig has done with EclipseME. Fortunately foundation did something about the situation with Eclipse MTJ; they started "from scratch" with the source code. They imported the EclipseME code into the Eclipse MTJ project, which replaced the old code.

You might wonder what are the reasons for using the Eclipse MTJ. First of all I have not had any problems with the pre-verification since I upgraded, which save me a lot of time. There are numerous bugs that has been removed, and the environment feels more stable. Another reason is that all of the Java ME specific menus is easier to access. For example; the Java ME project wizard is accessible at the same level a standard Java project. I believe that it is important to support great open source project like this. One of the best way to do so, is by using it and providing feedback.

For those of you that already have EclipseME installed I recommend the article "Converting to Eclipse Mobile Tools for Java". The rest of the bunch could use the same article, but skip the migration part.

Blog Post on Mobile & Embedded Community

I am proud and happy to announce that my blog post "Upgrading Voxtr with Microlog" has been featured on the Mobile and Embedded Community.

The Mobile and Embedded Community is a Java ME community for us developers. It consists of forums, blogs, some interesting podcasts etc. There is also a lot of open source projects. I regularly visit the forums and the blogs.

LWUIT Makeover demo

Ever since I heard about LWUIT for the first time, I have been following its progress. The LWUIT toolkit is an alternative to LCDUI. It is inspired by Swing, but is not a port of Swing. If you are looking for a port of Swing, take a look at JSR-209 "Advanced Graphics and User Interface Optional Package for J2ME Platform". I have not heard of any phone that implements JSR-209, but the SavaJE phone, which is not in production. But LWUIT is reality today. Since I consider myself as a fluent writer in Swing-lish, it was easy for me to get started with LWUIT. But I must admit that I have not done any real projects with LWUIT yet, but I have tried it out. It looks rather promising. Today I noticed a new LWUIT demo that was rather impressive.

What do you think about LWUIT?

Upgrading Voxtr with Microlog

What a sin! I am involved in the Voxtr open source project. The initial code was not made by me, so I found those awful System.out.println() statements. But fear no more; The Voxtr has been upgraded with Microlog.

I would like to take the opportunity to describe how simple it is to use Microlog. First of all you must download Microlog. Next up is to unzip the file that you downloaded. The included microlog.jar must be copied to your project and added to your buildpath. How this is done, depends on your development enviroment.

The second step is to setup Microlog. I prefer to use a properties file. The biggest advantage is that you do not need to change any code when you want to change your Microlog settings. Use the supplied file that is called microlog.properties. Copy this to the source root of your project or to your resource folder if you have one. To configure Microlog using the properties file you add the following code to your main class, which in most cases is the MIDlet class. The setup code looks like this:

Properties properties = new Properties();
log.configure(properties);

Microlog is now configured according to the settings in your microlog.properties file. In each class that you like to do some logging, you add the following code:

private final static Logger log = Logger.getLogger();

public void someMethod(){
// Do the actual logging
log.debug("MicroLog is working!");
}

That is it! Insert logging statements where you would normally put System.out.println() statements.

What good is all the logging if you do not know how to view the log? In this example, the logging is done in two destinations. The ConsoleAppender outputs to the same place all your System.out.println() would go. If you run your MIDlet in the emulator, the output is shown in some kind of console. In Eclipse, this is the "Console" view. The second output destination is the recordstore. To view it you use the RecordStoreLogViewer. Add the RecordStoreLogViewer MIDlet to the JAD file. When you have executed your main MIDlet, it is just a matter of switching to the RecordStoreLogViewer MIDlet. Select the "Load" item in the menu and the log is loaded on the screen. The image below shows the RecordStoreLogViewer with Voxtr log data.

What I have shown here is the setup that I recommend that you start with. The ConsoleAppender is good when using the emulator, and the RecordStoreAppender is good when executing on the target device. This is the default settings in the supplied microlog.properties file. When it is time to do field test, or similar, it is recommended that you start using one of the off-device appenders, for example the MMSAppender. The MMSAppender could be used to send MMS and/or e-mails to the addresses of your choice. Other choices are the Amazon S3 appenders which I have blogged about earlier. I will not go into more details about the off-device appenders right now, I will save it for later. Stay tuned!

Using Amazon S3 in a Different Way

You might have heard about Amazon S3, which stands for Amazon Simple Storage Service. Most people use it for backup. I will tell you a story about how I found a different way to use Amazon S3.

During the summer I felt a deep urge to implement a JDBCAppender for Microlog, like the JDBCAppender found in Log4j. In situations when the on-device logging is insufficient, this would give the developer a chance to log into a database. When searching the Internet I found less than a handful of JDBC implementations for Java ME with CLDC. Most implementation for Java ME devices was CDC compliant. Another problem was that I was to lazy to setup a database. Last but not least, my knowledge of JDBC was a little bit weak since I had not done any JDBC programming for many years. Soo my initial urge was gone like the wind.

But still I felt that there was a need for off-device logging in Microlog. How about Amazon S3? Could it work? Since Amazon S3 could be accessed with REST and/or SOAP, it should be possible to access it from Java ME. The developer resources for Amazon S3 are rather good, and it came as no suprise to find a J2ME Toolkit for Amazon S3. This was perfect for me since it was open source, and is using the Apache License 2.0. This is the same as we use for Microlog.

I coded two appenders for Amazon S3; the S3FileAppender and the S3BufferAppender. The S3FileAppender logs to file. When the file reaches a certain size and/or you log at a specified level, the file is copied to your S3 account. The S3BufferAppender logs to memory instead of a file. This is useful for applications that do not have access to JSR-75, i.e. file access.

But how do you use the S3 logging capabilities of Microlog? It is dead simple. The code look like this:

public S3FileLogMidlet() {
   S3FileAppender appender = new S3FileAppender();
   // You must set the accessKeyID & secretAccessKey in order for this to work.
   // For more information, see your Amazon account.
   appender.setAccesKeyID("accessKeyID");
   appender.setSecretAccessKey("secretAccessKey");
   log.addAppender(appender);
   log.setLogLevel(Level.DEBUG);
   log.info("Setup of log finished");

   log.error("This error message shall trigger file => S3.");
}

As you can see, you need to insert an access key id and a secret access key. These are obtained from the Amazon AWS pages. If you have ever bought something on Amazon, you already have an account. The only thing that you have to do is to active the AWS service. When you do this you could access these auto-generated codes. Copy and paste them into your code. A word of caution. Be aware that if you somehow loose your mobile device or your account details, you have to change your codes at Amazon AWS. Another solution would be that you enter these codes when starting your MIDlet or that you store them encrypted in a file. But do not say I did not warn you!

The rest of the code is simpe. The appender is added to the logger and the log level is set to DEBUG. The S3FileAppender is by default set to send the file to the S3 server when an ERROR or FATAL message is logged, or when the file is to big. But if you like to send the file only when the file is big this is possible as well. It should be noted that this setup could also be done in a properties file. Please take a look at the Microlog documentation for more details on the different setup options that are available.

When you have compiled and transferred your MIDlet to your device, the logs will be saved on your Amazon account. I use the Jungle Disk application to mount a virtual drive. The logging file will be accessible in your Microlog folder. It is as simple as that. The Jungle Disk application is available for $20 for the version that I use. There are nearly a zillion solutions for Amazon S3, and one of those will fit your purposes.

The benefits of using Amazon S3 for Microlog are many;

• No need to spend time on setup and maintenance of a database. This will save many $ for you.
• It is cheap to store the logs at Amazon S3. Even if you log huge amount of Microlog data, it will be very cheap. For example; let's say you store 1 GB of Microlog data. That would cost you $0.20 for the transfer and $ 0.15 if you save it on the server for a month. I believe that under normal circumstances you do not store it for that long.
• No need for JDBC knowledge. You only need to learn how to use Microlog.
• Focus on the development.

The only drawback is that the security could be an issue. However as explained, there are workarounds for this problem.

I would like so say some words about the future of S3 logging in Microlog. There is room for improvements. For example, I think it would be useful to log several users log files. As it is now, the S3 appenders are only for a single user. Of course there are other improvements, some of which I am unaware of. Maybe YOU are the one that could help me improve Microlog? Please use the Microlog forums if you have any suggestions.

Install MIDlet on a Motorola C380

Yesterday I had some problems when installing a MIDlet on a Motorola C380. Before doing this I believed that this was something I could do fast and easy. As it turned out, this was not the case. Here is the story.

As in all good cooking programs I had prepared myself. The document "Java ME Developer Guide for Motorola OS" seemed to be the right one. It describe the following ways of downloading a MIDlet to your mobile device;

1. OTA (Over The Air)
2. Bluetooth
3. IrDA
4. USB Cable

These are all standard ways of downloading a MIDlet. Using OTA for downloading from my laptop would imply to much works, so one of the other ways should be used in this case. Hmmm... Bluetooth should do the trick. Looking through all the menus, but no Bluetooth settings. The specification for the C380 confirmed this. IrDA was not possible either, since my laptop does not have an IrDA port. Lets try to use the USB cable then. Nice that Motorola devices uses a standard USB mini cable. My desktop is full of different brand specific USB cables. I wish that all manufacturers would use standard USB cables, which could simplify things for me.

I used the brute force method for USB connections. Attach the mobile device through USB to your computer, and see if Windows figures out which drivers to install. My Windows Vista installation did not. But I was a little bit surprised when Windows Vista suggested that I should download the Motorola Device Drivers. The link worked and within minutes the device drivers where downloaded.The documentation described a tool called MIDway which could be used for downloading MIDlets to your mobile. This was possible if you could find the "Java App Loader" in the Java menu on your mobile device. It was written that the "Java App Loader" is NOT available on devices that you buy from a standard consumer outlet. You should use the MWay tool found in Motorola MOTODev Studio for Java ME V2 instead. No problem, it was only a "small" download about the size of 112 MB. Estimated download time; 1 h 30 min. This gave me time to be a little bit social with my family. What a bummer :)

I installed the device drivers and Motorola MOTODev Studio. This worked like a charm. I attached my mobile device through USB and now it worked. The device manager showed that a Motorola US modem was installed, as well as some other devices. Now it was time to start MOTODev Studio. Surprise! The MOTODev Studio is Eclipse in disguise. Me like a lot! I found a document about Motorolas MWay Tool v1.0, which was the tool that I was supposed to use. The first step was to find the configuration tool, the second was to activate the "Java App Loader" menu. But wait... the other document stated that this was not available on mobile phone purchased in the consumer market. Appearently it was possible. After restarting the phone the menu was finally available. Connected the phone once more and used the deployment tool to install the MIDlet. Rather easy once you figured it out. But it took quite some time; I started right after the dinner at five and finished about eleven.

I now comes the short version, the version that you could use and save yourself a lot of time.

Prerequisites
Some kind of Windows environment. Windows Vista worked for me.

Preparations

1. Download the Motorola device drivers
2. Download the MOTODev Studio.
3. Optional; if you have a slow Internet connection you could take a long coffee break, watch a movie or something.

The real stuff

1. Install the device drivers
2. Install MOTODev Studio.
3. Connect your Motorola mobile phone. Wait for Windows to do the installation of the drivers.
4. Start MOTODev studio.
5. Open the "JavaME" view and select the "Tools" tab.
6. Select the "Config tool".
7. Refresh the "Config Tool" and you it should now show some information such as IMEI number etc.
8. Select the "JAL" option (short for "Java App Loader").
9. Disconnect your mobile device and restart it.
10. Choose the "Java Settings" menu found in the settings menu. Select the "Java App Loader". You are now prompted to connect your mobile device. The mobile device should confirm that your JAL link is active.
    
11. Select the "Deployment Tool". This is also found under the "Tools" tab.
12. Select the JAD file that you want to transfer. The JAR file shall be in the same directory.
13. Select the COM port for your Motorola USB modem. This is found Windows device manager.
14. Press the "Deploy" icon found in the upper right corner of the "Deployment Tool" view.
15. Accept the download on your mobile device. Follow the instructions on the mobile device.

You should now be executing your own MIDlet on your mobile device. I tried it on the Motorola C380, but this should be applicable on other Motorola devices as well. Good luck!

I hope that you could save an hour or two when using this guide. Unfortunately you have to download a couple of megabytes, but hopefully you have a faster Internet connection than I have. If you have any problems, you could still use the Motorolas MWay Tool v1.0 document to figure out how to do it.

Open Source Software Development; Microlog, Microinstall & Voxtr

A couple of years ago I started my first Open Source project; Microlog. This was an attempt to make something similar to Log4j. At that time I was new to Java ME programming. What I wanted was a really simple, but yet powerful logging tool. I started from scratch and within a couple of hours I did have something that I liked. For some reason it just felt right; I wanted to release it as Open Source. Said and done! I also showed it to some of my colleagues and got some feedback. My colleague Darius suggested that I would make the setup of Microlog very simple. Before I knew it, he had contributed with some code for the setup. After that he joined the project. Since I believe in "Release early, release often." I released a couple of small releases rather quickly.

During the years that have gone since then, I have from time to time taken a look at the Microlog project site. The statistics showed that there was a fair amount of downloads. But there was no activity in the forums. Nada, zero, null! :( Since I was not involved in any Java ME development project, there was no natural reason to use Microlog, nor updating the code.


But then there came an e-mail from a developer who wanted to contribute with some code. Wow! Somebody thinks that Microlog has some potential. A couple of days later another person wanted to contribute, and join the project. This was Karsten who now is our Maven specialist in the Microlog team. During the spring and the summer I and the rest of the team has been working very hard to get out the first "real release", i.e. V1.0. We also replaced our old static homepage with an autogenerated site by Maven. During this period we finally got some action in the forums :) Thank you all for the great feedback I have received, this is really motivating me to continue with Microlog.

I have heard many people complain about long URLs that you have to enter to download a MIDlet. Of course you can download the MIDlet to your computer, and then transfer it to your device. Both ways are rather tedious ways of doing the installation of a MIDlet. Therefore I started to think about different ways to distribute MIDlets. My experiments are now available for you to take a look at. Please visit the Microinstall project page site for more information.

I am the co-founder of the Voxtr project. This is a simple voice recorder MIDlet. Since I have a hard time to remember things, it is very practical for me to take "voice notes". No need to find a pen and paper or use that hard-to-use-notepad-application that is bundled on your mobile phone.

That is all for now folks!