Java Reference
In-Depth Information
A small JAR means that large assets such as video clips, high-resolution
images and audio clips need to be stored and retrieved from remote
locations. That's not too hard but it may require significant re-engineering
of your code base when you're trying to port a MIDlet across to DoJa.
Incidentally, it's worth noting that the latest DoJa 5.x versions in Japan
allow up to 1MB to be shared between the JAR file and the Scratchpad
so, if you are working with these versions, it is obviously less of an issue.
One of the more unfortunate consequences of this size limitation
is that developers must take dramatic steps to reduce the size of their
executable. They usually adopt aggressive coding strategies that result in
a poor code base which tends to be almost unreadable and extremely
hard to maintain. I'll talk more about this in Section 7.6.
On the other hand, DoJa2.5oe has a very good game API - one that
rivals the MIDP game API (and for now, mobile development is all
about games). With support for the Mascot plug-in, you can get high-
performance 3D graphics in DoJa pretty quickly and what's more this will
take advantage of any hardware acceleration on the device. It also has a
fully featured GUI implementation for thick-client applications. This is in
many respects very similar to the Abstract Windows Toolkit (AWT) model
from Java SE so the learning curve is not a steep one.
DoJa also has some features that MIDP doesn't have - applications
can be notified of system events such as the 'ticking' of the system clock
as real time passes, the folding of the handset (most DoJa phones tend
to be clamshells) and activate or suspend events. You can also find out
the reason an application was last suspended - allowing your code to
resume with some context.
There is also a fixed mapping to the left and right softkeys so you
don't have to hardcode magic numbers in your event handlers to work
out which one was pressed - a simple mapping which MIDP still doesn't
have (you can see an example of this in
GhostPong
in Chapter 8). And
when an application is suspended, the framework automatically stops
any audio playback in progress - given the number of MIDlets (mainly
games) that either don't do this at all or do it sporadically, this is a really
nice feature.
You can also create screen savers easily using the standby functional-
ities of the
MApplication
class and ADF configuration options. If you
don't see any value in that, check out any Java ME forum - everyone
wants to be able to do this in the MIDP world and, although it's part of
the MIDP 3.0 proposal, they can't do it just yet.
Again, note the difference between DoJa, a profile designed to meet
the specific demands of a particular customer market, and MIDP, a profile
that tried to be all things to all people by staying generic. DoJa focuses on
opportunities and product a lot more than mainstream Java ME but that's
no surprise as they sprang from very different sources.
