> It really requires two completely separate sets of code to > provide the appropriate user interface in your system. > Maybe 10% to 20% of your code could be common between the > platforms, but then there is the endian issues, so it > really isn't worth trying to have a common code set, in my > opinion.
Speaking as a developer who works at a company that develops applications for the Palm and PocketPC, my opinion differs from yours to a great degree. Far more than 10 or 20 percent of our code is common to the two platforms, and the fact that the business logic runs on two separate platforms helps us narrow down bugs very quickly. (If it's in both, it's a common-code bug. If it's only in Palm, then we only have to look through the Palm stuff. Ditto for PocketPC.) We've separated our code out into Models, Views, and Controllers, and the only platform-specific code we have are in the sub- classes of the various Views. (So, we'll have a FooView, and a PalmFooView, and a WinceFooView, and recently even a Win32FooView.) Having said this, we are doing all of our Palm development in C++. It makes for larger applications than I might like, but our clients seem to think that the benefits of having a product for both of the major handheld systems out there is more than worth the slightly larger size. > So, is Java the answer? I've worked with Java on the Palm (back when it was the KVM), and I don't think Java is the answer yet. Maybe when the new processors are more common it will be feasible. On my Palm Vx I could get the demos working, but as soon as I tried to write something a little more complicated than them, I hit barriers that I couldn't get around. Later Blake. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
