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?

Synchronizing iPhone 4 with Google without iTunes

Today I received a brand new iPhone 4. Life was joyful. However it gave me some frustrating moments before I could use it for real. Here is the true story what happened when I got my iPhone 4.

I had prepared the migration by backing up my contacts from my HTC Hero. The HTC had no way to export contacts to a SIM card, but only to SD card. Strangely enough it was possible to import contacts from a SIM card. Anyway I did not consider this to be a big problem, since exporting to the SD card should work fine.The contacts was saved as a VCF file. This was easily imported by double-clicking on the file. When this was done, all the google contacts was on my Mac Book. After I started and initialized the iPhone, it was connected via a USB cable to the Mac Book. Consequently iTunes was started with a wizard. One of the steps was the sync setup. By default all contacts was to be synced. Perfect! This was exactly what I wanted. A couple of more steps and I pressed the “Sync”-button.

After a short while something really odd happened. A warning message saying that no synchronization of contacts was not possible, since the phone was not connected. What! The phone was connected. Not good! I discovered a button labeled “Restore”. The help text explained that this should be used when in trouble. I felt like being in trouble and hit the restore button. The process was really fast, but enough time to get some tea. Then the same procedure once more. Still the same problem. Next try; search the Internet. I found out that I was not alone with this problem. I tried out all of the different solutions explained in the forum. Do not know how many times I cleared the sync settings, restarted the phone, re-booted the computer and all other kinds of tricks. The Apple support pages did not contain any other suggestions than found in the forum. Now I was really frustrated. I should not be that complicated to get your contacts into your new phone. Time to get a break. Get your brain to think in a different way. Reset the brain. Get some food.

Several hours later it was time to try a new approach. I googled “Sync iPhone Google”. I found an article called “Google Sync: Set Up Your Apple Device for Google Sync“. It seemed to be exactly what I was looking for. The article explained how to use add an account in the iPhone to synchronize mail, contacts and calendar. In fact it was a Microsoft Exchange account. It took me less than 5 minutes to have mail, contacts and the calendar in sync.

The final solution was much simpler than copying contacts via the computer. The intent was to only transfer the contacts and then set up a mail account on the phone. Now I get an all-in-one solution,  with mail, contacts and calendar synchronization. Now my life is joyful again.

The Öredev Developer Conference 2010

Each year since its inception, I have attended the Öredev developer conference. What makes it special is that it is a combined conference, with not only Java. This year it is especially important for me, since I can learn about both Android and iPhone development.

I will attend this year. Will you?

Do not forget to register at the Öredev site.

Microlog4Android V1.0 Released

Finally! After many months of struggling with Microlog4Android, the first official release is here. The core is the original Microlog code, but it is re-written to take full use Java SE features. For example, no Vectors are used. This means that the logging is faster than it was in Java ME. One important addition is the support for SLF4J. This should make it easy to migrate if necessary. This might also be an addition to future versions of Microlog. This way it should be easy to share code between Java ME and Android. The most important appenders are there as well.

Please download it from here. As always, any feedback and comments are welcome.

My World is Changing; Android & iPhone Development

I have been working with Android development for quite a while now. So I decided to do something quite different; iPhone development.

It is like groping in the dark. After many years with Java and garbage collection, it feels a little awkward to manage your memory by yourself. The first encounter with garbage collection in Java was really awesome. After a couple of years as a Java developer, you realized that the garbage collector is not the answer to all of your memory problems. But still, you are not forced to think about memory management on a daily basis. All of a sudden you need to think about memory management on a more regular basis.

Eclipse has been the main tool in my Java toolbox for many years now. One might argue that IntelliJ or NetBeans is a better tool, but I have used Eclipse. Switching from Eclipse to Xcode is not easy. I miss the fabulous re-factoring support in Eclipse. There are many other small issues, but I am slowly and constantly learning new keyboard shortcuts in Xcode. I guess that I could be a better Xcoder in a while. The interface builder in Xcode is an invaluable tool. It is very easy to get nice looking iPhone UIs. It is very nice not having to worry about getting your XML files right. Making a good looking UI on Android can be frustrating and cumbersome. Of course you can get nice UIs on Android, but I find it easier to create one on iPhone.

