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.

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.

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!".