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.

Microlog, Microlog4Android, SLF4J and Other Stuff

Right now a lot of interesting stuff are happening with both Microlog and Microlog4Android. I have been working with Microlog, while Jarle has been working on Microlog4Android (M4A). Let me start with Microlog.

I have started the work on Microlog V3.0. To start with I have been able to make the structure a little bit easier. For example I have removed some abstract classes, like the AbstractFileAppender. This was created for one purpose only, to be able to re-use parts of the file logging functionality between Microlog and M4A. A nice side effect of this construction is that we save some memory, both in terms of the memory footprint and run-time memory. Some bugs are fixed and there are some minor improvements.

Even though Microlog is my long time sweetheart, the most exciting things are happening within the M4A project. When moving the code from the Microlog to M4A, we skipped a lot of code. It was the core and only a few appenders that was moved. Working with the Android platform is quite different and the needs are a little bit different. For example, there is not really a need to log to the console. Instead we have replaced the ConsoleAppender with the LogCatAppender. This works as the built in log classes.  The reason for moving Microlog to the Android platform was to give Android developers more opportunities than the built in logging facilities. It is possible to use the logcat tool to log to file, but in that case you do not get the normal logcat logging in Eclipse. I have never heard of any way of logging to a file on the SD card or on the device, using the Android logging classes. With M4A it is possible to log to a file on the SD card. Just use the modified FileAppender to use M4A to log to file.

Another unique feature in Microlog is the ability to log to a remote server. This far we have the HTTPAppender which logs to a HTTP server. This is definitely something that is not possible with the standard Android logging facility. The HTTP logging is ideal for field test or similar, where the developers need to collect logs in a central place. No need to transfer log file manually. Note that during the development it might be more natural for individual developers to log to a file.

But that is not all! The most prominent addition is the SLF4J implementation. This gives you as a developer freedom to change the logging implementation whenever you feel like it. For example you want to use M4A during development for file logging, but want to remove the logging at deployment time. Just replace the M4A jar with the NOP implementation. If you want to revert back to good old Android LogCat logging (only), use the SLF4J implementation.

Last but not least, we have changed the PropertyConfigurator to read configuration files from an Android resource directory. The microlog.properties file could either be stored in the /res/raw or the /assets directory.

For those of you that want to try it out, it is available for download at: http://code.google.com/p/microlog4android/downloads/list
 
Please note that the latest release (V0.5) is rather experimental, but please try it out and give us feedback.

Starting the 3.0 development of Microlog?

What should it take to upgrade Microlog to 3.0? A while ago I release V2.3.4 of Microlog. There was only one "small" change, the Microlog instrument and instrument example modules were activated once more. They had not been part of any previous 2.X release. But was it a good decision to make only a patch release for such change? I must admit that I think this was an incorrect decision. The change was big enough to make a minor release or even a major release. What should I do to solve the situation right now?

I think the best solution would be to make a major release, that is that I should make a Microlog V3.0. This makes it possible to make some other changes that I wants to do. The changes that first comes to mind are these:

• Add the logging level NONE.
• Remove the Android module
• Remove the Amozon S3 module
• Cleanup the PropertyConfigurator
• ?

Some explanation might be in place. Adding the Level NONE gives the possibility to stop the logging without removing the logging from the code. This is sometimes used for production builds, with the possibility to enable logging after distribution. The feature has been asked for many times. To be honest I do not remember why this has not been implemented before.

Removing the Android module is for obvious reasons, since we have forked the Android parts this is no longer necessary to keep in the Microlog project. But is might not be obvious why to remove the Amazon S3 module. For me this was an experiment, but not something that turned out well. It is big and clumsy. A 3rd party library is used for the SOAP communication which also adds to the size. Fortunately it is kept in a separate jar. Thus only developers using the Amazon S3 modules are affected by this. Another drawback is that we need to maintain this module. I feel that I rather spend time on maintaining the core and other modules that are more important. But this is something that certainly is worth discussing. What do you think?

Cleaning up the PropertyConfigurator is something that I have wanted for a while now. When adding the hierarchical logging support in V2, I kept the original configuration possibilities. This is not wrong. However there are parts in the code that could be shared between the Microlog classic configuration and the new configuration. The parsing of attributes could be replaced by a separate StringTokenizer. All in all I think that the size of the configuration classes could be slimlined.

I guess that there are some more parts that could be improved and/or added to the list for Microlog V3. This was all that I could think of right now. Do you have any suggestions?

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?

R.I.P. Kenai - Microlog4Android has been Moved

I admit it. I was wrong. It is not business as usual for microlog4android. Yesterday I got an e-mail explaining that Kenai will be shutdown. But fortunately there are other hosting options. I wanted to move the project as fast as possible and have a simple solution. I was recommended by my esteemed colleague Hugo about using Google Code together with GitHub. Google Code allows a project to use other service, such as GitHub, when Google Code  is not sufficient enough. Moving the source code was rather simple. The part that took time was to generate a new SSH key for my new computer. The nice thing with git is that all the history is preserved.

To move the source code from the Kenai git repository I did the following:

git pull git://kenai.com/microlog4android~source-code-repository

git remote add git@github.com:johanlkarlsson/microlog4android.git

git push origin master


It was as simple as that. The first line was needed to pull the source code out from Kenai, since I had no backup copy on my new computer. So for a user with the code on his computer, it would be even simpler.

Right now it is time for me to relax a little. I know I have a lot of things to do tomorrow at work. Please stay tuned for more updates about microlog4android.

The project:
http://code.google.com/p/microlog4android/

The source code:
http://github.com/johanlkarlsson/microlog4android

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.