Program █ to debug MIDlet
When writing the Spotlet on PalmOS, we can use SYSTEM.OUT.PRINTLN () function to help us print some messages to help debug, what about the MIDlet on the phone? In principle, we can still use the SYSTEM.OUT.PRINTLN () function to do some output. When the emulator executes, it prints out some messages on the command line.
In addition, on the PalmOS, there are KVMUTIL.PRC that can help us to record the message that the program outputs. What about the phone? Because there is no actual machine to test, so the problem is still unknown, I believe Motorola will have a perfect solution!
In the description file enclosed in the Motorola J2ME SDK, a brief reference is made to the issue of debugging, which mentions that, in the future, if we are going to debug on the machine (On-device debugging), several conditions must be met:
- The machine itself has debugging-related functionality and is compatible with KDWP (KVM Debug Wire Protocol). Because debugging tools need to use KDWP and machine conversations to get debugging information.
- The manufacturer itself provides a way to download MIDlet to the phone for debugging.
- To provide tools for MIDlet debugging, you must support the transport interface (such as serial port or UDP) that your phone uses when using KDWP debugging.
Well, it seems to be able to debug, midlet program writing should be very convenient things.
█motorola J2ME SDK Support for Chinese
I believe I've seen run!. The PC November article "using Java to write PalmOS application Infrastructure" readers, in the writing PalmOS on the Spotlet must encounter the Chinese can not normally display problems. The Chinese question is divided into two parts, one is in the user interface Chinese question, one is in the command column output (utilizes SYSTEM.OUT.PRINTLN () the output which does) on the Chinese question, invites everybody to do a small experiment, will the previous we prepared the procedure to change as follows:
Hellomidlet.java
Import javax.microedition.lcdui.*;
Import javax.microedition.midlet.*;
public class Hellomidlet extends MIDlet
{
Private Display Firstdisplay;
Private Form Firstform;
Hellomidlet ()
{
Firstdisplay = Display.getdisplay (this);
Firstform = new Form ("Hello! MIDlet ");
Stringitem Firststritem = new Stringitem ("Hello", "Midret");
Firstform.append (Firststritem);
System.out.println ("MIDlet start");
}
protected void startApp () throws Midletstatechangeexception
{
Firstdisplay.setcurrent (Firstform);
}
protected void Pauseapp ()
{
}
protected void Destroyapp (Boolean unconditional)
Throws Midletstatechangeexception
{
}
}
After compiling this midlet and approving it, we turn on the simulator to execute the MIDlet, following the execution result:
user interface output:
command-column outputHttp://www.csdn.net/expert/wangsen/artic013.jpghttp://www.csdn.net/expert/wangsen/artic014.jpg we found from the results, A preset compilation directive will allow the user interface to output the Chinese correctly, while the command column cannot print the correct Chinese.
We found from the results that the preset compilation instructions would let the user interface normally output Chinese, and the command column could not output the correct Chinese.
Then please put the original instructions in the Compileall.bat
Javac-o-bootclasspath. \.. \lib%compileclass%
Amended to
javac–encoding iso8859_1-o-bootclasspath. \.. \lib%compileclass%
After that, recompile this midlet execution result:
user interface output:
command-column outputHttp://www.csdn.net/expert/wangsen/artic015.jpghttp://www.csdn.net/expert/wangsen/artic016.jpg we found from the results, A preset compilation directive will allow the user interface to output Chinese correctly, while the command column can output the correct Chinese.
This result differs from the Chinese test results on PalmOS.
When you write Spotlet, if you use Javac ... Instructions, you will find that the user interface on the emulator output is garbled, but the output on the command line can normally output Chinese. But if you are using the javac-encoding iso8859_1 ... Instructions, the CLDC enclosing the emulator on the output of the user interface or the output of the command line all become garbled, unable to output the normal Chinese (this part is because the CLDC enclosing the simulator to do the problem, resulting from the actual machine results are different).
In short, if you have previously written spotlet can not be installed in the Chinese system of the actual machine or pose normal output Chinese, please do the same, in the compilation instructions to add-encoding iso8859_1, you can in the actual machine or pose see the normal Chinese characters.
The main reason for this problem is that all of the text encodings are UTF8 in the compiled Java class file (byte code). For example, when you use the words "Start" in a program code,
The BIG5 code for the word "up" is b1d2.
The BIG5 code for the word "move" is b0ca.
We will use Javac Xxxx.java to compile the source code to produce the class file. In fact, this line of instruction, under the Traditional Chinese Windows environment, is equivalent to javac-encoding "Big5" Xxxx.java. That is, when the compiler reads the text in the BIG5 encoding range, it automatically passes the BIG5 code through the "big5èunicode table" to convert Big5 to Unicode, which means that after checking the tables,
The Unicode encoding of the word "up" is 555F.
The Unicode encoding for the word "move" is 5272.
The Unicode is then converted to UTF8 and stored in the class file using UTF8 encoding, so if you view the class file with a text editor such as UltraEdit, you will see that the
The UTF8 code for the word "up" is e5959f.
The UTF8 code for the word "move" is e58b95.
Then, when we output the Chinese in the execution of the program, the JVM is responsible for reading the UTF8 code, then returning it to Unicode, and then to the Big5, and then to the screen, based on the preset encoding of the system environment you are using.
However, after the test results, the KVM seems to be only able to read the UTF8, converted back to Unicode after the direct output. Less the step back to Big5, therefore, the operating system as a Big5 to deal with Unicode, nature can not find the corresponding text in the code, and therefore the output is a bunch of????? The symbol. This is also our PalmOS even if the Chinese system installed, it is not normal to display Chinese.
OK, since we know that KVM only helps us do half of the work, that thing is good to do, we just let UTF8 back, still retain Big5 encoding way, so we use the command javac-encoding iso8859_1 Xxxx.java, the compiler should not consider the two-byte encoding of the Chinese BIG5 encoded in the code as one (because it would trigger the work of the query Big5èunicode table), as long as the Chinese is regarded as a common Western European alphabetic word set, so when we use the above instructions, You will find that the Chinese in the class file becomes,
The UTF8 code for the word "up" is c2b1 C392.
The UTF8 code for the word "move" is c2b0 c38a.
You can find that the compiler treats B1, D2, B0, CA individually as a code. As a result, when the KVM reads this code, it will turn them back to B1D2 and B0CA, then the KVM can be exported directly, and the Chinese will be used normally.
Finally, summing up the whole problem, I infer that the CLDC containing the simulator is no longer used
javac–encoding iso8859_1 Xxxx.javadirective, the command column will be output garbled in the user interface, which is the normal result, and the Motorola J2ME SDK contains the emulator's user interface Chinese is not a problem, it is likely only because of the difference between the simulator operation. So according to the KVM output, it's possible that on the actual phone, we have to add
-encoding iso8859_1option to correctly export the Chinese bar!
In particular, I would like to thank Tang Qia (Kailung.tang@msa.hinet.net), a student at the University of Providence. Because the author after a heated discussion, we can have a more in-depth understanding of the Chinese problem of J2ME
█ support development tools for Motorola J2ME SDK
When writing this article, the Integrated development environment (IDE) that supports MIDlet development is only the CodeWarrior mentioned in the Motorola J2ME SDK companion file. It is believed that other vendors, such as Borland, should also quickly use their products JBuilder Opentools APIs to support midlet development, not to mention Borland JBuilder currently has spotlet solutions.
Because the author can not get CodeWarrior for testing, so I can not provide you with the relevant information, I believe that if there is a chance, will also be a special article to introduce how to use CodeWarrior to write MIDlet.
Motorola J2ME SDK accompanying files in the appendix part of the use of CodeWarrior development MIDlet do a simple introduction, I believe that for beginners, is quite enough.
█motorola J2ME SDK-embedded auxiliary development tools
The Motorola J2ME SDK contains three additional development tools to facilitate our program development work, which are:
- J2ME Simulator (J2ME emulator)
Allows you to simulate Motorola's future support for J2ME mobile devices on your PC. This allows you to test the written program directly on your PC.
- Bytecode validator (bytecode Verifier)
This validator is used to verify that the bytecode in the class file (Classfile) does not illegally access the memory. and confirm that all the actions of the class files loaded into the virtual machine conform to the Java Virtual Machine specification (Java Machine specification).
- Configuration Editor (Configuration Editor)
Allows you to create or modify device profile.
The three tools are detailed in the file enclosed in the Motorola J2ME SDK, and I will not repeat them here.
█ Summary
It's so tiring, it's time to make a summary! Do you think the MIDlet is over? MIDlet has lots of fun stuff! We will explore the midlet in more detail in the articles after this series. We'll see you next time.
█ Appendix: Sample Procedures
There are a number of interesting examples in the Motorola J2ME SDK, which are located under the demo/midlets/directory. Readers who are interested in continuing to Excel can learn more about MIDlet by these examples, because these examples are too large to execute, so they are omitted in this article and readers are asked to refer to the documentation themselves.
These sample procedures are:
Bounce
Com.mot.j2me.midlets.bounce.Bounce
Paddleball
Com.mot.j2me.midlets.paddleball.PaddleBall
Scribble
Com.mot.j2me.midlets.scribble.Scribble
Fontdemo
Com.mot.j2me.midlets.tutorials.FontDemo
Graphicsdemo
Com.mot.j2me.midlets.tutorials.GraphicsDemo
Recordstoredemo
Com.mot.j2me.midlets.tutorials.RecordStoreDemo
UDP Tutorial Application
Com.mot.j2me.midlets.tutorials.UDPReceive
Alerttest
Com.mot.j2me.midlets.tests.AlertTest
Choicegrouptest
Com.mot.j2me.midlets.tests.ChoiceGroupTest
Datefieldtest
Com.mot.j2me.midlets.tests.DateFieldTest
Formtest
Com.mot.j2me.midlets.tests.FormTest
Gaugetest
Com.mot.j2me.midlets.tests.GaugeTest
Keyeventstest
Com.mot.j2me.midlets.tests.KeyEventsTest
Textboxtest
Com.mot.j2me.midlets.tests.TextBoxTest
Textfieldtest
Com.mot.j2me.midlets.tests.TextFieldTest
Tickertest
Com.mot.j2me.midlets.tests.TickerTest
█ network resources
Site
Name URL
Motorola official website http://www.motorola.com/java/
Metrowerks (CodeWarrior) http://www.Metrowerks.com
