     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Dealing With A Fragmented Java Landscape For Mobile Game Development Insights For The Future Despite the challenges mobile game developers face today with the fractured Java landscape, the future still looks exciting to me. One bright spot is the Java Community Process, which was originally founded by Sun Microsystems. JCP is an open organization working on Java standards. It uses a formalized process to develop new Java technology specifications and revises existing ones. Any member of JCP can submit a new Java specification request (JSR), so it's an important tool for all of us Java developers to help evolve the standard. For more information on JCP and a full list of JSRs, visit www.jcp.org. I have selected five JSRs that are interesting from mobile game developer's point of view.
To summarize, mobile applications are today merely add-ons to the device. The above- mentioned new APIs make it possible to create more seamless applications-providing new and exciting possibilities. The challenge, however, is that mobile game development is not only about producing games. All these APIs provide potentially an even more fragmented technology base -- and at the same time the developers have to support the current installed base of handsets, which is based on yesterday's technology. All the parties involved realize the problems brought by fragmentation and try to fight against it. One of the most interesting JSRs is JSR-185, "Java Technology for the Wireless Industry." The purpose of this JSR is not to produce new APIs but to provide an overall architectural description and to coordinate selected JCP efforts for the wireless industry. One of the most practical outcomes of this JSR is that, for example, instead of saying that a certain device supports MIDP 1.0 and Wireless Messaging API, it is JTWI 1.0 compliant. JTWI does give recommendations for minimum device capabilities, but it doesn't define actual categories, such as certain display resolutions or amount of memory. However, most manufacturers have adopted so called series thinking. This means that a manufacturer has a number of categories, which again have a number of devices in them. Examples of such categories are Nokia's Series 40 and Series 60. In the best cases the series thinking is working so well that application developers don't have to test an application on every device. Quality assurance has been taken into account as well. In June 2003 Motorola, Nokia, Siemens, Sony Ericsson, and Sun Microsystems announced their plans for unified testing and certification programs. For more information on this one go to www.javaverified.com. We at Sumea eagerly await the results of this initiative. The biggest problem at the moment I see in K Virtual Machine implementations: The APIs and specifications are not strict enough, leaving space for various different implementations. This should be solved soon, as the number of devices and APIs is growing. My wish-list is long, but it's clearly shorter than a year ago. I think that is a good sign. For Further Reading
 [back
to] Introduction |
|||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|