Last but not least, the markets are a little bit different. Android market is open. Appstore is a little bit more closed. There is no quality control when submitting to Android market. As a consequence there is a lot of really bad Android applications. It is hard to find what you are searching for on Android market. The search seems to be case sensitive. Not good. Usually I install applications that is recommended somewhere. In most cases, there is a QR code available that I scan with the Android barcode reader. Really nifty application that makes installation on Android simple. The applications in Appstore is controlled by Apple and it seems that they are of better quality than Android applications. It must be pointed out that there are many high quality Android applications, but they are harder to find. As a developer in Sweden it is not possible to get paid for your Android applications, but you can get paid for your iPhone apps. When will this problem be solved?

Another thing that seems to be missing in the iPhone world is open source projects. The Java and Android world is full of open source. However there seems to be good hope for the iPhone world. I found this this list of open source applications for iPhone.

Of course there are many more differences. These are the most apparent differences from my perspective. At the end of the day I am a mobile software developer. Switching to iPhone gives me a new perspective of my world. I think that is a good thing.

Printing Stuff from an Android Phone with PrinterShare

I am always on the quest to find nice applications for my Android. There are many not so good applications on Android Market. Many applications are fun for a couple of minutes, but not so useful. Today I found one that I liked. I do not know if I am going to use it a lot, but the concept is simple and yet powerful. I am talking about the PrinterShare application.

The PrinterShare application is used for printing from your Android application. You could print pictures, web pages, contacts, messages, e-mail etc. The PrinterShare is also added to the share menu. You have two ways of printing your stuff; either using a nearby printer or a remote printer. A nearby printer is found using a Wifi access point. To use a remote printer you need to install an application on your computer and register yourself at the PrinterShare site. Let us see when I tried out the PrinterShare application.

Finding a nearby printer was very easy. My printer is connected to my Synology DS110j, which has support for the Bonjour protocol. Since the PrinterShare application also has support for Bonjour they found each other without any problems. But I was a little bit disappointed when I only could print a test page. To print using a nearby printer you need to buy the pro version of the PrinterShare application. The real bad thing here is that paid applications are not available here in Sweden. But luckily enough it seems to be possible to buy a key using PayPal. The price is a modest $4.95.

 Finding my nearby printer.

Since I was curious to try the application out, I registered myself at the site. The registration was simple.  I entered my e-mail address, in return I got an e-mail with an auto generated user id and password. A couple of minutes later I had managed to print a picture that I found in my phone. Nice and easy.

Beside the setback with using the local printer solution, I was impressed how simple it was to get everything to work. It is applications like this that is nice to have installed on your Android phone. I am not sure if this is an application that I am going to use very often, but it is rather cool. If I am going to use it extensively, I think it would be worth paying $4.95.

What is your favorite Android application? Is there any Android application that you could not live without?

Back at Home :)

I am finally back from my vacation. Last week I was in Egypt with my family. They had an Internet café in the reception of the hotel, but it did only work one time when I was there. But I guess it was a good thing to be offline for some time. At least my family appreciated it. Prior to that I was in Istanbul. Turkey. This was a trip together with my colleges. I learned a lot of new things about the Android platform. The most interesting thing was to try out Robotium, a testing framework for Android. It is built around the existing testing framework found in Android, but it is much simpler. If you want to know more, please read this excellent article.

That is all for now. Nice to be back at home with a working Internet connection.

Reading Properties Files on Android (Investigation for microlog4android)

Today I have investigated the possibilities to read properties files on Android. In microlog4android there is no configuration possibilities via file as it is today. The microlog4android development team feels that we need to re-write the configuration from scratch. There are many reasons for this decision, for example there is the Properties class available on Android while in Java ME we use microproperties. These are my findings about properties files on Android.

