• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Top features JCP should include in the MIDP/CLDC

 
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
there are complaints about the inherent limitations of MIDP when it comes to certain apps like games.
any opinions or RANTS here on what features should be considered for inclusion into the platform?
what steps need to be taken to make MIDP a success? what features need to be included in order to make life easier for us as developer?
[ July 29, 2002: Message edited by: a sanjuan ]
 
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, MIDP is missing a big sign saying "Not designed for game play." :-)
Seriously, MIDP isn't designed for games. Not now, anyway. MIDP was designed with 3 basic devices in mind (check the official spec for the formal list):
1) Smart Boxes
Things like routers that have a basic LED type interface and a few buttons, kinda like old VCRs, allowing for basic control through the buttons.
2) Pagers
Alphanumeric pagers, no frills attached.
3) Cell phones
Basic cells phones. Again, generally alphanumeric in nature.

MIDP doesn't even have real graphics capabilities. Why? No one felt they were necessary. Peopled wanted to write productivity apps for yesterdays phones, not prepare for advanced apps for tomorrow's phones.
PDAP has better graphics functionality. Most modern phones are closer to PDAP devices, anyway. Certainly most phones coming out in the next few years will have more memory and power then MIDP was intended for.
Perhaps if demand is really there, MIDP will incorporate this in the future, but I suspect what most people want are additional profiles to support game playing. MIDP fills a key niche and should be left there. Unfortunately, since PDAP and other profiles are taking so long, MIDP is all anyone has had access to.

--Mark
 
author
Posts: 1436
6
Python TypeScript Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK, here are my 2 cents:
1. I think MIDP 2.0 actually provide reasonable graphics support for games. No, I do not have a RI but from the example in JavaDoc they released, I think it is quite neat.
2. Even without MIDP, cell phone makers are already supporting gaming. A good book I found is Micro Java(TM) Game Development. Look at the examples in that book. They are quite amazing although most of them are non-US.
3. Although most games use graphics, wireless games can take other forms! quiz and text based games are getting popular.
So, I think games on MIDP platform does have a future.
 
a sanjuan
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
my 2 cents:
the problem, i think, stems from the confusion among many people regarding j2me. a lot of people equate j2me=midp, so when they are talking (and complaining) about "j2me", they are in fact simply referring to "midp/cldc".
i think in some ways this might hurt j2me (as a whole) in the long run, because midp was optimized for very resource constrained environments like basic cellphones and pagers, but (because it is the one complete profile out and the vendors are desperate to get things moving), it is being shoe horned into everything from pagers, to high end smartphones, to PDAs.
when it does not perform to satisfaction, or when the API is simply not capable of doing some things (simply because it was not designed to do those things), people blame "J2me" as being lacking, and may get frustrated enough that they quit altogether and move on to another platform. thus, they miss out altogether on the new profiles (CDC and CLDC) that later come out and which would have solved their problems better.
for example, one discussion thread i read had people basically blasting the game capabilities of MIDP 1.0 (which of course, everyone knew as "j2me"), and a guy came in and pointed out a possible replacement called
"Mophun"
http://www.mophun.com/
 
Michael Yuan
author
Posts: 1436
6
Python TypeScript Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by a sanjuan:

the problem, i think, stems from the confusion among many people regarding j2me. a lot of people equate j2me=midp, so when they are talking (and complaining) about "j2me", they are in fact simply referring to "midp/cldc".


The original post said MIDP/CLDC not J2ME.
Sure J2ME is much more than MIDP. But I think MIDP will be the most important profile in the long run, even in the gaming sector. That is because small and simple phones are the most pervasive devices and people will carry them everywhere. You might not carry a $500 high end device when you go to beach but you will carry your $20 phone.
If you want to design a wireless game, you want it to reach millions on the move rather than competing with console games for the same pool of sitting room gamers.
So, I think the problem for wireless games is not a 3-D graphics technical issue. It is to come up with and market a game people can become addict to on small screens.
 
a sanjuan
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i think you make some good points here.
when you code MIDP, don't think DOOM (although it WOULD be cool to see that running in a basic cellphone).
use the tool for what it was made for.
i think developers have to understand this, so they (1) won't get frustrated by the limitations imposed by it; (2) don't keep banging their heads against an only slightly yielding wall; (3) focus less on apps that are high on the complex graphics, and on apps that are more suited to basic (massmarket) cellphones.
i think what has to happen quickly though, is for such things as the game profile/personal profile to be implemented sooner rather than later, if only to (1) move developers to focus on these when they want to create complex graphic games; (2) prevent unfair comparisons between MIDP apps running on high end smartphones/PDAs and native apps or other platforms that are specifically targeted to these high end devices (but which would not be able to run at all in mass-market phones).


