Month: February 2010

Transfer-Encoding: chunked

The J2ME HTTPConnection which comes with MIDP lets you make HTTP requests to your server. It doesn't do much at a high level, for example the API doesn't have methods like addCookie() - you need to manually add them with a request header. But the implementation is clever enough to turn any request body which is greater than around 2Kb into a chunked request. With HTTP 1.0, the request had to contain a header called Content-Length which told the server how many bytes to read off the input stream when reading the body. HTTP 1.1 introduced the Transfer-Encoding header, which lets the client omit the Content-Length header, and instead create chunks of request body, which optimises the upload meaning that a) the server can start processing before it has everything, and b) more importantly for J2ME where memory might be a valuable resource, it lets the client send a bit of the request, free up that allocated memory and then send some more of the request. For a POST request, with no chunking, the headers and body might look like this: POST /log.jsp HTTP/1.1 User-Agent: Mozilla/4.0 (maxant J2ME Client) Accept: text/html,application/xhtml+xml,application/xml Content-Type: application/x-www-form-urlencoded Content-Length: 51 Host: wwwchaseamatecom:8089 problem=Failed%20to%20get%20installation%20response Chunked, that becomes: POST /ota/addInstallation.jsp HTTP/1.1 User-Agent: Mozilla/4.0 (maxant J2ME Client) Accept: text/html,application/xhtml+xml,application/xml Content-Type: application/x-www-form-urlencoded Host: wwwchaseamatecom:8089 Transfer-Encoding: chunked problem=Failed%20to%20get%20installation%20response You'll notice that the body of the second example, "problem=..." doesn't contain chunk headers (search Wikipedia for chunking to see an example). The reason is that I copied that text out of…

Read more

A J2ME Library and a simple HTTP Service Framework

J2ME's support for calling a server is rather simple and low level. Not only do you have to deal with the HTTP Connection at a low level, there is no high level support for cookies, authentication or remote procedure calling. So if you want to pass an object to the server and get a response, you need to figure out how to do that. XML over HTTP is one solution, but presents its own problems like the serialisation and deserialisation of objects, not to mention higher network traffic because of the meta-data held within the XML. JAX Binding is certainly not supported in J2ME-land which results in you having to use a SAX parser. In previous projects I have toyed with a simple way of providing services over JSPs, which take and receive delimited text. The idea is to implement your own simple serialization and deserialisation of simple objects allowing you to make simple calls to the server and receive simple responses. I purposefully used the word "simple" four times in that last sentence to impress upon you the idea that server calls should be kept simple. Take for example a J2ME application which tracks a GPS location. To send the location of the user it can simply send a line of text like this: 006.574438|045.453345|11022344843373 What's it mean? longitude | latitude | timestamp The serialising and deserialising of the data is VERY simple using a StringTokenizer (erm, which doesn't exist in J2ME, so see later!). And the server could…

Read more

Base X Encoding

Ever needed to shorten a number so that its easier to remember? Or provide someone with a temporary PIN which is short enough to remember, but long enough to pretty much ensure it wont be randomly guessed by someone else? Converting a binary number into a hexadecimal is exactly the process used in such cases. But hexadecimal only has 16 characters in its "dictionary". Base64 is the next step up, with a bigger dictionary containing all alphanumerics (upper and lower case) as well as "/" and "+". I need a solution which didn't contain certain characters. For example, its easy to mix up an O with a 0. Or an I,l and a 1. I wanted a solution whereby I could encode a number, but using my own definition of the dictionary. So I built just such a solution. You can see the source code below. It contains a main method which runs a simple test, the output of which is:     Original: 123456789012345678901234567890     encoded: 2aYls9bkamJJSwhr0     decoded: 123456789012345678901234567890     Passed! decoded value is the same as the original. As you can see, the encoded version is only half as long as the input. Using an 89 character dictionary, it gets even shorter:     encoded: "9Kgbz])M.w8KgK The implementation uses the BigInteger class from Java, so you can encode REALLY big numbers. My phone number is now only 5 characters long and really easy to remember:     rDm3T /* * Copyright (c) 2010 Ant Kutschera, maxant * * The code…

Read more