Friday, March 30, 2007

Bug in ConnectionDemo

Wireless J2ME Platform Programming, Chapter 8.

Comment out the println to make it work. It's trying to use conn without initializing.
public void run() {
// System.out.println("Connection class name = " +
// conn.getClass().getName());
connect();
parse();
...
}
Other things. To emulate this on my notebook, I had to unblock the emulator and some zaysit or something program so they can access Internet. Apparently, Wireless Messaging API needs initialization. Also, I updated my hosts file to show the current IP address, just to be safe.

Wednesday, March 21, 2007

Bug in PersistenceDemo code of Sun's J2ME book

I'd downloaded the sources of the book "Wireless J2ME Platform Programming" to save some typing. commandAction() method of PersistenceDemo class (Chapter 7) has this bug - it returns after it sees that the event didn't happen on the list, without giving any chance to the exit code that follows. I put a if (c == exit) line right at that start and that does it.

It also looks like that some of the imports aren't needed.

Monday, March 5, 2007

RE: Rapid Prototyping

Precisely what I was trying to say! For me, this is the key line

In this context, prototyping means writing the absolute minimum amount of throwaway code that's needed to answer a specific design question.

Hence we will be prototyping a single concept at a time.

RE: Rapid Prototyping

An excerpt from Code Complete:

Experimental Prototyping

Sometimes you can't really know whether a design will work until you better understand some implementation detail. You might not know if a particular database organization will work until you know whether it will meet your performance goals. You might not know whether a particular subsystem design will work until you select the specific GUI libraries you'll be working with. These are examples of the essential "wickedness" of software design—you can't fully define the design problem until you've at least partially solved it.

A general technique for addressing these questions at low cost is experimental prototyping. The word "prototyping" means lots of different things to different people (McConnell 1996). In this context, prototyping means writing the absolute minimum amount of throwaway code that's needed to answer a specific design question.



Of course, prototyping was to be done in the sandbox. Once we get the idea - precisely! We'll work on the prototype to get the idea. And then we move to the main trunk.

RE: Rapid Prototyping

Define a prototype. How long will we keep on "prototyping"? If you are talking specifically on the sandbox environment, then I couldn't care less. Those are like hello-world type programs which we make for understanding. But once we have an idea of what we want to do with Kite & then go to the main repository, I really don't want to code and throw. There has to be some implicit flow & logic to our work.

We will eventually use the concepts we have solidified in the prototype when we start on the real application.

RE: Rapid Prototyping

I disagree with - "Once we have the protocol issues resolved, we could go ahead, adding more to the UI." Here's the argument.

Adding more to the UI of the prototype could mean patches atop patches, 'cause first time around we'll make mistakes, and adding on to it will be plain hacking. When prototyping, we won't concern ourselves with the design. Idea is simple, get the UI details fast. Once we get that outta the door, we get rid of the prototype. This is essentially a throw-away prototype, and we must not fall in love. By now, we should also have the networking API working. With everything in line, we can *think* better in terms of widgets and APIs available and that equips us better for the design process.

Rapid prototyping for requirements-gathering, then the functional spec, and then the design process. No code reuse from the prototype; it's meant to be dumped. That's what I've been thinking.

RE: Rapid Prototyping

When I code, I implicitly use rapid prototyping. I'm very fond of writing small modules which help me visualize what I'm trying to do. So yes, I do agree the approach is worthwhile. Only caveat is that we need to make sure we don't digress from our common goal. Also, an eye on the bigger picture will not hurt!

My initial thinking was that we should provide a bare-bones UI which just allows the user to chat. That's it. Once we have the protocol issues resolved, we could go ahead, adding more to the UI. Simple rule I guess - "Functionality over eye-candy!".

Rapid Prototyping

To get the UI right, and also to get a feel for the networking API, I'd want to take the rapid-prototyping approach. Focus remains on getting the details right from a user's perspective, and not the design per se. Once we have something working and find ourselves on the same page as to the UI details, prototype needs to be dumped and we start all over again. This may sound like a waste of time but proponents of the approach swear by it, more so when we're new in this arena and have no clue what the end result's gonna look like.

Working in the sandbox, I guess we can begin now. Will also be an exercise in how well we communicate, and see what needs be done to streamline it. Hoping to setup SVN and stuff late in the evening today.

Exploring J2ME

Over the weekend I have been looking into the J2ME api with the help of the 'Programming Java 2 Micro Edition w/ Symbian' book. Being more oriented towards covering the length and breadth of J2ME, this is not an ideal book for someone new to wireless programming. I did however, get a good overview of the J2ME api.

J2ME is definitely a limited api. We will need to code a lot of the UI by hand, developing new widgets as we go. Designing a good UI will require quite some work. I have been giving considerable thought to our UI and the more I think, the more I am convinced that we should adopt a very no-frills approach for the UI. One that doesn't try to get in the way of the user.

On a cursory look, I do feel that making any sort of connection should be fairly simple given the high level of abstraction in the Connector api.

So much for now, I'm heading to work.

Friday, March 2, 2007

