Friday, June 09, 2006
MIDP 3 , Do we really need it?
How's it going? People have started to talked about MIDP 3 for a long time, now seems getting velocity up and should be close by may 2006. -I'm confirming it, could you help me out?-
The first question I had, what’s new?
Notable Features so far:
- Secure RMS stores
- Removable and remote RMS stores
- Support for IPv6
- Specify standard ways for doing MIDlet provisioning through other means (e.g. OMA (SyncML) DM/DS, Bluetooth, removable media, MMS, JSR-232, etc.)
- Remote MIDlet start at bootup
- Enable multiple MIDlets in one JVM and inter-communication between midlets
- Better support for devices with larger displays
- Localization & Internationalization
- Enable richer and higher performance games ¿?¿? -What does it means?-
- Will be backward compatibility with MIDP2 content, at least this is what we hope.
When I take a look to the list I pleased to see some of the things. For example, be able to run more than one application at the same time. I mean soon, all of us will be using our IM client or music player; meanwhile we enjoy our favorite game.
The standard ways for doing MIDlet provisioning, also essential, right now is the weakness point in the industry. Think in the nightmare to download an application, sending 5 messages to download the game -if you are lucky, some time times the packages are not the good ones for your mobile-, Did you feel the necessity to kill?
I guess I could go in deep but I would like to heard your comments before ;-)
posted by Juan Antonio Muñoz-Gallego : 5:50 pm
Comments:
sais...
Well.. the more things a phone can do, the merrier. I'd like to see alpha blending for that antialiased look PNG can do.
Yet, I didn't get "the necessity to kill" thing.
I think you meant to post that in the "psychotic freak" blog.
dotcommie sais...
Here's my pick for features that would be great to have.
1. Applications written to the MIDP 3.0 specification should run on all Handsets with MIDP 3.0.
2. See #1.
3. Really, I'm not kidding.
4. I mean it. Let's make this work this time.
5. I know I'm just asking for too much, but can't we just have this one little feature.
6. Please.
7. With sugar on top.
8. I won't even mention Flash if you do this.
9. Honest.
Jaime Lanchares sais...
I think that each JSR we see is a new oportunity to make new things in so many different ways. The real problem is that manufacturers will make implementations of MIDP3 in the way they think is the right way (of course with different bugs in each case). We need a way to be more strict with the implementations from recommendations and specification requests, a way of working where all devices execute the same code as expected and not depending on each implementation. Thinking about better capabilities without solving the real fragmentation problem with manufacturers quality problems and specifications interpretations is not the best way in my opinion. Of course the "wrong" way is good news for tools like Battlewizard (http://www.unkasoft.com/bw_en.html), that solves part from fragmentation problem.
sais...
Mrakomor, those are wishes for any j2me game developer, but who makes the VM has other needs, restrictions and ideas.
I'm afraid that much of the damage is already done and there's no turning back.
Juan Antonio Muñoz-Gallego sais...
I agree with you, myNuMo, Specially in "Applications written to the MIDP 3.0 specification should run on all Handsets with MIDP 3.0.".
We have a platform to avoid the problem in MIDP 2, and we hope the problem is solved in MIDP 3 and go for new innovations.
Mrakomor, I mean already exists the device database you need. I work for a mobile company (Movistar) and they have it. But all your comments are good points.
Jose Manuel, What do you think? How could we help on that?
Jaime Lanchares sais...
We are using WURLF as our profiles/capabilities database. It is based on WAP developers experience with fragmentation problems. Also we have a patch file created by us, that we use over the WURLF database to improve the J2ME capabilities and for connecting with Battlewizard implementations. As far as I know, JBenchmark has't too much devices tested and some of the results we could see, are very different from our gaming tests in the same devices. JBenchmark need to introduce the firmware variable because differences between firmwares can be very big. Other things not managed by JBenchmark is some KVM implementations bugs like drawRegion memory leaks, that can be used in a test, but not in a real game.
JM sais...
Main problem with current MIDP 2.0 development is the lack of strictness for vendors implementations.
This means that although one handset support MIDP 2.0, it doesn't guarantee us all requiered features behaves correctly.
For that reason, although we'll get one perfect MIDP 3 standard (with all wonderful features you always dreamt), probably vendors won't take more care in those implementations, and we'll be in the same scenario, even worse, with one more standard to follow and support.
This is main reason for creating Battlewizard because we're sure perfect standard accepted and followed by everybody doesn't exist (and won't exist).
In other hand, about the standard devices database, our mobile development platform supports all devices included in WURLF (about 400 handsets and 1700 firmwares). It's an industry de facto standard. Most of operators use it for their WAP systems, and now we're using it for generate several content versions depending on each device capabilities.
Post a Comment
<< Home
sais...Well.. the more things a phone can do, the merrier. I'd like to see alpha blending for that antialiased look PNG can do.
Yet, I didn't get "the necessity to kill" thing.
I think you meant to post that in the "psychotic freak" blog.
dotcommie sais...Here's my pick for features that would be great to have.
1. Applications written to the MIDP 3.0 specification should run on all Handsets with MIDP 3.0.
2. See #1.
3. Really, I'm not kidding.
4. I mean it. Let's make this work this time.
5. I know I'm just asking for too much, but can't we just have this one little feature.
6. Please.
7. With sugar on top.
8. I won't even mention Flash if you do this.
9. Honest.
Jaime Lanchares sais...I think that each JSR we see is a new oportunity to make new things in so many different ways. The real problem is that manufacturers will make implementations of MIDP3 in the way they think is the right way (of course with different bugs in each case). We need a way to be more strict with the implementations from recommendations and specification requests, a way of working where all devices execute the same code as expected and not depending on each implementation. Thinking about better capabilities without solving the real fragmentation problem with manufacturers quality problems and specifications interpretations is not the best way in my opinion. Of course the "wrong" way is good news for tools like Battlewizard (http://www.unkasoft.com/bw_en.html), that solves part from fragmentation problem.
sais...Mrakomor, those are wishes for any j2me game developer, but who makes the VM has other needs, restrictions and ideas.
I'm afraid that much of the damage is already done and there's no turning back.
Juan Antonio Muñoz-Gallego sais...I agree with you, myNuMo, Specially in "Applications written to the MIDP 3.0 specification should run on all Handsets with MIDP 3.0.".
We have a platform to avoid the problem in MIDP 2, and we hope the problem is solved in MIDP 3 and go for new innovations.
Mrakomor, I mean already exists the device database you need. I work for a mobile company (Movistar) and they have it. But all your comments are good points.
Jose Manuel, What do you think? How could we help on that?
Jaime Lanchares sais...We are using WURLF as our profiles/capabilities database. It is based on WAP developers experience with fragmentation problems. Also we have a patch file created by us, that we use over the WURLF database to improve the J2ME capabilities and for connecting with Battlewizard implementations. As far as I know, JBenchmark has't too much devices tested and some of the results we could see, are very different from our gaming tests in the same devices. JBenchmark need to introduce the firmware variable because differences between firmwares can be very big. Other things not managed by JBenchmark is some KVM implementations bugs like drawRegion memory leaks, that can be used in a test, but not in a real game.
JM sais...Main problem with current MIDP 2.0 development is the lack of strictness for vendors implementations.
This means that although one handset support MIDP 2.0, it doesn't guarantee us all requiered features behaves correctly.
For that reason, although we'll get one perfect MIDP 3 standard (with all wonderful features you always dreamt), probably vendors won't take more care in those implementations, and we'll be in the same scenario, even worse, with one more standard to follow and support.
This is main reason for creating Battlewizard because we're sure perfect standard accepted and followed by everybody doesn't exist (and won't exist).
In other hand, about the standard devices database, our mobile development platform supports all devices included in WURLF (about 400 handsets and 1700 firmwares). It's an industry de facto standard. Most of operators use it for their WAP systems, and now we're using it for generate several content versions depending on each device capabilities.
Post a Comment
<< Home
