Developing MIDlet for PDAs and cell phones

[Darryl L. Pierce]

I am a member of a small club and several people in the club have PDAs and
cell phones. If I want to make an application that each of our members can
use on their existing PDAs and cell phones (assuming their cells can even
run MIDlets) what exactly do I need to know about each of their devices to
develop MIDlets that will run on all their devices (at least those that
are capable of running MIDlets)?

The whole point of the MIDP is that you shouldn't *need* to know anything
about the handset in order to run the application.

With that said, there are, obviously, exceptions. For example, with the MIDP
1.0 and low level graphics you will quickly find that there's no standard
keycode for things like softkeys and anything outside of the ITU-9 keypad.
You'll also find that different handsets render graphics different; i.e.,
the Samsung A600 won't paint any part of a graphic that extends below the
screen height, if you have a background that's taller than the screen then
only the top half will render even if you do XY translations.

In other words, rather than writing toward a specific device, e.g. Nokia
CP1111 cellphone, and requiring everyone to have that device, I want to
write MIDlets that will run on a (small) known set of devices. How do I
determine the capabilities of those devices so that I know what the lowest
common denominator MIDP, CLDC, etc. I need to use in doing the
development?

What capabilities are you looking for? The MIDP requires that the LCDUI
components be supported and that the device provide some level of
persistent storage and HTTP networking. Outside of that set (which is
complete enough for most applications) what do you need?

--
/**
* @author Darryl L. Pierce <[email protected]>
* @see The Infobahn Offramp <http://mcpierce.multiply.com>
* @quote "Lobby, lobby, lobby, lobby, lobby, lobby..." - Adrian Monk
*/

 

[Rhino]

I am a member of a small club and several people in the club have PDAs and
cell phones. If I want to make an application that each of our members can
use on their existing PDAs and cell phones (assuming their cells can even
run MIDlets) what exactly do I need to know about each of their devices to
develop MIDlets that will run on all their devices (at least those that are
capable of running MIDlets)?

In other words, rather than writing toward a specific device, e.g. Nokia
CP1111 cellphone, and requiring everyone to have that device, I want to
write MIDlets that will run on a (small) known set of devices. How do I
determine the capabilities of those devices so that I know what the lowest
common denominator MIDP, CLDC, etc. I need to use in doing the development?

I'm still very new to MIDlets so if I'm not asking a coherent question,
please help me ask one that makes more sense ;-)

 

[Rhino]

The whole point of the MIDP is that you shouldn't *need* to know anything
about the handset in order to run the application.

Yeah, that's basically what I thought but the fact that there are already
two levels, MIDP-1.0 and MIDP-2.0 with others presumably on the horizon,
plus different levels of CLDP, and other Profile stuff like the Personal
Basis, made me think that I might have to be sensitive to what versions or
levels of each that the different devices are running. However, I am still
VERY new to the whole world of MIDlets so the concepts haven't really sunk
in yet.

With that said, there are, obviously, exceptions. For example, with the MIDP
1.0 and low level graphics you will quickly find that there's no standard
keycode for things like softkeys and anything outside of the ITU-9 keypad.
You'll also find that different handsets render graphics different; i.e.,
the Samsung A600 won't paint any part of a graphic that extends below the
screen height, if you have a background that's taller than the screen then
only the top half will render even if you do XY translations.


What capabilities are you looking for? The MIDP requires that the LCDUI
components be supported and that the device provide some level of
persistent storage and HTTP networking. Outside of that set (which is
complete enough for most applications) what do you need?

I'm not sure yet. I'm still just at the design stage for a few MIDlets so I
haven't thought the whole design through. I like to use colour though and I
read that colour isn't available in MIDP-1.0 (or was it CLDC-1.0?). Ditto
for custom controls. But I may be able to write something satisfactory with
just MIDP-1.0 and grayscale. Or maybe I'll write two versions of my MIDlet,
one for MIDP-2.0/colour/custom controls and a more primitive version for
MIDP-1.0/grayscale/standard controls. Like I said, I'm new to MIDlets and
only started looking at them on Thursday, at which point I knew nothing at
all about MIDlets.