My first thought was to use the SharedPreferences class. My brain picked up this idea while using the SharedPreferences in another project. The SharedPreferences is used to read/write preferences for an Android application. The preferences are stored in an xml file that is put in the private directory structure of an application. You could edit the file by pulling it from the device or emulator using adb pull. After editing it you push it back using the adb push command. If you are using the Android Eclipse plugin you could use the file browser to do the same trick. But this is cumbersome to pull/edit/push the file and I do not really like to use XML for storing properties.

But how do we do it in microlog? The properties are stored in a properties file that is put in the JAR or by setting properties in the JAD file. Both are easily edited in Eclipse without no need to pull/push the file. The same goes for NetBeans. The properties file is bundled with the jar. Why not do the same on Android? Time to Google again! I found out that there was primarily two ways of doing this:

1. Using the AssetManager
2. Reading a raw resource

To test this I created a simple Android project in Eclipse and copied two microlog properties files. One was put in the /assets directory while the other was put in the /res/raw directory. The first thing that happened was that Eclipse complained about the naming of micrologV2.properties that was put in the /res/raw directory. It was kind enough to inform me that only [0..9][a..z] was allowed. Changing the capital V to a lower case v was simple. Now time to do some coding. The code for reading using the AssetManager looked like this:

Resources resources = this.getResources();
AssetManager assetManager = resources.getAssets();

// Read from the /assets directory
try {
    InputStream inputStream = assetManager.open("microlog.properties");
    Properties properties = new Properties();
    properties.load(inputStream);
    System.out.println("The properties are now loaded");
    System.out.println("properties: " + properties);
} catch (IOException e) {
    System.err.println("Failed to open microlog property file");
    e.printStackTrace();
}

The code is dead simple and thank God for the Properties class, although microproperties would do the trick. The second way to do it is as simple as the first approach. The code looks like this:

// Read from the /res/raw directory
try {
    InputStream rawResource = resources.openRawResource(R.raw.micrologv2);
    Properties properties = new Properties();
    properties.load(rawResource);
    System.out.println("The properties are now loaded");
    System.out.println("properties: " + properties);
} catch (NotFoundException e) {
    System.err.println("Did not find raw resource: "+e);
} catch (IOException e) {
    System.err.println("Failed to open microlog property file");
}

Notice that I omitted the code for getting the resources, since this was part of the first example. Both ways seems to be good. But what to choose? Using approach 1) has the following advantages from a microlog4android perspective:

1. You are not limited to name your file with lower case letters only.
2. It is possible to use a default file name if the user does not specify one.

But I probably will implement both solutions, since this gives the user a freedom to choose where to put the file. What do you think? Is there any other solutions that I have missed out?

The Future of Kenai?

As I wrote in an earlier article, the Android part of Microlog has been forked into a new project. The project is hosted on Project Kenai beta. This is Suns offering for open source project. With Oracles acquisition of Sun this project seems to be endangered.  But I am not sure how it will be affected. If it is going to be changed, I sure hope that the projects will get support for the migration if any. For more information, read the article about the subject on Kenai's blog.

I guess we have to continue with business as usual for microlog4android.

Newsflash! Microlog for Android - microlog4android

As you might know, Microlog has support for logging on the Android platform. However it has been living a rather discrete life in the shadow of the rest of Microlog. The other day I chatted with one of the other Microlog developers (Jarle) and we decided that it was suitable to create a new project for Microlog support on Android. We aim to re-use the Microlog core, but to optimize and such for the Android platform.

But why should I care? Android already has built in logging support that works rather well. I think that there are a couple of reasons for using Microlog on Android:

• Log4j API
• Resource effective
  
• Remote logging
  

Many people are used to the Log4j API when it comes to logging and prefer it over the Java logging API (which is used on Android). I have spoken to several users of Microlog and they have praised that it uses the Log4j API.

