Airlan San Juan's Blog

Java developers sure do like making things from scratch

You'd think that after 10 years - an entire DECADE mind you - that Java developers would have a treasure trove of pre-built components that they could use to quickly cobble together their otherwise home-brewed apps.

Alas, perhaps there are just tons of examples of this in the bigger world of Java SE and JEE, but at least in the world of small Java, trying to code some of the simplest functionalities can cause some people who are stingy about buying books to go into a real google frenzy.

Take this MIDP app that I recently started coding as a side hobby. I needed to have the thing talking to Java servlets on the server, and I figure this'll be a cinch. As a Java developer, my first impulse was to simply use some code from a book, and admittedly, the code snippets to do POSTs that I found are pretty straightforward:

 try {
         hc=(HttpConnection)Connector.open (targetUrl,Connector.READ_WRITE);		 
         hc.setRequestMethod (HttpConnection.POST);
	 hc.setRequestProperty("User-Agent", "Profile/MIDP-2.0 Configuration/CLDC-1.0");
	 c.setRequestProperty("Content-Language", "en-CA");
		 
         dos=hc.openDataOutputStream();
         byte [] req_body=theData.getBytes();
         int size=req_body.length;

         for (int i=0;i < size;i++) {
                dos.writeByte (req_body[i]);
         }
         
         dos.flush();
         
         // receive response
         dis=new DataInputStream(hc.openInputStream());
    
         int ch;
         while ((ch=dis.read()) !=-1) {
                 b.append((char)ch);
         }              
    } finally {    
              if (hc !=null) hc.close();
              if (dis !=null) dis.close();
              if (dos !=null) dos.close();
      }

But then I have to worry about session management (where parsing requests and response headers becomes a fulltime job) and all the other tiny details that are needed to make it into a robust functioning unit (saving multiple sessions to the RMS for example), and I got to wondering why some good soul who had done this before hadn't simply packaged the entire functionality into a nice, shiny new component that I could plug into my Midlet suite and thence say et voila!

Given such a huge library of Java ME components, even relative newbies should be able to assemble together a functioning suite in no time flat. Imagine some newcomer to the world of Java who starts up Netbeans Mobility, uses the really cool Midlet Visual Mobile designer tool to quickly create the needed MIDP forms by dragging and dropping screen commands, list items, textfields and whatnot, then imports pre-built components into the Midlet suite, again by dragging and dropping instead of going to the source.

Sound good, right? I did my googly thing but the sites I found were sorely lacking in actual meat. So, if anybody knows of any places for Java ME developers to acquire basic components such as these, please feel free to tell me, and everyone else here. If there aren't any such places, perhaps I could add it to the To-Do list of the Java ME group that was set up for just such problems?

Comments

• The mobile space isn't particularly good for reusable components because that reusability/generality has an associated size/performance cost. On a desktop or server, it rarely matters but on a mobile phone every byte counts. That's why all the API's for Java ME are so simple -- Java ME doesn't have the luxury of piling on the abstractions like Java SE and EE. For some MIDP applications/phones you'll have to start thinking about the number of classes in your application and the number of objects you have instantiated at any given time. Just because it looks like the desktop/server Java you know, doesn't mean you can approach it in the same way.

  Posted by: hopeless on June 20, 2006 at 04:52 AM

• Hi:

  In fact I was thinking the same way, but:

  in the past several years, the general capabilities of mobiles seems to have gone up. I remember the time when even application size was severely limited, but now you have apps and games that routinely cross 100 kb in size. Heap size too seems to be generally up.

  There are quite a number of functionalities that can be encapsulated in units that would not really vary that much, or need to be so specific. As mentioned above, handling connection relationships to server apps might be one example. I don't buy into the argument that each and every application has to be extremely unique from every other application just because the developers are different. Common functionalitles will always bve there, and of course, the consumer developers always have the choice of reusing a component or creating their own from scratch.

  Posted by: asj2006 on June 20, 2006 at 05:40 AM

• Also, isn't it possible manageability of apps in the long run would be increased if people started using standard components to cobble together certain parts of their apps?

  So, sacrificing raw efficiency might get you in return faster, quicker, easier development, and better manageability in the long run - not to mention it saves developers from 'inventing the wheel' all the time.

  Certainly, Java has the reputation for being 'difficult'. I'm the type of person who is not too proud of this perception and anything that convinces newcomers that this is not necessarily so is good with me.

  Posted by: asj2006 on June 20, 2006 at 05:55 AM

• You obviously haven't tried Apache commons HTTPClient; it takes care of most of the HTTP complexity for you, including handling cookies, proxies, authentication and POSTS.

  Posted by: infernoz on July 24, 2006 at 11:49 AM

• It is at http://jakarta.apache.org/commons/httpclient/

  Posted by: infernoz on July 24, 2006 at 11:51 AM

This work is licensed under a Creative Commons License.