Part 4
Java XML Programmers Reference
Chapter 11: XML Tools for Information Appliances
October 15, 2001
Brought to you by:
Check It Out!
|
Beaming the XML Document
When the user clicks one of the entryBtns, BeamContact receives a penDown() event. It's in this event handler that we determine which, if any, of the entryBtns were pressed. If one was pressed, BeamContact.beamRecord() is called with the record number to beam.
Infrared beaming itself is quite simple. The XML document must be beamed as a byte array, since com.sun.kjava.Spotlet requires all beamed content to be an array of bytes. com.sun.kjava.Spotlet provides a method called beamSend() that we will use for the physical data transfer:
public static boolean beamSend(byte[] data)
So let's look at our last method for this class, beamRecord(). It is called by penDown() when a button other than Quit, Next, or Prev is clicked. recordNum is the record in the contact book that the user wants to beam.
private void beamRecord(int recordNum) {
Database db = new Database(ContactBook.dbType,
ContactBook.creatorId, Database.READONLY);
if (db == null)
System.err.println("Error opening contact book");
else {
//read and beam it!
if (beamSend(db.getRecord(recordNum)))
new Dialog(this, "Success", "Beamed contact!",
"Ok").showDialog();
else
new Dialog(this, "Failure", "Could not beam contact!",
"Ok").showDialog();
}
com.sun.kjava.Database.getRecord() makes a native Palm OS call and returns a byte array with the raw content of the desired record:
public native byte[] getRecord(int recordNumber);
ReceiveContact
|
public class ReceiveContact
extends com.sun.kjava.Spotlet |
ReceiveContact is the core class for receiving a contact from the BeamContact application. It must extend com.sun.kjava.Spotlet to fit into the package com.sun.kjava application paradigm.
Spotlet is conceptually similar to java.applet.Applet in that it is a class for handling event callbacks. Overriding one of the event handlers, such as penMove(), keyDown(), or keyUp(), will enable the extended class (ReceiveContact, in this case) to receive notification of these events.
Upon running ReceiveContact, the application blocks until it receives beamed data. Although this is hardly adequate for a commercial environment, the application nevertheless demonstrates the technologies in this chapter quite well.
ReceiveContact blocks until it receives beamed data. If the data received is an XML document of the document class we've defined implicitly, the user is prompted to import the data into the contact book. If answered affirmatively, a new record is created in the database with that data. If the received data isn't XML or is not of the expected document class, it is ignored and ReceiveContact continues to block.
Here's a screenshot of the application before it receives a contact so you get a feel for how it works. There is only one other screen besides this one — the screen that prompts the user to import the contact.
We'll examine two parts of class ReceiveContact:
- Receiving beamed data and parsing it with NanoXML
- Writing the beamed data to the database
Receiving the XML Document
The process to receive beamed infrared data is quite simple. com.sun.kjava.Spotlet provides an event handler called beamReceive() that we override:
public static void beamReceive(byte[] data)
So let's look at our ReceiveContact.beamReceive(). It is called when the class Spotlet dispatches infrared data to our handler.
public void beamReceive(byte[] buf) {
//parse the received xml using NanoXML
contact = new String(buf);
kXMLElement elem = new kXMLElement();
try {
elem.parseString(contact);
}
catch (XMLParseException e) {
//can't parse received data--the sender probably
//wasn't BeamContact!! ignore it and return.
paint();
return;
}
All we're doing here is converting the byte array to a java.lang.String and passing it to NanoXML to parse. nanoxml.kXMLElement is the CLDC/KVM port of nanoxml.XMLElement and has the same public methods. See NanoXML for more information. A typical document instance, after converted from a byte array to a String, might look like this:
<contact fname="Frantic" lname="Neumann"
address="123 Fake Street" city="Denver"
state="Colorado" zip="80202" country="USA"
phone="303-303-3000"/>
The most common cause of an exception being thrown here is receiving data that isn't XML. The Palm OS routes received infrared data to the same application on the receiving unit that sent the data from the sending unit. This sandbox restriction pretty much guarantees that Palm's Memo Pad won't beam the contact book data, but it is restrictive; in our case, the sending and receiving applications, from the Palm OS's perspective, in the KVM. However, the Palm OS has no idea what application is running inside the KVM. It is therefore possible that another Java application running inside the KVM could beam data to ReceiveContact. If this occurs, beamReceive() calls paint(), which clears the screen and redraws the message, "Waiting for contact information…", and then returns.
Here's the rest of the beamReceive():
String fname = elem.getProperty("fname"), lname =
elem.getProperty("lname");
if (fname != null && lname != null) {
g.clearScreen();
g.drawString("Contact info was received for:", 0, 20);
g.drawString(fname + " " + lname, 0, 40);
g.drawString("Import into contact book?", 0, 60);
yesBtn = new Button("Yes", 40, 80);
noBtn = new Button("No", 60, 80);
yesBtn.paint();
noBtn.paint();
}
else paint();
}
kXMLElement.getProperty() returns null if a property doesn't exist in the element in which we are manipulating (in this case, the root element). If either the fname or lname properties don't exist, we ignore the received data, paint() the screen with the message "Waiting for contact information…" and then return. We could do further document checking by ensuring that the root element is named contact.
|
REPORTS
ANALYTICS
Follow 
