I have warmed to XML having learnt hard lessons about changing on the wire formats for messages, between version skewed participants. So XML has been great for server side in banking where much of our data is already in XML and JVMs have 4Gb of physical RAM. On the transaction side of banking, XML parsing speed has always been dwarfed by RDBS transaction times. These statements are not so true on the market data side.
I'm back in the mobile device world and XML is too verbose. There are already mechanisms for reducing the size, for example WBXML, aimed at old WAP browsers. However WBXML required much hand crafting of code pages and analysis of occurrences for new message types. I shiver at the thought of all the hand coded parsers I've seen.
I had read about the Google protobuf library, and decided it was trying to address the exact problem I had, which is mainly about space. I therefore needed in binary encoding.
The downside is that the web is my wire, so I have to character encode the binary.
I'm using the Apache Commons Codec libraries for this.
I couldn't use the latest Apache Codec on android, as it appears to have a repackaged version that exists already.
11-27 15:48:42.551: DEBUG/dalvikvm(479): DexOpt: 'Lorg/apache/commons/codec/binary/Base64;' has an earlier definition; blocking outI also could not get the Base64OutputStream and Base64InputStream to create content correctly.
Since my input content is never more than 1024 bytes, I'm using the Base64 class.
A great feature are the Base65.URL_SAFE and Base64.NO_WRAP flags which give me exactly what I need to be able to use my encoded string as a HTTP parameter.
Perfect.
Are comments pushed too?
ReplyDelete