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?

Ö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.

Improving your Java Source Code with Open Source Code Analysis Tools; FindBugs, Lint4j & CheckStyle

One of the best way to improve your own code is by looking at other peoples code. Another way to be a world class programmer is to use a source code analysis tool, like FindBugs, Lint4j, CheckStyle. Here is a short & compendious summary of these tools.

FindBugs

This is my favorite source code analyzer, simply because it tends to find the most horribly, awful bugs. FindBugs is based on the concept of bug patterns. A bug pattern is a pattern in your code that implies a bug. The FindBugs tool is initially developed at The University of Maryland. According to Professor William Pugh, "Students are good bug generators". As such many of the students mistakes has generated a new bug detector implementation. One might think that these are mistakes only made by beginners, but as it turns out many of these problems are also part of production code. For example, the FindBugs tool was used on the Sun JDK and it found some serious bugs.

The FindBugs tool is available as a stand-alone GUI, Ant, Eclipse and Maven plugins. During development I prefer to use a plugin in my IDE, which in my case is Eclipse. The source code analyzer should also be a part of the build process.

For all the newcomers to Eclipse, this is how you install the FindBugs plugin from the update site:

1. Select menu "Help" -> "Software Updates" -> "Find and Install..."
2. Select "Search for new features to install" and press the "Next" button.
3. Press the "New Remote Site..." button.
4. Enter your name for the update site, for example "FindBugs Update Site", and enter the following into the URL field: http://findbugs.cs.umd.edu/eclipse
   Press the "OK" button
5. Press the "Finish" button. Eclipse will now contact the update site and check for the latest version.
6. After a while you will get a list with the features that are available to you. Press the "Next" button until you get to the "Install" page. Press the "Finish" button.
   
7. When you get to the "Verification" page, press the "Install" button.
8. Eclipse will now run the "Update Manager" and download the plugin.
9. When everything is finished, you will be prompted to restart Eclipse. Please press "Yes" and Eclipse will be restarted.

When you have installed it, you will have an extra context menu like this;


Select this menu and within seconds you will have a list of potential problems in your code. These are all gathered together with the compiler warnings. When you click on a warning, your code will be displayed with a bug:


Double-click on the bug and you get an explanation on what the warning really means:


Now you could start figuring out what to do with the warnings. Hopefully FindBugs has found some bugs for you.

Here is where you find more information about FindBugs:

• FindBugs homepage
  
• The FindBugs Eclipse update site
  
• FindBugs Blog

CheckStyle

As the name implies, CheckStyle check the style of code. For example, it can check if you follow the Sun Java Code Convention. But CheckStyle can find more than this. It contains a multitude of rules that are considered bad programming practices. Some are very common, and others are a little bit more doubtful. In other words CheckStyle is not really in the same category as FindBugs, but I find it a tool that is worth having in your Java programmer toolbox. Installation of the CheckStyle Eclipse plugin is made the same way as with FindBugs, but you use another link (found below).

Here is where you find more information about CheckStyle:

• CheckStyle homepage
• The Eclipse CheckStyle plugin (that I use)

Lint4j

The Lint4j tool is a tool that is similar to the famous lint tool for the C programming language. I have not used it very much, but it have found some code that smelled badly. When I have used it for a while I will communicate my opinions to you.

Here is where you find more information about Lint4j:

• Lint4j
  

Some Final Words

Here are some final words of advice

• Use it from the start of your project. Otherwise you could be overwhelmed by the enormous pile of things that you should correct.
• Do not use full checking from the beginning, start by using the default settings. When you have checked your code you could add the checks that you find useful.
• Do not check in your code without running your source code analyzer.
  
• Add code checking as part of your continuous build process. Your build should not fail when it detects some problem(s). The reports could be used to ensure that nobody check in code that is bad.
  
• Use common sense, you should not obey the tool relentlessly without questioning. The FindBugs tools is the most effective, but sometime it indicates things that are not really a bug. Use the filtering capabilities found in the tools to filter out what is not relevant. This let you focus on the real bugs.
  
• A source code analysis tool should not replace other good practices like unit testing and code reviews. These are all complementary tools to make your code close to perfect, and avoid those nasty bugs.
  

I hope these tips will help you to improve your code, and will make you a better programmer.

Happy bug hunting!

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.

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!