Everyone who worked with Java ME a couple of years ago (for 'J2ME' fans, this is the new name of the platform), should feel very confortable with the platform today. That is because Java ME didn't evolve too much in the last years.

We are at a time of great changes in this area. Mobile hardware capacity has grown in the last years, and people are updating their mobile phones more frequently. That's the cause of the need of evolution in Java ME and, for that, JCP (Java Community Process) is working on multiple standars. In these series of post we'll discuss each of them. In last JavaOne in San Francisco, many of these 'new mobile architectures' were presented, and some of them are already implemented in some new devices.

Let's start to see some new APIs that complements MIDP and CLDC. These new JSR or APIs are the standard way to use new features in mobile Java technologies right now. Remember that if a device doesn't implement a API, we don't have a possibility to use it or install it on that device. There are a dozen of new APIs (just look at www.jcp.org), but I'll focus in this post in the following:

Web Services

This isn't a new API, but there aren't many developers using it yet. This API allow us to consume SOAP web services from the mobile device; a very useful feature in mobile development to create Smart Client Applications that connects to a remote server. This API is JSR-172 and it is implemented in some IDEs in a graphical way, like Nokia Carbide.j 1.5 and Netbeans Mobility Pack 5.0.

If we are working with JSR-172 no capable phones, we can still consume web services using our own library, by parsing the SOAP XML with the help of another library, like kXML, a free Java ME XML parser library.

Mobile Payment

This is a great feature for us (we are doing this for receive a payment, don't we? ;-) ).

In these area, there are two adittional packages to work with. These are Secure And Trusted Services APIs (SATSA JSR 177) and Payment API (PAPI JSR 229), Using this APIs we should develop, in the future, applications that charge the user for some service or content using, a) Remote Transactions (like a ringtone download) or b) Local Transactions using proximity technologies (like with a soda machine). These two APIs covers: security, interoperability and easy of use.

SATSA API add security and encryption to Java ME. With PAPI we can make mobile applications to charge the user, abstracting us the architecture behind. The user (or operator) should have available many payment mehods installed on the phone (by SMS, credit card, phone bill, etc) and we only decide how much we want to charge, and the user will be prompted to select a way to pay it.

Let's see some code of the process

import javax.microedition.payment.*;  
public void startApp(){
try {
   TransactionModule myTrans = new TransactionModule(this);
   myTrans.setListener(this)
   myTrans.process(featureID, “Title", "Description");
…
}catch (Exception e) { }
}
 
public void processed(TransactionRecord paymentRecord) {
switch(paymentRecord .getState()) {
   case TransactionRecord.TRANSACTION_SUCCESSFUL:
      // Payment OK
      break;
   case TransactionRecord.TRANSACTION_REJECTED:
      // Payment KO
      break;
}
}

The information about the price and other data is stored inside the manifest, in the JAR file.

We should use this feature in the future to offer some new cool levels for our games or, ¡new game lifes! Imagine yourself playing Space Invaders Ultimate in the last level, with the last enemy ship to kill and you lost your last life... will you pay $0,20 to get one more life? Will be 'gaming ethical' to offer this in a game? Interesting question...

What's Next?

In other post I'll continue with the Future of Java ME... talking about SVG, Internationalization, Contactless technologies, new tools and IDEs, and the most expected ones... MIDP with CDC, Next Generation Mobile Platform and MIDP 3.0.