The Microlog has been built from scratch. It has been designed to be used on devices with a small amount of memory and with reduced processor capacity. Log4j on the other hand contains a lot of legacy code and has been used on computer with many times the capacity of an embedded device. For example Log4j contains a lot of classes that are there for being backward compatible with older releases.

The Microlog library has support for logging to remote servers and devices. This is not something that is built into the logging API found on Android. Remote logging is something that is very appreciated in Microlog. My guess is that it would be nice for Android developers as well.

As mentioned before, the project was registered a couple of days ago. Notice that we are in the startup phase and no release is available yet. We decided to use Kenai.com, since SourceForge does not meet our expectations. The project is called microlog4android. As always; any contributions are very welcome. Please contact me if you are interested in the project.

It would be interesting to know what you think of this idea. Is this something that is missing on the Android platform? Or is the built in logging enough for you?

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?

Öredev Reflections

I have just finished 3 intense day at the Öredev conference here in Malmö. As always I have a lot of thoughts, ideas and inspiration after attending a conference. These are my reflections from the conference:

• I was missing a sessions about Android. Everybody is talking about the Android platform, but I wonder how many developers are actually developing for Android. It would be interesting to hear about some real Android projects. But maybe next year we will have some Android sessions?
  
• I was surprised by the session "Design to Development- Collaborating and Communicating Interaction Design". I have never heard of Theresa Neil before. She has some really good ideas. It was about communication between developers and interaction designers. This is something that I could relate to.
  
• My friend and colleague Davor had an interesting presentation called "Snow white and the seven dwarfs". It is a true about Davor (Snow White) and his team of developers (the dwarfs). He introduces the concept of Developers Exploratory Testing (DET), which is a way to do continuous testing in an agile project. The James Bach really liked the way how Davor has taken some ideas by James Bach and evolved them even further. Note: I am one of the dwarfs.
  
• Maven 3.x has some genuinely interesting news. The thing that I would like to try out the most is the new Maven console. I hope that it will help me to do faster builds.
  
• The keynote by Scott Hanselman was interesting. He gave some nice hands on tip for improving your efficiency as a developer.
  
• I have been registered as a Twitter user for some time now. Never used it much for anything other than Microlog news. During the conference I twittered a lot. I used the "I Tweet" Android client. Now it feels like I am hooked on Twitter. The Tweets was displayed on large screens all over the place, so it became very popular for many attendees. In fact tweets about #oredev was on the top list for Scandinavia.
• I attended a session by Neil Ford that was interesting. He is the author of "The Productive Programmer", a book that I recently read. As the name implies it is all about productivity for programmers.
  
• Some interesting stuff going around with the Java app store. I have always wondered why Java desktop applications are so underrated. I hope that Java desktop apps will get more popular.
  
• Ze Frank is very funny. He has a lot of very interesting social experiments going on and some unusual games.
  
• I liked the sauna and dinner on Monday. Did meet some interesting people there like Marc Lesser and Chris Hughes. The Swedish pickled herring on a toast was superb. The main course was Swedish fish, not candy kind, but a codfish.
• In general a very good conference. Of course I am a little bit biased since my company is one of the founders of Öredev.
  

That is all that I could remember right now. I guess that I have missed something out. Here are some pictures from the conference:


Marc Lesser about "Doing Less"

Terrence Barr about Java and Open Source


Theresa Neil about Interaction Designers and their interaction with software developers and vice versa.


Davor speaking about "Snow white and the seven dwarfs".


The Öredev Twitter feed. Notice the comments about Davor's presentation.

The No SQL presentation. To the left Emil Eifrem, Adam Skogman to the right. Notice their new definition of NO SQL.

The multi talented Ze Frank was very funny.

An air safety instruction. Notice the wizard to the right.

Chris Hughes about the secrets of the iPhone. Chris is a very cool geek, just the way a geek should be according to me.
Looking for some bugs?


Scott Hanselman and his keynote.

Android, Android, Android and Some More Android