Originally posted by Michael Yuan:

Sure J2ME is much more than MIDP. But I think MIDP will be the most important profile in the long run, even in the gaming sector. That is because small and simple phones are the most pervasive devices and people will carry them everywhere. You might not carry a $500 high end device when you go to beach but you will carry your $20 phone.
If you want to design a wireless game, you want it to reach millions on the move rather than competing with console games for the same pool of sitting room gamers.
So, I think the problem for wireless games is not a 3-D graphics technical issue. It is to come up with and market a game people can become addict to on small screens.

 
Mark Herschberg
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Michael Yuan:

Sure J2ME is much more than MIDP. But I think MIDP will be the most important profile in the long run, even in the gaming sector. That is because small and simple phones are the most pervasive devices and people will carry them everywhere. You might not carry a $500 high end device when you go to beach but you will carry your $20 phone.


I think the phone running PersonalJava at JavaOne 2001 suggests otherwise. I have no idea what it costs, but I'm sure it'll cost half as much in a year or two. Moore's Law has a way to go for moble devices.
--Mark
 
Michael Yuan
author
Posts: 1436
6
Python TypeScript Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mark Herschberg:

I think the phone running PersonalJava at JavaOne 2001 suggests otherwise. I have no idea what it costs, but I'm sure it'll cost half as much in a year or two. Moore's Law has a way to go for moble devices.
--Mark


Hmm, even if Moore law applies to hardware -- Personal Java devices will drop below $100 in two years, it does not apply to human beings. It is the szie of the device that matters. You eye will take millions of years to evolve to see high resolution 3-D on small screens.
You do not want to carry a palm size device to beach while you can carry a small cell phone. That makes a J2ME profile designed for small screens more than relevant.
Also, MIDP evolves too. When Personal Java capable devices become cheap, you will see a lot of Personal Java APIs become available in MIDP 4.0 5.0 ...
 
a sanjuan
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
well, there's tetris, which will probably become the #1 download from the nextel catalog
beyond that, ???
also, you have to imagine that the carriers would rather see innovative games that utilize some airtime ("network aware", in j2me-speak), rather than standalone games that simply drain the battery of the phone.
ok, things i'd definitely want to see in MIDP is: (1) web services support.
(2) ability to interact with SIM cards and/or external smartcards through APDUs
(3) some javaphone APIs to allow interaction with calls, etc (or am i going too far here?)

Originally posted by Michael Yuan:

So, I think the problem for wireless games is not a 3-D graphics technical issue. It is to come up with and market a game people can become addict to on small screens.

 
Michael Yuan
author
Posts: 1436
6
Python TypeScript Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by a sanjuan:

ok, things i'd definitely want to see in MIDP is: (1) web services support.
(2) ability to interact with SIM cards and/or external smartcards through APDUs
(3) some javaphone APIs to allow interaction with calls, etc (or am i going too far here?)


1. We already have web services support through kSOAP and kUDDI. JSR 172 is making standard APIs (do not know how long it will take them!)
2. JSR 177 is such effort. I hope it could support SAML for web service single logon.
3. The new MIDP 2.0 allows you to pause your MIDlet and make a phone call automatcially using Java code. Of course, it would not *understand* the calls. We are a long way from voice recognition on handholds.
 
a sanjuan
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
yep, i know about enHydra's efforts, but like you mentioned, i'd rather get some standard APIs.
imho, single sign on is somewhat controversial, and since the liberty alliance still has to get its act together, probably some ways in near future. passport, e.g. has been scaled down a bit since it was first proposed because of strong objections by privacy groups.
gotta check out those new "phone call" abilities....thanks.

Originally posted by Michael Yuan:

1. We already have web services support through kSOAP and kUDDI. JSR 172 is making standard APIs (do not know how long it will take them!)
2. JSR 177 is such effort. I hope it could support SAML for web service single logon.
3. The new MIDP 2.0 allows you to pause your MIDlet and make a phone call automatcially using Java code. Of course, it would not *understand* the calls. We are a long way from voice recognition on handholds.

 
reply
    Bookmark Topic Watch Topic
  • New Topic