Rhino

 

[Darryl L. Pierce]

Yeah, that's basically what I thought but the fact that there are already
two levels, MIDP-1.0 and MIDP-2.0 with others presumably on the horizon,

Nope, there are no new MIDP versions on the horizon. MIDP 2.0 is the latest
and is only now becoming prevalent on handsets.

plus different levels of CLDP, and other Profile stuff like the Personal
Basis, made me think that I might have to be sensitive to what versions or
levels of each that the different devices are running. However, I am still
VERY new to the whole world of MIDlets so the concepts haven't really sunk
in yet.

The Personal Profile will only be on larger handsets, tablet PCs and settop
and headless devices. I doubt you'll find them on mobiles anytime in the
near future. My recommendation is to focus on MIDP 1.0 or, if the handsets
are new enough, MIDP 2.0.

I'm not sure yet. I'm still just at the design stage for a few MIDlets so
I haven't thought the whole design through. I like to use colour though
and I read that colour isn't available in MIDP-1.0 (or was it CLDC-1.0?).

You have no control over the colors of high-level UI widgets (i.e., the Form
class, Item classes and List and TextBox) but you do have color for doing
your own graphics via Canvas.

Ditto for custom controls. But I may be able to write something
satisfactory with just MIDP-1.0 and grayscale. Or maybe I'll write two
versions of my MIDlet, one for MIDP-2.0/colour/custom controls and a more
primitive version for MIDP-1.0/grayscale/standard controls. Like I said,
I'm new to MIDlets and only started looking at them on Thursday, at which
point I knew nothing at all about MIDlets.

If you're using Form-based UIs (the most portable) then you can forget about
color, you'll have no control over it. If you're talking games you can do
color. What *kind* of app are you talking about?

--
/**
* @author Darryl L. Pierce <[email protected]>
* @see The Infobahn Offramp <http://mcpierce.multiply.com>
* @quote "Lobby, lobby, lobby, lobby, lobby, lobby..." - Adrian Monk
*/

 

[Rhino]

Personal Basis is a minimal set of the Personal Profile for headless devices
and minimal display devices. But, again, there's no MIDP 3 TMK. The EG just
released MIDP 2 last year and to start on a third specification now would
make for an unsteady market and do more harm than good to Java adoption.

I get it; no MIDP 3 in the near future ;-) But what *is* the method by which
new functionality will be made possible in PDAs? Surely no one seriously
imagines that no new requirements or facilities will ever be wanted.

For example, if the hardware that could support voice-activated applications
became sufficiently inexpensive that they could be added to PDAs at a
reasonably small cost, how would the software to support voice-activated
components be provided for in PDA software development? Would we get a new
CLDC, new Personal Profiles, or what? Somehow the existing APIs would need
to get enhanced to provide the new methods that would be needed to do
voice-activated code.

By the way, I don't really care about voice-activated in particular, I'm
just using it as an example of something new needing to be supported by
PDAs, cell phones, and other like devices. I'm trying to understand where
the vendors would put the new APIs that would be needed to support new
hardware, regardless of the nature of that hardware.

Rhino

 

[Darryl L. Pierce]

I get it; no MIDP 3 in the near future ;-) But what *is* the method by
which new functionality will be made possible in PDAs? Surely no one
seriously imagines that no new requirements or facilities will ever be
wanted.

For example, if the hardware that could support voice-activated
applications became sufficiently inexpensive that they could be added to
PDAs at a reasonably small cost, how would the software to support
voice-activated components be provided for in PDA software development?

Optional APIs for J2ME. Things like the Bluetooth APIs, the PIM APIs
(formerly the PDA Profile), Location APIs, etc.

And vendors are always able to add proprietary Java APIs to their MIDP
environment. The only restriction is that, if a JSR exists that covers that
area, they have to provide the standard APIs as well.

<snip>
--
/**
* @author Darryl L. Pierce <[email protected]>
* @see The Infobahn Offramp <http://mcpierce.multiply.com>
* @quote "Lobby, lobby, lobby, lobby, lobby, lobby..." - Adrian Monk
*/