Developing for Japanese Phones in Netbeans (Part 3)

IAppli (NttDocomo) Development in Netbeans

In parts one and two of this large blog post I explained how to use Netbeans with the Mobility pack to develop mobile applications for two of the major carriers in Japan (au/KDDI and Softbank). In this last part I will talk about developing IAppli's that are how the mobile applications for NttDocomo phones are called.

There is a big difference in development for NttDocomo phones when compared with the other two carriers and any other J2ME platform. NttDocomo uses a propietary profile called Doja instead of the standard MIDP profile.

There are core differences between MIDP and Doja that make them incompatible. For example in MIDP the main application class inherits from the MIDLet class while in Doja the main application class inherits from IApplication class. This kind of core differences and others (see here) makes it necessary to have two complete different versions of the source code (Doja and MIDP versions) if we want the application to run on as most platforms as possible.

If we ignore this incompatibility details then Doja is a great platform for developing applications for phones. I really found Doja development much easier and entertaining than the MIDP counterparts. Maybe because at the time Doja had much more functionality than MIDP. Current versions of MIDP may be by now as good as Doja but I bet Doja is even more powerful than it was before.

Doja Versions

There are several versions of Doja here in Japan and I now of at least two international versions that are used in other parts of the world. In Japan we have versions: 1.0, 1.50E, 2.0, 2.1, 2.50E, 3.0, 3.5, 4.0 and 4.1 and internationally we have versions: 1.5 and 2.5.

I will talk here how to use Japanese versions of Doja versions between and including version 3.0 to 4.1 since the procedure is exactly the same. I have not used the international versions and really don't know if they are excactly the same as the Japanese ones. For information (in english) of the international versions of Doja please refer to the Doja Development Network. All I can tell is that the information in this page is applicable to the Japanese versions of Doja as well.

Getting the IAppli Development Toolkits

All the necessary files for IAppli development can be downloaded from this page. The firsts links are development guides (pdf files) and java api documentation (zip files) for each of the Doja versions available. In the section that says something like アプリ開発ツールのダウンロード is were we can download the development toolkits. You can choose the version of Doja you want to develop but for this guide I have only tested versions 3.0 to 4.1.

Click in the version you want and a page with the requirements and a download link will appear. As usual you need a Windows2000/XP machine with Java2 SDK 1.4.X and for this guide you also need Netbeans with the Mobility Pack version 4.2 or 5.0.

Click in the download link (is in english) and a terms of use page appears. If you agree with the terms of use click in the link below that says 同意する and save the zip file on disk. The file is called emufordoja4_1_201.zip for Doja4.1. If you choose a different Doja version the file name may be different.

Unzip, click the install exe file and accept all the defaults. If you have doubts you can follow the instructions in this page since the steps are very similar to the Japanese versions of Doja.

If everything went OK you will have the tool installed in C:\iDKDoJaX.Y where X and Y are the version number of the Doja toolkit. In my case it is C:\iDKDoJa4.1. I must note that Doja4.1 comes with a plugin for Netbeans already but it does not use the Mobility Pack. This means that all the features that the mobility pack offers cannot be used with this plugin.

The idea of using Netbeans is the ability of the Mobility Pack to handle device partitions and the automatic application build process so I will not be using the plugin that comes with Doja. Also previous versions of Doja do not have this plugin making it difficult to develop applications that support several versions of Doja.

You can develop IAppli's with the toolkit alone following these instructions. In fact all the tutorials that you can find in the Doja Development Network should work in any version of Doja so if you are not interested in using Netbeans for Doja development stop reading this blog and study all the tutorials in the Doja Development Network page.

IAppli's with Netbeans

As with EzAppli's the Doja development toolkits are not UEI compatible so some manual work is needed in order to develop Doja applications with Netbeans. For Netbeans to detect the Doja toolkit as a J2ME platform we must create a platform definition file:

<?xml version='1.0'?>
<!DOCTYPE platform PUBLIC '-//NetBeans//DTD J2ME PlatformDefinition 1.0//EN' 'http://www.netbeans.org/dtds/j2me-platformdefinition-1_0.dtd'>
<platform name="iDKDoJa4.1" home="C:\iDKDoJa4.1" type="custom" displayname="NTT Doja 4.1" srcpath="${platform.home}/doja_stub_src.zip:${platform.home}/stub_src.zip:" docpath="${platform.home}/doc," preverifycmd=""{platformhome}/bin/preverify.exe" -classpath "{classpath}" -d "{destdir}" "{srcdir}"" runcmd="">
<device name="FOMA" securitydomains="trusted,untrusted" description="FOMA">
<configuration name="CLDC" version="1.0" displayname="CLDC1.0" classpath="${platform.home}/lib/classes.zip" dependencies="" default="true"/>
<profile name="DOJA" version="4.1" displayname="Doja4.1" classpath="${platform.home}/lib/doja_classes.zip" dependencies="" default="true"/>
</device>
</platform>

This platform definition file works for all Doja versions (3.0~4.1). Only make sure to change the version number (i.e. 4.1 with your version) and the path where the toolkit is installed in you machine.

Save this file as "Doja4.1.xml" and put it in the platform directory (\config\Services\Platforms\org-netbeans-api-java-Platform) in your user home directory (the Windows default is C:\Documents and Settings\{username}\.netbeans. If you installed more than one Doja toolkit create different files for each one (i.e. Doja3.0.xml, Doja3.5.xml and so on) making sure to change the version names and the installation path. Copy all these platform definitions files in the directory above.

Now when entering the Netbeans Java Platform Manager (Tools menu) you will see the Doja platform for all the toolkits you created xml files for.

The description file (JAM)

When creating mobile applications using the MIDP profile we need to create a description file (JAD file) that contains information about the application. In Netbeans this JAD file is generated for us and if we need to add attributes to the file (i.e. HTTP support) we can do it easily in the projects properties of Netbeans.

For Doja we need to create a similar file but is called JAM instead of JAD and has different attributes that a JAD file does not support. The best way I have found to create this file when building the project is to use the Eclipse Doja plugin. This plugin contain some ant tasks that make it easy to create the JAM file and since Netbeans build system is based on ANT tasks we can easily add support for the JAM file creation.

First we must download the Eclipse Doja Plugin from this page. Look for a file called jp.gr.ttj.Doja_0.0.1.zip and download it. Uncompress the file and look for a file called anttask.jar and copy it in a directory where the Netbeans ant can find it. I simply copy it in the projects directory but this means I must copy this file in each of the Doja projects I create.

HelloNtt example IAppli

Now the main part. To develop an IAppli using Netbeans we proceed as any normal MIDLet. We create a new "Mobile Application" project and follow the Netbeans dialogs selecting the projects name and folder. For this example create a project called HelloNtt. You can check the Set as main project box but uncheck the Create Hello Midlet box.

In the next dialog select in the Emulator Platform the NTT Doja 4.1 platform (or any other Doja platform you have installed) and finish the project creation process.

If the Doja emulators do not appear in the list box of emulator platforms then you forgot to create the platform definition xml file and copy them in the Netbeans platforms directory in your userhome as indicated above.

As I mentioned in the previous section we need to modify the building process of Netbeans to create a JAM descriptor file. For this we need the anttasks.jar file that comes with the Eclipse Doja plugin (see previous section). Copy the anttasks.jar file inside the newly created project directory (i.e. HelloNtt) and open the build.xml file inside there.

You must add the following targets in between the <project> and </project> tags in the build.xml file:

        <target name="post-jar">
        <taskdef name="file" classname="jp.gr.ttj.ant.FileTask">
            <classpath>
                <pathelement location="anttask.jar"/>
            </classpath>
        </taskdef>
        <taskdef name="date" classname="jp.gr.ttj.ant.DateTask">
            <classpath>
                <pathelement location="anttask.jar"/>
            </classpath>
        </taskdef>
        <file property="jarsize"  type="size" file="${basedir}/${dist.dir}/${dist.jar}"  />
  <date property="TODAY_i" pattern="E, dd MMM yyyy HH:mm:ss" />
        <echo file="${dist.dir}/${name}.jam">
LastModified = ${TODAY_i}
AppClass = ${name}
AppName = HelloNtt
PackageURL = http://www.mypage.com/${name}.jar
AppSize = ${jarsize}
UseNetwork = http
SPsize = 102400
 </echo>
    </target>
    
    <target name="run" depends="init,jar">
 <exec executable="${platform.home}/bin/doja.exe" dir="${dist.dir}">
  <arg value="-i" />
  <arg value="${name}.jam" />
 </exec>  
    </target>    
    
    <target name="post-clean">
         <delete file="${dist.dir}/${name}.jam"/>
    </target>

Only look where it says AppName and PackageURL. These are the most important attributes of the JAM file and MUST be setup to reflect your application. The AppName is simply the name of the application you are developing. The one that will appear in the phone when the application appears in the list of IAppli's installed in the phone. The PackageURL is the URL address from where the IAppli is to be downloaded. This URL is not important when running from an emulator but must be the real URL from where the IAppli is to be downloaded when deploying to real phones.

The UseNetwork and SPsize attributes tell that the IAppli can use http connections and the Scratch Pad (Persistent Storage) respectively. They are not required for our little HelloNtt example but you may need them for more interesting applications.

Please make sure that all attributes that are to be written to the JAM file have no white spaces to the left in the build.xml file. This way there will be no spaces to the left in the JAM file. All the attributes you add must be in between the <echo> and </echo> tags.

If you understand how ANT works you may see that there is also a run task there. This task simply invokes the Doja.exe emulator with the JAM file as parameter. You may be also define a debug task to use the Dojag.exe emulator that supports debugging functions like limited phone memory and storage.

HelloNtt Source code

The little example here is gonna be very different from that used for EzAppli and S!-Appli mostly because Doja is different. Within the project's context menu (right click) select New->MIDLet and in the dialog that appears input the IAppli name (HelloNtt). A new java source will be created in the src directory of the project. Delete everything in that file and put the following code:

import com.nttdocomo.ui.*;

public class HelloNtt extends IApplication {   // --- (1)

    public void start() {
        Display.setCurrent(new MyPanel());      // --- (2)
    }
    
    class MyPanel extends Panel implements ComponentListener{
    // --- (3)
        /**--- (4) ---**/
        private Label lbl = new Label("Your Name");
        private TextBox tbx =
        new TextBox("",16,1,TextBox.DISPLAY_ANY);
        private Button btn = new Button("Press");
        
        public  MyPanel(){
            /**--- (5) ---**/
            add(lbl);
            add(tbx);
            add(btn);
            
            setComponentListener(this);         // --- (6)
        }
        
        public void componentAction
        (Component source, int type, int param){
            /**--- (7) ---**/
            if(source == btn){
                Dialog d =
                new Dialog(Dialog.BUTTON_OK,"Message");
                d.setText("Hello " + tbx.getText());
                d.show();
            }
        }
    }
}

This example was taken from the beginners section of the Doja Development Network page without any modification.

Now simply build and run the project as any other Netbeans project and you should see the Doja emulator being launched with your newly HelloNtt IAppli on it.

Now with this part 3 of the blog you should be able to develop mobile applications for all the three major cellular phone carriers in Japan. EzAppli's for au/KDDI, S!-Applis for Softbank and IAppli's for NTTDoCoMo.

Developing for Japanese Phones in Netbeans (Part 2)

S!-Appli (Softbank) Development in Netbeans

In the previous post I explained a little about development of mobile applications for Japanese cellular phones. In that post I only touched development for Ez-Applis that are applications for Au(KDDI) phones.

In this post I will explain how to develop S!-Applis that are simply mobile applications for Softbank phones.

Some history

Before there was Vodaphone and the applications that ran on Vodaphone phones were called V-Applis. Developing V-Applis was exactly the same as any MIDLet using the Wireless Toolkit with the addition of the JSCL profile (J-Phone Specific Class Library). So in short a V-Appli was a MIDLet using the MIDP-1.0 plus a JSCL profile.

There were several JSCL profiles and different phones that supported those profiles. There was also an JSCL in steroids called MEXA (Mobile Entertainment eXtension API) that added some multimedia, sound and graphic capabilities to the phones. Here is a list of the phone models and the profiles they supported.

• C4 Model Phones -> MIDP-1.0


• P4 Model Phones -> MIDP-1.0 + JSCL-1.1.0


• P5 Model Phones -> MIDP-1.0 + JSCL-1.2.0


• P6 Model Phones -> MIDP-1.0 + JSCL-1.2.2


• P7 Model Phones -> MIDP-1.0 + JSCL-1.3.2


• S Model Phones -> MIDP-2.0


• X Model Phones -> MIDP-2.0 + MEXA/JSCL

Each profile had it's own toolkit that you needed to download in order to develop V-Applis. These toolkits only contained the emulator binary and the JSCL jar file. To compile, preverify and pack the V-Appli you needed to use the Wireless Toolkit and Java Development SDK (> 1.3).

Vodaphone Japan was then adquired by Softbank and V-Applis were replaced by S!-Applis. All the V-Appli toolkits disappeared from the web and were replaced by the S!-Appli toolkit. Fortunatelly the only thing that changed was the name. Developing an S!-Appli is exactly the same as an V-Appli. The only differences is that the S!-Appli toolkit supports all JSCL profiles from JSCL-1.0.x to JSCL-1.3.2 profile.

I am unable to find the V-Appli toolkits in the web so this post will be about S!-Appli toolkit. In any case this toolkit includes all the previous profiles so the other toolkits are unecessary.

Getting the S!-Appli toolkit

The download page is here. Simply go were it says S!アプリ開発ツール and click were it says something like エミュレータ.

You will be asked to accept the copyright and term of use. Simply click where it says　同意する　twice. You will have to fill a little form. The first two fields put your name, next your email address and finally select your development environment settings. In the next page click in the download link and you will get a file called S_Appli_Emulator_JSCL-1.3.2.zip.

Uncompress, run the installation exe and accept all the defaults. This will install the toolkit in the directory C:\S_appli_SDK_132. You can change this directory but make sure the path has no spaces in blank.

S!-Appli with Netbeans

All Vodaphone toolkits and the Softbank toolkit are UIE compliant so using them with Netbeans is a breeze. In Tools->Java Platform Manager in the menu of Netbeans press the Add Platform button. In the next panel select Java Micro Edition Platform Emulator and press next. In the next dialog all toolkits that Netbeans sees will appear in a list. If the Softbank toolkit is not in the list (most probably won't be) press the Find More Java ME Platform Folders... button and select the directory were you installed the toolkit (i.e. c:\). You will get the list of all toolkits installed in that directory. Simply check the toolkits you want added to Netbeans and press next.

Now in the Java Platform Manager in the J2ME section should appear the newly installed toolkit and that's it!! we are ready to develop S!-Applis.

Hello Softbank

Developing an S!-Appli is exactly as an Ez-Appli or a normal MIDLet. In the Netbeans File menu we select new project and select a Mobile Application as usual. Create the MIDlet you want and build/run from the project's context menu (right click).

Here is a little test MIDLet for a S!-Appli:

/*
 * HelloSoftbank.java
 *
 * Created on 2006/10/03, 13:10
 */

import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;

/**
 *
 * @author  panama
 * @version
 */
public class HelloSoftbank extends MIDlet {
    public void startApp() {
        Display.getDisplay(this).setCurrent(new HelloCanvas());
    }
    
    public void pauseApp() {
    }
    
    public void destroyApp(boolean unconditional) {
    }
    
    
    public class HelloCanvas extends Canvas {
     
        private final Font sFont = Font.getFont(Font.FACE_MONOSPACE ,Font.STYLE_PLAIN ,Font.SIZE_MEDIUM );
        String s = "Hello World";
        
 public void paint(Graphics g) {
            g.setColor(0,222,100);  
            g.setFont(sFont);
            g.drawString(s, (getWidth() - sFont.stringWidth(s)) /2,getHeight()/2,Graphics.TOP|Graphics.HCENTER);
 }
    }
}

There is a little problem that does not allow the excecution of the Emulator from within Netbeans. I am not sure if it is a problem of Netbeans or the Softbank toolkit . The problem seems to be that Netbeans gives the wrong path of the jad file to the emulator and the emulator complains with a "File not found" error.

The work around this problem is to change the "Running" properties of the project to give the correct path. To do this simply enter the project properties (right click) and select the "Running" section.

In the "Emulator_Command Line Options" text box write the following line. Making sure to change the paths to reflect your configuration:

-Xdevice:"S!_Appli_Universal_JSCL1_3_2" -Xdescriptor:"C:\path\to\project\dist\project.jad"

This way we can call the emulator from within Netbeans. The only disadvantage is that we must modify this configuration for each new project we create. Maybe future versions of Netbeans will fix this problem.

Final Notes

As we can see developing S!-Applis is not different than a normal MIDLet until we start using the JSCL classes. These classes allow us to manage the phone's hardware for example and with MEXA we get 3D graphics, 3D sound, etc.

Since the applications I develop must run in as many devices as possible I do not use the JSCL/MEXA classes nor the KDDIP classes that come with Ez-Applis. This way my applicatications can run with only minor modifications in au phones and Softbank phones.

If you are interested in using MEXA in your applications you need to download the MEXA SDK Ver1.1.0 from here. This SDK seems to come with a complete development environment and it is not recognized by Netbeans as UIE compliant. Maybe if someday I require to use MEXA for a project I will try to integrate it with Netbeans but is very unlikely to be any time soon.

Doja IAppli's

In the next part of this series of post I will talk about NTTDocomo's IAppli. An IAppli is different from Ez-Applis and S!-Applis because they do not use MIDP. IApplis use Doja and as MIDP there are several versions of Doja(1.0 to 4.1).

I will explain how to create Doja Platform Profiles for Netbeans and create a little test IAppli. If time permits me I will also try to point out the most important differences between Doja and MIDP that have caused me development headaches.

Developing for Japanese Phones in Netbeans (Part 1)

Netbeans Mobility Pack

Developing for J2ME applications for the primary carriers in Japan can be a living nightmare. There are three main mobile phone carriers in Japan: au/KDDI, Voda Phone (now Softbank) and NttDocomo. Each of these providers have a midraid of phones of all sizes and capabilities and each week there are new ones. Here in Japan people change phones as often as their underwear...

For a J2ME application to be successful it must be compatible with the current phones used at the moment which means that development never stops and evolves very, very fast. As new phones come with new MIDP profiles and propietary extensions programming this little MIDLet's is a new experience each time.

I am a VIM guy and I am used to develop huge enterprise projects and web applications in a console with screen+vim. But for J2ME development I really recomend an IDE especially Netbeans with it's preprocessor to handle device fragmentation.

Developing a J2ME application requires several steps like class preverification, ofuscation, signing, packing, deployment. These steps can vary from carrier to carrier and even from phone to phone of the same carrier. A single change on the source code would require to excecute all these steps for each phone of each carrier and doing by hand is tedious and error prone. This gets worse if we have a different source code for each phone (Device Fragmentation Problem).

The Mobility Pack of Netbeans is a lifesaver in this case with support for several configurations in a single project. But life is not perfect and the only carrier that provide UIC compliant development environments is Voda Phone. To develop au and NttDocomo applications in Netbeans we must do some magic.

Installing Ez Appli's (au/KDDI) Toolkit

To develop an Ez Appli we need to download the tool kit Ez Appli. Just click where it says 同意する that means you accept the agreement. In the next page click where it says ダウンロード to download the tool kit. You will end with a file called "ezplus_emulator.exe".

You can also download a programming guide and the KDDIP javadoc files from this page but they are useless if you cannot read Japanese.

To install the tool kit simply double click the exe file and accept any defaults you get except for the install directory part. When the installation programs asks for an installation path make sure the path has no blank spaces. I have found the emulator cannot understand spaces on the path names.

From now on I assume the toolkit is installed in c:\ezplus. Inside that directory must be an structure like:

-- Doc               -> PDF files with manual and guide
-- Tools
   -- CmdTool        -> Development Tools
   -- Emulator       -> Contains the phone emulator
   -- KDDIP          -> Contains the KDDIP library

Steps for Ez Appli Development

There are several steps involved in developing an Ez Appli. The tool kit contains a CmdTool that sorts of eases the job but is not that feature rich. Ez Appli development is very similar to J2ME MIDLet development. We need to create a MIDLet (jar file) and a Description file (jad file). This includes preverification and ofuscation of the classes and source code etc.

When developing MIDLets the jar and jad files are enough to run the application. In the case of Ez Appli we must create a KJX file using the KJXArchiver.jar that comes with the toolkit. All au phones need this KJX file to excecute the application.

All these steps can be done manually or by using the CmdTool that comes with the tool kit. As I said this can be error prone and tedious when there are several versions of the source code to support several devices.

Ez Appli configurations and profiles

Ez Appli's use the CLCD1.0 configuration and the MIDP1.0 profile combined with the au custom profile KDDIP. The KDDIP profile simply adds classes to control the phones hardware (backlight, vibration, etc) and to access services specific to au (c-mail, smarf, e-mail, etc.). If you can read a little japanese then the documentation that comes with the tool kit can give you an idea of what you can do.

Fortunatelly since we want to create applications that run equally in all carrier phones we must avoid all custom classes. This completely eliminates KDDIP classes from the picture and we end with MIDP1.0. This means that we can write a MIDLet using the J2ME english documentation available on the net and it will run without too much problems on au phones and hopefully also run on Vodaphone phones.

Even without using the KDDIP profiles we must understand some physical limitations present on the phones that depend on the profile they can run. There are several versions of KDDIP profiles listed below:

Version	KXJ Size	RecordStore Size
Phase1	50KB	10KB
Phase2	50KB	10KB
Phase2.5	50KB	10KB
Phase3	150KB	10KB + 100KB extended

The KJX size refers to the maximum size the Ez Appli can have. Any KJX file larger than the limit will not download to the real phones even if it runs well on the emulator. The RecordStore limit refers to the max amount of persitent storage the phone can handle.

Ez Appli Development With Netbeans

With Netbeans is easy to add new J2ME development platforms in the Tool->Java Platform Manager->Add Platform dialog. With this dialog we can simply point to the directory where the tool kit is installed and all the black magick is done for us.

Unfortunatelly this only works for tool kits that comply with the UEI (Universal Emulator Interface) standard and the Ez Appli toolkit is not compatible. But don't despair! we can add custom tool kits with some work. Essentially what we need to do is to tell Netbeans the steps it must follow to create an Ez Appli.

For au I took the time to generate the platform definitions for the KDDIP Phase1 and Phase2 profiles.

Phase1.xml file:

<!DOCTYPE platform PUBLIC '-//NetBeans//DTD J2ME PlatformDefinition 1.0//EN'
             'http://www.netbeans.org/dtds/j2me-platformdefinition-1_0.dtd'>

<platform name="ezplusTool" home="C:\ezplus" type="custom"
      displayname="KDDI Phase1" srcpath="" docpath="${platform.home}/doc"   
      preverifycmd=""C:/WTK22/bin/preverify.exe"
      -classpath "{classpath}" -d "{destdir}"
      "{srcdir}""
      runcmd=""
>
 <device name="C452CA/C451H" securitydomains="trusted,untrusted" description="Phase 2 Devices">
     <configuration name="CLDC" version="1.0" displayname="CLDC1.0"
               classpath="C:/WTK22/lib/cldcapi10.jar" dependencies="" default="true"/>
    
     <profile name="KDDIP" version="1.0" displayname="KDDIP1.0"
                   classpath="C:/WTK22/lib/midpapi10.jar;${platform.home}/Tools/KDDI-P/kddip.jar"
                   dependencies="" default="true"/>
       </device>

</platform>

Phase2.xml file:

<!DOCTYPE platform PUBLIC '-//NetBeans//DTD J2ME PlatformDefinition 1.0//EN'
'http://www.netbeans.org/dtds/j2me-platformdefinition-1_0.dtd'>>
<platform name="ezplusTool" home="C:\ezplus" type="custom" displayname="KDDI
 Phase2" srcpath="" docpath="${platform.home}/doc"
 preverifycmd=""C:/WTK22/bin/preverify.exe"
 -classpath "{classpath}" -d "{destdir}"
 "{srcdir}""
 runcmd="">
 
 <device name="C3001H/C3002K/C5001T/A3011SA/A3012CA/A3013T/A3014S"
  securitydomains="trusted,untrusted" description="Phase 2 Devices">
    
  <configuration name="CLDC" version="1.0" displayname="CLDC1.0"
   classpath="C:/WTK22/lib/cldcapi10.jar" dependencies="" default="true"/>
 
  <profile name="KDDIP" version="2.0" displayname="KDDIP2.0"
   classpath="C:/WTK22/lib/midpapi10.jar;${platform.home}/Tools/KDDI-P/kddip.jar"
   dependencies="" default="true"/>
       </device>

</platform>

These are simply XML files that defines the environment needed to build Ez Appli's. You do not need to understand the syntax and simply save them inside the "Services\Platforms\org-netbeans-api-java-Platform" directory inside your .netbeans config directory.

From the definition file you can see that the Ezplus toolkit makes use of the preverify command and the midpapi.zip library from the Wireless Toolkit. Make sure you set the path to these two files to reflect the installation path of the Wireless Toolkit in your machine. If you do not have the Wireless Toolkit installed you can use the one installed with Netbeans. I have tested these platform definitions files with Netbeans 4.1 and 5.0 without any visible problems.

Also make sure the path to the kddip.jar file coincides to the path where you installed the Ezplus toolkit.

After saving this files in the appropiate place when you restart Netbeans you will see the two new platforms added to the list of J2ME Platforms in the Java Platform Manager of Netbeans. They will be called KDDI Phase1 and KDDI Phase2 respectively.

Ez Appli Hello World

Now we can try to develop a simple Hello World Ez Appli. With Netbeans create a new Mobile Application Project (File->New Project->Mobile->Mobile Application) and proceed with the project creation dialog as normal until you get the the Default Platform Selection dialog. Here make sure to select any of the new platforms as default platform. The CLCD1.0 and KDDIP1.0/KDDIP2.0 will be selected automatically depending on the profile you chose.

Next select other platforms templates if you want and finish the creation process. At this point we should have a new Mobile Project ready to start development. Before we compile we need to modify the build.xml script a little to handle the KJX file creation and to invoke the Ez plus emulator when running the project. To do this simply open the build.xml file of the project and add these tags inside the <project> and </project> tags.

 <target description="Create AU KJX file" name="post-jar">
    <java jar="${platform.home}/Tools/CmdTool/KJXArchiver.jar" fork="true">
       <arg line="-c ${dist.dir}/${dist.jad} ${dist.dir}/${dist.jar} {dist.dir}/${name}.kjx">
    </java>
 </target>
  
 <target name="run" depends="init,post-jar">
    <exec executable="${platform.home}/Tools/Emulator/run.bat" dir="${dist.dir}">
        <arg value="${basedir}/${dist.dir}/${name}.kjx">
    </exec>  
 </target>   

The code above defines two ant tasks in the build.xml file. One is to generate the KXJ file using the KJXArchiver that comes with the Ezplus toolkit. The other task is to call the emulator with the created KJX file. This task requires a run.bat file I generated to call the emulator. Simply copy the next file a run.bat inside the Emulator subdirectory of the Ezplus toolkit:.

@echo off
cd C:\j2me\ToolKits\ezplusTools\Tools\Emulator
javaw -jar jbmidp.jar %1

Of course make sure you change the path to reflect that of your machine. With the build.xml file in order we can now create a simple MIDLet as usual. With the project select create a ne MIDLet (Right Click->New->MIDLet) and edit the source as a normal MIDLet. Here is my example source code:

import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;

public class HelloKddi extends MIDlet {
    public void startApp() {
        Display.getDisplay(this).setCurrent(new HelloCanvas());
    }
    
    public void pauseApp() {
    }
    
    public void destroyApp(boolean unconditional) {
    }
    
    public class HelloCanvas extends Canvas {
 public void paint(Graphics g) {
            g.setColor(0,222,100);                  
            g.drawString("Hello World",40,20,Graphics.TOP|Graphics.HCENTER);
 }
    }
}

If you have ever programed a MIDLet for any other mobile device based on the MIDP profile you will see that these one is identical.

Now we can build and run this application as any other Netbeans project with the context menu (right click). Not only that we can now add new configurations to the project and use all features of the Mobility Pack to develop for au (KDDI) phones.

Notes

I was able to create platform configurations for Phase1 and Phase2 of the Ezplus toolkit. For Phase2.5 and Phase3 there is a different toolkit but I am unable to make it work with Netbeans. In fact I am not able to develop with that toolkit even with the CmdTool that comes with it.

Since au gives priority to the Brew platform and not to J2ME the kind of applications we can develop for au phones is very limited. If you want to develop rich applications for au Phones you better start learning Brew.

In subsequent posts I will talk about Vodaphone (JSCL/MEXA) and NttDocomo (Doja) development using Netbeans.