First, the tool to use is commons codec package from Apache. The documentation can be found here. The source is available here. You can just include the source of the package to your project, it is all Android compatible.

The commons codec package has also convenient method for Base64 decoding,
String imageString = "";
try {
  FileInputStream fin = openFileInput("camera.jpg");
  int jpeg_size = fin.available();
  byte[] imagedata = new byte[jpeg_size];
  fin.read(imagedata);
  byte[] encodedData = Base64.encodeBase64(imagedata);
  imageString = new String(encodedData);
  final String mimetype = "text/html";
  final String encoding = "UTF-8";
  // replace below [ with html "<" and ] similarly ] with ">"
  String html = "[html][body][center][img height=\"200\" width=\"200\"
         src=\"data:image/jpeg;base64,"+imageString+"\"/][/center][/body][/html]";
  mWebView.loadData(html, mimetype, encoding);
} catch (Exception e) {
  e.printStackTrace();
}

There is also convenient Base64 decoding functionality in the package, which can be used for example, to decode Base64 encoded content in MIME messages, which were covered in previous post.

A small explanation on usage follows: First, let’s parse the top-level header to get boundary token:

MimeHeadersFactory headFactory = new MimeHeadersFactory();
MimeParser mp = new MimeParser(bin,headFactory);
byte [] boundary = null;

try {
  MimeHeaders mh = (MimeHeaders)mp.parse();
  Enumeration e = mh.enumerateHeaders();
  while(e.hasMoreElements()){
    String key = e.nextElement().toString();
    // get the boundary, which separates parts in multipart
    if(key.equalsIgnoreCase("content-type")){
    MimeType MT = new MimeType(mh.getValue(key));
    if(MT.equiv(MimeType.MULTIPART_RELATED)){
      boundary = MT.getParameterValue("boundary").getBytes();
    }
  }
}
}catch (Exception e){
  e.printStackTrace();
}

Then, let’s go through all body parts

MultipartInputStream mIS = new MultipartInputStream(mp.getInputStream(), boundary);
try {
  while(mIS.nextInputStream()){
    if (mIS.available()>0){
    // create parser for each part in multipart
    MimeParser partParser = new MimeParser(mIS, headFactory);
    MimeHeaders mh = (MimeHeaders)partParser.parse();
    Enumeration e = mh.enumerateHeaders();
    while(e.hasMoreElements()){
    // do something
    }
  }
}

The above should do the trick – enjoy!

Then, the really cool stuff was to install the Maemo Mapper application. One motivation for this post was to link to a right page, where you can just install with a single click. The initial attempts to use tablet’s own application manager failed because of missing libraries , but once the mentioned page was found it was straightforward.

Maemo Mapper uses raster maps from Open Street Map. Some writings mentioned this to work well for walking and biking use. Purely vector based maps were recommended for car use where maps need to be updated more frequently.

Despite having 400*4 radios above your head, they promised that your brain should not be boiling while in the room. The black hats in the picture were an interesting detail, they cover the nodes from water leaks from pipelines or from fire extinguishers, and they have proven to be useful.

The first experiences were all positive, and Antenna tasks were straightforward to set up by following the tutorial. However, be warned, the emulator does not correctly implement the HTTP(S) Connection as defined in JSR-118 MIDP API. Even the HTTPConnection of J2ME should not do automatic redirects, running our code did some redirecting on Microemulator. This may not be major issue for simple development, but forced us to continue development on Linux using SUN’s WTK where the HTTP connections worked as expected.

Thanks for many comments.We begin our observations on measuring the write performance by Nokia N800 on its Flash storage device. The data is written and read on blocks of 512 bytes, to achieve good performance. This time I decided to use standard Linux tools for the benchmarking. 

So, the first observation is that we achieve write performance close to 1Mbit/s for small (less than 1 MB) files. In the write performance test the Linux command dd was used to copy files from /dev/urandom to a destination file in the Flash storage. The operation was timed by using /usr/bin/time, since the default dd command on N800 did not provide timing statistics.

The above figure shows the read performance from the N800 Internet tablet. For the read test I used dd to transfer data from a file on the Flash storage to /dev/null. Now we can see that the read bandwidth is in the order of 250 Mbit/s.So what can we conclude from the graphs. We are looking on just a single device, and especially a mobile device where the processing power of the device may prevent us from achieving the highest performance provided by the Flash storage. So the results are not very generic. Also, the read performance is much better than for writing and is certainly enough to play movies. The write performance instead, is poor and would not allow the user to receive large files with the full bandwidth achievable by the device’s WLAN.For now, this should be it for the N800 benchmarking, since we have already the great new N810 at hand.

To flash the OS on Intel based MacBook, you can still use the old flasher application available here. Then you should follow the N810 instructions form here. With one exception, there is a trick on the order of doing the stuff. First, connect the USB. At this point, change execution rights for the flasher, enter the command to start the flasher as sudo (either sudo su, or do something as sudo, so that you won’t need to stop to type the password later when there is only seconds of time to act). Now, enter the command and be ready to hit the “Enter” (but do not hit it yet). Now plug the power cable to start the N810, and when you will see the USB logo in the N810 hit the enter. You see the flasher to complete and you are done – have fun!

The evolution from N770 to N810 via N800 illustrates nicely how to make a consumer product.

However, the manufacturer has still something to improve. Trying to start the Skype application resulted in information which leas to firmware update (some Hildon framework libs are not anymore compatible with the latest Skype.). This kind of “need to do some hacking” stuff should not appear when you pull out your new shiny device from the nicely finished box.

And final notes: My PSU (thermaltake 420W) blew up during the Christmas holiday, and I am waiting for the replacement to arrive. After, the benchmarks on Flash performance will be published. This time I used real *nix kin of methods (/usr/bin/time, /dd, and like) to do the measurements. Let’s get back…

So, the comparison does not measure only storage performance, but also Java. Anyways, storage performance counts often only when some application is using the storage, and this application might as well be written on Java. In the tests, each size of file was created consecutively 10 times and average was calculated. For file size of 0 kB I measured only time to create an empty file. So here we go with the results:

Update: After seeing a post referring to my benchmark, I felt urgent need to look into an independent benchmark and see whether I had been writing nonsense or not. Using my home desktop and connecting via a WLAN router I copied several files of different sizes (100kB to 1MB as in the above benchmark) by using secure copy over ssh. Now, the average bandwidth of 10 transfers was 278 KB/s. From this, we can calculate copy time of 1.84 s for 512KB file and 3.68 s for a file of 1 MB. These figures have very similar order of magnitude than my earlier measurements with mobile Java.

Today, the tests only included local file creation but there is more to come. I am interested on looking into combined wireless download and write performance (and to compare this somehow with iPod Touch) as well as read performance the applications experience from the local storage.

However, some of the libraries in my project used commons-logging library, and I was very lucky to find a patched version, which enables running commons-logging on J2ME (Java CDC) device.

You can find information on how to build Java projects to run on different platforms, from here. I modified the javac task, by adding compiler, source and target definitions as follows to make code that runs on CDC Java.