Repository Decision!

Finally decided to use Assembla as our source repository due to the dearth of free non open source project hosting alternatives.

My only concern is whether Assembla will stay around for a long time though to its credit its been around for a while.

Worse case scenario: Move the repository to Google Code hosting and charge a million bucks for source code :)

Hello World! (Turbo Edition)

Yeah, the authors call it the 'Turbo Edition'. After much ado, I finally have the hello-world in the 'Programming Java 2 Micro Edition for Symbian OS' (PJ2MES here on) working. Apparently the .png resource I was using had issues. Scoured a few forums before I could see what was happening. Some argument passed to the Sprite constructor wasn't valid. I didn't care to know which one, just replaced my .png with the one that worked (It had to work, 'cause I got it from the book's website). Guess the effort's been worth it; animation looked quite good on the Nokia E61 (E61) I ran it on.

I notice something weird happening on my machine. Turns out that Sun's emulator is trying to get to the Internet every time I launch it. Saw at least two different binaries doing that, one showed as J2SE and the other one as zaysit or something. Why? Blocked J2SE binary from accessing Internet permanently.

And I used Eclipse this time. Is neat. :-).

Thursday, March 1, 2007

RE: Hello World! [Eclipse Rocks!]

Using the EclipseME plugin I was easily able to build the proverbial "Hello World!" application :) In addition to the development setup I mentioned earlier, I also needed a little bit of configuration before I could start coding, which I will detail below.

Steps to configure the EclipseME plugin:
  1. Got to "Window > Preferences > J2ME".
  2. Set the WTK Root to the root folder of your wireless toolkit installation.
  3. Under J2ME, select "Device Management".
  4. In this tab, click on "Import".
  5. Specify the wireless toolkit root folder again in the "Specify search directory" text box.
  6. Now, click "Refresh" which searches the directory for installed devices. (I'm using the Sun Wireless Toolkit 2.5)
  7. Import all the devices in the list & click "Finish".
  8. Select a default device and click "OK".
And that's it :) We are done!!

Now, make a new J2ME Midlet Suite whose JAD file should be changed to make CLDC version equal to 1.0 and the MIDP version to 2.0. Then make a J2ME Midlet which I named "HelloWorld", containing the following code:

import javax.microedition.lcdui.Display;
import javax.microedition.lcdui.TextBox;
import javax.microedition.midlet.MIDlet;
import javax.microedition.midlet.MIDletStateChangeException;


public class HelloWorld extends MIDlet {

private Display display = null;
private TextBox textBox = null;

public HelloWorld() {
}

protected void destroyApp(boolean arg0) throws MIDletStateChangeException {
}

protected void pauseApp() {
}

protected void startApp() throws MIDletStateChangeException {
display = Display.getDisplay(this);
textBox = new TextBox("Simple", "Hello World!", 100, 0);
display.setCurrent(textBox);
}
}

Right click on your project, go to "J2ME > Create Package". This will create a "deployed" folder which contains a .jad and .jar file.

You could now copy these files to your phone and then open the JAD file via your phone. It should launch the "HelloWorld!" app! :)

You can also make a new "Run" configuration to execute the jar file from the Sun Wireless Toolkit emulator. This can be done from the "Run > Run" menu by making a new configuration under "Wireless Toolkit Emulator". Once created you can launch it easily!

Some points to note:
  1. For the Emulator configuration choose the "Midlet" form of executable rather than the "Over the Air" option.
  2. When you make a new J2ME Midlet Suite, in the screen for Java Settings, if you see a "J2ME Library (failed to get library information)" do not worry cause once you click finish, that particular problem goes away.

Hello World!

Deployed a hello-world midlet minutes ago on my Nokia E61.

And I'm itching to say a few words on the book I've been following this far. "Programming Java 2 Micro Edition for Symbian OS". With all due respect to the authors, the way this book takes off is disappointing. I believe a tutorial should **always** start with a hello-world, and just a hello-world, not a hello-I-was-hoping-maybe kind of a hello. Had to read over 70 pages of plain text to get to the first piece of code, and I just couldn't make it work. A simple hello-world is all a beginner needs. One can always get ambitious later.

To put the credit where it's due, here's the link to where I finally got what I needed. Couldn't thank the guy enough. My eyes had almost popped out of the sockets and the world was 'bout to end, when he saved them both.

JWT's got this small IDE to automate the build and config process. When I tried to deploy the package as is, I got some unknown-file kind of an error. And I was at sea. Next thing I did I looked into the settings of a jad of some app I had on my machine and compared it to that of mine. Changed MIDP 2.1 and CLDC 1.1 to MIDP 2.0 and CLDC 1.0 respectively. It worked.

That taken care of, here's my dev environment:
1. Windows XP SP2.
2. JRE 1.5.0_11.
3. Sun JWT 2.5 for CLDC.
4. Emacs 22.0.50.1.
5. Two chairs. (Blue and red. I sit on the blue one and rest my feet on the red. )
6. Sony FM Walkman.

Am gonna watch some TV now. Enough for the day.