a glover

Check out Enhydra- there is a mail library for J2ME already built:

http://mail4me.enhydra.org/index.html


I am sure they wouldn't mind a new developer helping them out, either!

Having used both and been a long time visual age advocate, I'd still have to say use Jbuilder as it is much more advanced in terms of keeping up with Java. Besides, visual age is being phased out in favor of a new open platform.

I find that I utilize the factory and command pattern quite frequently. The template pattern is rather valuable, in my opinion, too.

if you want to "sync" with the host via a serial cable, see MochaSoft PPP. This program allows a palm to utilize the TCP/IP stack.
http://www.mochasoft.dk/palm.html

MIDP for Palm does NOT offer serial support. As for performance, I haven't seen any benchmarks, but from the applications I have built using the beta edition and now the 1.0 edition (just came out), I can't complain as the environment is extremely limited.

I highly recommend the vanguard book, Design Patterns, by the Gang of Four (Gamma, Helm, Johnson, and Vlissides). In addition, I would read some Java publications, such as Java Pro and Java Developers Journal. Incidentally, Java Pro has a column written by the author of Java Design Patterns, James Cooper. Also, I have read articles in the Java Report written by Vlissides and read articles in Java Developers journal by the others of the J2EE patterns book.


As for a strategy for learning patterns, if possible, I would try to find a mentor who knows what they are talking about and learn as much as possible from them. Study groups is a great idea too!

Static methods are represented by underlining the method name in a particular sequence diagram.

From a strict performance perspective, indeed, iterating over a series of choices would be slower than a direct link to the corresponding object. When it comes to patterns, however, I would attack the problem from a flexibility and maintainability standpoint. If for some odd reason your implementation of the pattern becomes a bottleneck, then you can always take it out.

A common pattern I find effective is the Factory pattern. Basically, defer the implementation of a particular object to the actual creator at runtime. For example, say you have an interface representing a car. Your code will utilize this interface, but it may not care of its actual implementation (i.e. If it�s a 4 wheel car or 18 wheeler). In this case, you could use a factory to give you a particular instance of a car so that your code is plug and playable at runtime. Your code could say:


<code>
Car myCar = CarFactory.manufacture(�FourWheelCar�);
</code>


where �FourWheelCar� is a runtime creation of a class representing a 4 wheel car which implements the interface, car. You can see with some minor effort that your code is changeable with out recompilation.

Utilizing design patterns will speed up your development. If you are in a team-oriented environment, clear and effective communication is a must. I firmly believe design patterns help bridge the communication gap by creating a coding atmosphere where team members are on the same page. Moreover, effective use of design patterns will help in code maintenance and enhancements. Design patterns help to decouple system components, which will elevate those maintenance headaches caused when one code change ripples throughout the various layers. I strongly recommend you take the time to review your code; moreover, I would attempt to create object diagrams and sequence diagrams. Start high level and see your web based system spatially and you�ll easily find where patterns can be applied. After that step, delve down low level into the actual code; consequently, I would recommend examining your existing code with an eye for refactoring.

I would first come up with a model representing the fundamental data you return to clients. Forget display- focus only on the data. From this, you can then create an XML schema or DTD that represents your model.
With your model designed, you can focus on the look and feel. From here, you can develop an XSL that will transform your XML model into what you were originally creating with HTML.
Take a look at apache's xml projects (xml.apache.org) for a starter. Xerces and Xalan are outstanding libraries that will do the job. Moreover, you can look at something like Jdom (www.jdom.org). Cocoon, another apache project also fits into this space.

Thank you very much, the example you posted is most informative. Now, it seems it is just a matter of mastering RTF. For those interested in RTF, there is a link:
http://msdn.microsoft.com/library/?url=/library/en-us/dnrtfspec/html/rtfspec.asp?frame=true
Alas, the CitySlicker alias has been retired in favor of my new one. Thanks for pointing out my error!