This post continues on programming HTTP within Android. In the following, I’ll show how to manage Base64 coded content in Android and how to render an image on WebView from a String that we encoded.

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.

Parsing multipart MIME documents can be troublesome in limited Java environment like Android, J2ME, or CDC. One cannot simply use javax.mail together with activation.jar, since activation framework is not supported in these environment.  I wrote this post, because Android does not provide tools for parsing multipart MIME messages, e.g., for extracting contexts of MIME document with type multipart/related or multipart/mixed. A solution is to use third party MIME parser from W3C Jigsaw project. The Jigsaw MIME parser does not contain references to classes that would cause harm in Android programs. The documentation for package is here. The source code packages here.

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!

Inspired  by some visibility in storagemojo.com, I decided to provide some more plots on the Flash storage performance.

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.

The new N810 which I got last week, could not install Skype application because of some old Hildon libraries. So re-installing the operating system on N810 was needed.

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!

I have been following writings on flash storage performance from storagemojo blog. Now, that I had a little time to sit down and a Nokia N800 at hand it was time to do a small experiment. I ran some benchmarks with a Java program that creates random data (in chunks of kilobyte) and writes the data to a file. For comparison I ran the same program with the cheapest Intel based MacBook available using Java 1.4. I used the same source level and the same Java binary that I used on N800 running Java CDC.

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.