Android is getting a lot of attention right now, both from me and a lot of other people. Recently I attended a breakfast seminar about business opportunities with Android. The author of the book "The Busy Coder's Guide to Android Development", Mark Murphy, gave an interesting presentation on the subject. After a brief technical introduction, Mark spoke about the business opportunities. As I gathered, he mostly used the classical open source business opportunities, more or less. Nevertheless the presentation was good. The most interesting part of the breakfast seminar was actually the fact that it was really crowded. I would guess that there was around 200-300 people there, which is very much for a breakfast seminar i Malmö. I meet a lot of old colleagues and all was very positive about Android.

I have just attended the "Advanced Android" course by WayEducation. It was really good and gave insight into the inner workings of the Android platform. I am looking forward to start programming Android for real, in a real project. But that is just around the corner, since it is part of our product backlog.



Last but not least I have ported some parts of Microlog to work on Android. The core is the same for Java ME and Android, but opening a file or a network connection is different. On the other hand writing the actual data is done the same way, e.g. to an OutputStream. This shows that even though Android not officially is Java, we could re-use Java code.

It will be interesting to follow what happens with Android, the platform, the community and the phones. Only time will tell.

What are you opinions/experiences with Android?

Microlog & Microproperties Updates

This weekend I decided to start the replacement of the old Microlog configuration with the new one; Microproperties. Ironically this work was to copy the file reading part from Microlog to Microproperties. When this was done and tested, I decided to do a new Microproperties release. This is the new V0.2.0 release. When this was done I added Microproperties V0.2.0 to Microlog.

However this weekend is approaching its end and I decided to do the first snapshot release of V2.0.0, before continuing my work. The Android extension is included in this release. My hope is that developers who prefer the Log4j API will find Microlog for Android an interesting alternative. Please download and try it out!

Using Microlog for File Logging on Android and Viewing Files on Android Emulator

My goal yesterday was to re-factor the FileConnectionAppender in Microlog. I wanted to separate the logging part from the actual file writing. The logging should be in an abstract super class, while the file writing should be in the the concrete class. The purpose of this exercise would of course to be to support file logging on both Java ME and Android platform.

It took some time to create a good structure in the new AbstractFileAppender and the FileConnectionAppender. When this was done, it was a piece of cake to create the FileAppender (for Android). I used the Eclipse class wizard to create a sub-class to AbstractFileAppender. Most of the time was spent browsing the Internet and looking in the Android documentation. Then it was a matter of implementing a handful of methods. I had never tested to create and write to a file on Android before, but I was curious and executed the code directly when most of the methods was finished. This excluded the flush() method for example. The diagram below shows the new class structure.



The next step was to figure where to find the log file. It was not long time before I found a file with a .img extension. From some documents found on the Internet, I could gather that this was a disk image. But how do I read the data found in the disk image? As it turns out there is several ways to do this:

1. Use the command line tool called adb
2. Use the file browser found in Android DDMS (Dalvik Debug Monitor System)
3. Use the file browser that is part of the Android plug-in for Eclipse.

I will show the 2nd way. If you manage this, you will almost certain be able to the 3rd way. All those shell lovers will have to take a look at the documentation for adb.

You start by typing ddms in your shell window or command prompt, depending on your operating system. This will bring up the DDMS tool. Select the device and use the Device->File Explorer... menu to access the file explorer, see picture below. You could now browse the file system in your Android emulator. In our case we browse to /data/data/net.sf.microlog.android.example/files. This is where you will find the file microlog.txt. If you wish to see the content of the file, which I gather that you do, you press the button marked yellow below. This will pull the file out of the Android file system to your file system. You get the chance to select where you want to save. Pick up your favorite text editor to view the marvelous content of your log file.




It is as easy as this to view a file on the Android file system. I hope you found this tip helpful.

Microlog4Android

