Skip to main content

Does "High-level x Low-level APIs in MIDP" Mean "Portability x Usability"?!

Posted by brunogh on June 29, 2007 at 12:37 PM PDT

In MIDP (Mobile Information Device Profile), all UI (user interface) classes can be found in the javax.microedition.lcdui package. This package basically contains two sets of APIs: high-level and low-level. So, what is the difference between them? How do you choose and balance the advantages and disadvantages of these two groups? Here we go...

If you are looking for portability, which means having a single version of your application and have it running in all devices, you can use the high-level API. But why? All the components across this API depend on the mobile implementation, so they are rendered by the mobile, which is good, because you will not have to care about things like how to handle different screens sizes, for example. On the other hand, you will have less control over the UI, which means you can not do what you want, the mobile will give the last word in terms of UI and your application could look different in the variety of mobiles. Anyway, this API is huge and you can find a lot of components (subclasses of the Screen and Item classes): Alert, ChoiceGroup, CustomItem (an abstract class for customizable items, since MIDP 2.0), DateField, Form, Gauge, ImageItem, List, Spacer (since MIDP 2.0), StringItem, TextBox and TextField. Now, in MIDP 3.0, we will get some other components (and a lot of improvements and useful classes too): FileSelector, that has a screen to allows the user to select a file from file system; and TabbedPane, which allows the navigation between screens by selecting the corresponding tab. But what about the second group?

The major low-level API classes are Canvas and Graphics, they allow the developer to have greater control over the UI, which is good for usability, because you can make things as your wish and as your application users wishes. However, the developer has the responsibility for drawing and rendering the display and that means problems in portability. Probably if you use low-level APIs and want that your application could run in a lot of devices, you will need to port it (or get all mobile characteristics at runtime and render things dynamically), which means adapt it for specific devices or family of them. Do not forget, all of these work because we have a lot of differences between devices and things are not always pretty easy (not now, yet, but things are getting really really better ;) ). But, where does this low-level API apply? Mobile Games use Canvas (or extending GameCanvas in a concrete class, after MIDP 2.0)! However, low-level API is not only about games, I have seen some cool applications using it and good frameworks providing extra portable (in some way) components as well.

More and more, people do not only want something that works, they want things working, but with the additional of a great visual stuff (and portable applications as well)! That is why, in Java ME, we are having a lot of improvements in this aspect over the years, for example, nowadays, with JSR 226 (Scalable 2D Vector Graphics API for J2ME). If you want to understand more about all this Java ME UI context, including UI in other profiles and how could be the future with SVG, 3D Graphics and so on, I do recommend you to read this recent Bruce Hopkins' article. I forgot to tell, you can mix both high-level and low-level APIs in your application! Forget, you can mix whatever you want to make your application look even better... and portable too! That is the way! Have a good weekend!


Bruno Ghisi

Related Topics >>