MobileLJ Architecture


MobileLJ is a Java 2 Micro Edition MIDlet designed to run on cellphones and PDAs.  It arose from my desire to write a J2ME application.  While I know J2SE and J2EE fairly well, previously I knew nothing about J2ME.  As such, it went through several design revisions until I came across one that worked well, within the constraints of both the Micro Edition limitations and real-world limitations.

The MobileLJ software is a client/server application.  The Java client talks to a forwarding server that parses the request, sends it to LiveJournal using the special LJ protocol, interprets the result, and sends it back to the Java client.  As a privacy advocate, I am a little wary of having a centralized server like that, but it seemed to be the only reasonable solution.  Both the client and server code are Open Source, copywritten under the GPL.  The server is a single PHP script, so should run on a variety of servers (Apache, IIS, Unix, Linux, Windows).  You are not only allowed to set up and run your own relay server, you are encouraged.

The initial architecture designs of MobileLJ called for a Java app that talks directly to the LiveJournal servers.  The prototypes were looking good, with one exception.  "400 Bad Request."  It turns out that the KVM reference implementation that comes with Sun's J2ME Wireless Toolkit really likes to send POST data using HTTP 1.1 "chunked" encoding.  It also turns out that the latest stable builds of Apache really do not like "chunked" encoding for POSTs.  The solution was to implement HTTP/1.0 POSTs entirely using raw sockets or go with a more easily parsable client/server format.  Because of processor and memory constraints (and because I did not feel like re-inventing the wheel) I went with the latter.


The MobileLJ client is a standard J2ME application.  In theory, it should run on any platform: any cellphone, PDA, or pager that supports the J2ME runtime.  It talks a custom client/server protocol to a MobileLJ server.  The server parses the input, relays it to the official LiveJournal server, interprets the response, then sends a response message back to the client.  

The client talks over raw sockets using a scaled down HTTP/1.0 protocol.  It sends a standard HTTP POST request, but the response is expected to be quite simple.  The first line of the response headers is scanned for an error code.  If it is "200" it continues processing.  If it is any other code, processing stops and the code (and any text string following, up to the first newline) is displayed to the user.  The rest of the headers are skipped over.  Once the body of the response is reached, only the first line is scanned.  This line is then displayed to the device's screen.  The line should be the human-readable response from the MobileLJ server--something like "Successful post" or "LJ server reports invalid password."  

The client is really no more intelligent than that.  It caches your name+password in nonvolatile memory in your handheld device so that it does not need to be re-entered every time you wish to post, but is a fairly simple application.  At present there are little, if no, exception checks for out of memory.  This did not pose a problem while testing on the emulator, but in a real-world situation in a limited-memory device, this may be an issue.  A URL encoded copy of the text entered in the "entry" (and "subject," for that matter) text field is made in memory.  This text box accepts up to 4000 characters.  This means that if you use the maximum post size (rather difficult using a numeric keypad as your keyboard, but still possible), the device will require at least 8K free to hold the original and the copy.  This is in addition to any other runtime stack or heap information the app is using.  Of course, this is unlikely to cause a problem under normal usage, but is still a potential issue.


The MobileLJ server is a single page of PHP.  It has enough intelligence to relay a request to LiveJournal and interpret the response.  It performs absolutely no persistent caching of data (i.e. it never saves anything to a database or file), and keeps an incoming requet's username, password, and post information in memory long enough to relay it.  It also contains some macro definitions at the top of the code.  One take the server offline (sending a user-defined friendly error message to any Java client trying to access the server).  Another puts the server in debug mode--it will accept a request, pretend that it relayed it properly to LJ, then send back a "successful" response to the MobileLJ client.

Because the page uses nothing but the most simple PHP commands and doesn't care about anything on the local system, it can be run on any web server supporting PHP.  Feel free to place this on your own web server.  

Running Your Own Server

You are welcome (and encouraged) to run your own server.  To do this, you will need three things in addition to your PHP-supporting web server: the mobilelj.php script, the MobileLJ.jar file (this is a special ZIP file containing all of the executable code that runs on the cellphone), and the MobileLJ.jad file (this is a special text file that describes the MobileLJ.jar file and includes a few server connection parameters).

mobilelj.php: Place this file somewhere on your server.  The official MobileLJ server holds this in the root directory ("").  To make support easier, it is suggested you place it there.

MobileLJ.jar/MobileLJ.jad: You do not need to modify the *.jar file, only the *.jad.  Locate the three entries at the bottom: host , postUrl, and requestPath.  postUrl is the socket URL that the request are sent to.  Do not get this confused with a standard "http://" URL.  It is quite different.  It consists of the word "socket://" followed by the server name, a colon, and the port and nothing more.  Do not put a directory after this.  Do not put a page name after this.  That is what the other two parameters are for.  The host parameter is for the "Host:" HTTP header, in case you are connecting to a server that supports virtual hosts.  It should be the same server name used in postUrl.  requestPath is the file portion of the URL.  It is used after the "POST" command in the HTTP request.  Basically, it is the file portion of the URL.  It starts with a forward slash, may or may not have directories (it is suggested not to use subdirectories), followed by "mobilelj.php", the server page name.  By default, all of this is lower case.  For the sake of consistency, it is suggested to keep it all lower case.  While IIS is not case-sensitive, Apache is.  

$Id: MobileLJ_Architecture.html,v 1.1 2002/04/21 21:33:28 enigma Exp $