I have continued with the re-factoring of Microlog. Tonight my plan was to re-arrange the package structure to separate the Microlog core from the rest of the code. One reason for this was to make it easier to make different flavors of Microlog. The Microlog core should be possible to execute on CLDC. The plan was to move the MIDP specific classes to its own package structure. One new flavor that I had in mind was the Android flavor of Microlog. Many people have asked me about Microlog on Android. My answer has always been something like "It should work on Android, at least the core.".

After the re-factoring it was time to prove my point, that it is possible to execute Microlog on Android. And it did! The setup was simple, it was Microlog with a ConsoleAppender and a SimpleFormatter. Not so very much at the moment, but I think it is a good starting point.

During the process I learnt that it was in fact possible to see the System.out.println() statements. Many people claim that it is not possible to see the System.out.println() in the Console. That is true, but it is possible to get hold of the prints. The trick is to show the "LogCat" view. This is activated this way:

1. Select "Window->Show View->Other..."
2. Open up the Android category and select "LogCat"

You can now see the output from System.out.println() and System.err.println(). A nice side effect is that you now can see your Microlog statements as well!

One might ask why should I use Microlog on Android, since there already is a logging API available. This is a perfectly legitimate question. The reason would be that Microlog brings a Log4j like API to the Android platform, but the supplied API is the java.util.logging package. I have always preferred the Log4j API, which was the reason why I choose it for Microlog in the first place. But I guess that you could use Log4j on Android, but Microlog is designed for constrained devices, which Log4j was not.

Öredev 2008: Android, Blackberry & Clean Code

The last day of Öredev 2008 started with a keynote by Robert C Martin (the picture above). It feels hard for me to reproduce the content of the keynote. His session about "Clean Code" was a little bit more tangible. He showed an example on how to simplify a method, and decompose into several small methods. The final example was very, very simple. The session gave me a new perspective on how to write good code. Maybe it is time to clean up some of my code?

I have never tried to develop for a BlackBerry device. The primary reason is that BlackBerry devices are not very common here in Sweden. Anyhow I thought it would be interesting to know a little bit more about the BlackBerry development. One thing that impressed me was that how Java friendly the device is. Every "native" application is written in Java. As a consequence all the APIs are written in Java. If you were to develop a Java application for a Symbian device you would be limited when writing your application in Java ME, since not all the APIs are reachable from Java. On many mobile devices the Java applications are hidden somewhere deep inside some strange folder. This means that your Java ME applications are some kind of "second class citizen". On a BlackBerry on the other hand, the Java ME applications that you write is as important as the pre-loaded applications. Really nice! If there is a new feature, like GPS, it is immediately available for you as a developer. That is not the case when developing for a lot of other mobile devices. The development environment seems to be pretty mature, including such stuff as memory statistics and a profiler.

A new kid on the block in Java world is the Android Open Source platform. For those of you that have not heard of it; it is a new mobile platform. It is developed by the Open Handset Alliance, which consists of many mobile operators, mobile manufacturers and software companies. The most famous company of this bunch is probably Google Inc. As mentioned it is Open Source, which gives a lot of new possibilities. For example, it could be possible to port it to any kind of embedded device. The Android platform is based on a Linux kernel. On top of that we have a Dalvik VM. You develop your application in Java and compiles to a Dalvik executable. Although it is not considered as Java by definition, you as a Java developer hardly notice any difference. The API is based in Java v1.5, with some unwanted APIs removed. As of today there are not many Android devices available, but inevitably there will be some more devices real soon. The Androiod platform seems to be targeted at the smartphone segment.

Before the last session it was time to attend a lottery draw. To be a part of the lottery you would have to solve a developer scrabble, which I did. Believe it or not, I won a brand new Eee PC 901. A real nice piece of equipment, although I have not tried it extensively. I guess it is nice to have when you are on the road.

Here are the rest of the photos from day 3 at Öredev 2008:

The Android session was pretty cool.

This shows how wrong it can get when a critical application fails. From the presentation by Kevlin Henney.

Kevlin Henney in action.