The kxml of the xml| syntax Enhydra is an XML parser that takes up only a small storage space and is ideal for J2ME applications. It has a very unique dom manipulation method and a syntax analysis method called Pull.
In developing a multiplayer game project for J2ME devices. In this application, the communication between the server and the device was originally encoded into a "&"-delimited key-value pair, so retrieving variables from the server would be quick, but when I started working with more complex data structures and nested data structures, I found that this approach did not apply. In this case, it becomes difficult to write data and error prone.
To solve this problem, I decided to rewrite the data transfer section of the application using XML. For me, XML is a natural choice, not least because I have used it to write a program in a previous project that sends information over the network to the applet, and because XML is really easy to debug and write. Of course, it also allows you to use a rich format to structure the data. However, to my surprise, I found a precious gem for my programming toolbox.
Kxml is a simplified class library designed for J2ME devices, although it can also be used for other environments that require small XML parser applications, such as applets. Kxml is a Enhydra maintenance project that supports the following performance:
Supports XML namespaces
Parsing HTML or other SGML formats with "loose" mode
Takes up very little storage space (Kbps)
The analysis based on pull
Supports XML write operations
Optional DOM Support
Optional WAP Support
In this article, some of these features are described in detail, especially pull parsing and DOM operations, and I'll show you how to check the effect of kxml operations in memory. The two MIDlet routines in this article have complete source code that can show you how to use Kxml (click to download). The Kxml class library is not included in the Ktoolbar 1.04 project-You must obtain the class library from the http://KXML.enhydra.org/and place the compressed file in the project's "Lib" directory.
working with XML
There are two common ways to work with XML: Manipulate the DOM or capture parsing events. Manipulating the DOM is a simple way of interacting with XML, which is usually a complete XML tree that is parsed into a node structure stored in memory that you can traverse. It's very easy to use, but because the entire tree exists in memory, it creates a burden on the memory.
In the second method of capturing a parsing event, whenever the parser encounters a specific structure in the data, it traverses the XML data and sends the result back to the previously registered event listener. For example, when the parser encounters a start tag, such as
Kxml supports DOM parsing and manipulation, but does not support push parsing. Instead, it uses a slightly different method of analysis called "Pull". Contrary to push grammar analysis, pull parsing allows programmers to "pull" the next event from the parser. In push parsing, you have to maintain the state of the current data that you are analyzing, and then restore any previous state based on the events that are transmitted to the listener, and save the new state when you switch to a different state. Pull parsing makes processing state changes easier because you can send parsers to different functions and maintain their own state variables.
Pull Grammar Analysis
Let's look at an example of how Kxml does a pull parser. The demo program is named Kxmldemo_pull. It will use a pull parser to view a file containing the Address book information. Here are some of the more important lines in the source code, and I gave them a comment.
1.XmlParser parser = null;
2. ...
3.parser = new Xmlparser (New InputStreamReader (1this.getclass (). getResourceAsStream (Resfile_name)));
The third line creates a xmlparser and uploads it to a inputstream. This parser is invoked repeatedly until the End_document event occurs.
1.while (event = Parser.read ()). GetType ()!= xml.end_document) {
2...
3.if (name!= null && name.equals ("Address")) {
4...
5. Parseaddresstag (parser);
The third line determines whether the event starts with a <address> tag, and the fifth line passes the parser to the "Parseaddresstag" of the control parser.
1.while (event = Parser.peek ()). GetType ()!= xml.end_document) {
2...
3. if (type = = Xml.end_tag && name.equals ("address") {
4. return;
5.}
6...
7. Parseevent next = Parser.read ();
8.
9.//If it ' s not a text event then skip it
if (Next.gettype ()!= xml.text) {
Continue;
12.}
13...
SYSTEM.ERR.PRINTLN (name + ":" + text);
The above code loops through "Parseaddresstag" until it finds the stop tag corresponding to <address>. If it encounters any other tag, the tag name and tag contents are printed to the console. Therefore, if you find the tag <name> Robert Cadena </name>, you will see the following console output:
Name:robert Cadena
Once you find the <address> end tag (8-10 rows), the control is returned to the calling function, and then the lookup starts again. <address>
As you can see, using the pull parser is very easy, and it is able to transfer the parser to another function, and then find the elements in the document. You are not limited to analyzing resource files; You can also use Httpconnection to pass this function to the HTTP InputStream. This frees you from reading InputStream, saving content, analyzing content and so on, and everything is done by Kxml for you.
DOM Processing
Pull parsing is especially useful when you need to maintain very small storage space because only a portion of the document that emits the event exists in memory. In other words, if you are interested in a particular segment of data that is hundreds of bytes in the middle of the document, the preceding hundreds of bytes need not be saved in memory.
But if you can save some memory, you can use another version of the Kxml parser, which includes support for the DOM. The DOM is the entire document tree that is saved in memory, and each tag is separated into node objects. You can traverse the tree of the document and then get the data as needed.
Another midlet,kxmldemo_dom in the project did the same thing. It reads an address book and then prints the content to the console, but this time it uses the DOM. Here are some of the more important lines in the source code.
1.Document doc = new Document ();
2...
3.parser = new Xmlparser (ISR);
4.doc.parse (parser);
The first line creates a document and saves the XML tree. The third line creates a Kxml parser from a inputstreamreader named ISR. Line four sends the parser to the document and then lets the document begin parsing. XML is recursively parsed until the end of the document is reached. When the parse call exits, the entire document is loaded into memory, and you can manipulate it.
1.Element root = Doc.getrootelement ();
2.int Child_count = Root.getchildcount ();
3...
4.for (int i = 0; I child_count i++) {
5...
6. Element Kid = root.getelement (i);
7.
8. if (!kid.getname (). Equals ("Address")) {
9. Continue;
10.}
Because we know that the <address> element is a direct child of the root element, we can iterate through the child elements of the root element, look for the address tag, and return if the child element is not an address tag.
1.int Address_item_count = Kid.getchildcount ();
2.
3. for (int j = 0; J Address_item_count; J + +) {
4...
If we find the address child element, we begin to iterate through its child elements and print out the contents of the child elements. Unfortunately, you can't just use Kid.getelement ("name"), because if this element doesn't exist, then you'll get a runtimeexception. So I suggest that you use this method only if you know all the fields you need in the XML document.
Check your memory
According to experience, you should use the pull parser when you are unable to ensure the structure of your application and you need to keep the memory footprint low. You can use DOM when you have enough memory and you may need to manipulate the document by adding or moving tags.
If you want to see how these two methods use memory, open the project in Ktoolbar and use the Memory monitor (edit-->preferences:monitoring Tag). When you run MIDlet, you will see the Memory monitor window pop up with graphics and figures indicating memory usage. Run each application and watch the Green Line rise, which indicates the amount of memory your application consumes. You will see that the pull application uses less memory than the DOM application. Although the difference between the two midlet in this example is not very large, if a midlet traverses a larger file in DOM, it consumes more memory.
