EQUIP2 and ContextPhone

Introduction

ContextPhone is a "mobile context-aware prototyping platform" running on Nokia Series 60 smart phones, developed at the University of Helsinki. It is available under GPL and MIT licenses, http://www.cs.helsinki.fi/group/context/latest/. It is built around a tuplespace/blackboard service which runs on the phone, which is used to manage configuration of the platform and to share "sensor" data obtained from various sources (e.g. current phone cell id, phone application activity, alarms, battery status, attached bluetooth GPS, bluetooth addresses in range).

ContextPhone has a (currently read-only) XML socket-based interface which allows J2ME and other non-native applications to read the information in the contextphone tuplespace. By default, this uses TCP on port 2000. A sample of the datastream obtained is contextphone-sample-onphone4.xml.

I have created an XML unmarshaller in EQUIP2's general marshalling framework to read this (kind of) XML stream and generate corresponding Java objects. This document describes this and the initial test/demo applications constructed for interfacing to ContextPhone.

Note: this unmarshalling-based interface gives access to the full information in the contextphone tuplespace in an object form, which can also be shadowed in an EQUIP2 dataspace. However, if an application only requires access to a small subset of contextphone's information (e.g. current cell id) then it would be simpler, more efficient and less fragile (to changes in the XML marshalling) to use a standard XML parser and just look for the particular elements of interest in the XML stream (there are other examples of doing this from J2ME - contact the ContextPhone team).

Code

Building

• test_contextphone - J2SE build of context-phone related classes and sample application(s) (depends on generate_contextphone)
  
• j2me_contextphone - J2ME build of contextphone related classes and sample midlet(s) (depends on generate_contextphone)
• generate_contextphone - builds javabeans and EQUIP2 helpers for native java representations of key contextphone types (using Simple Bean Generator)
  

data types

• equip2.contextphone.types.Tuple
• equip2.contextphone.types.TupleName
• equip2.contextphone.types.Event
• equip2.contextphone.types.CellId
• equip2.contextphone.types.Device
• equip2.contextphone.types.NetworkStatus

Unmarshalling

The unmarshaller is equip2.contextphone.marshall.ContextPhoneXmlUnmarshaller, which in turn depends on information built into equip2.contextphone.marshall.TypeMappingFactory to map contextphone objects (identified by various XML attributes) into corresponding Java object classes. This mapping is defined using a standard EQUIP2 XML serialisation of an array of equip2.contextphone.marshall.TypeMapping objects.

The unmarshaller has various default rules, e.g. to use Hashtables for unknown classes. But these rules will fail under certain circumstances, e.g. unknown event data object which is not compound, or event data object which has unknown sub-objects. In these cases an exception will be raised and the type mapping will need to be fixed/updated accordingly.

The unmarshaller will also search for some EQUIP2 helpers automatically which may not exist, in which cases ERROR/WARNING messages will be generated; these can be avoided by specifying explicit mappings for those contextphone types, even if it is just to a Hashtable (which is the fallback in any case).

The standard helper class equip2.core.marshall.impl.XmlObjectInputStream can be used with context phone unmarshaller (or the default EQUIP2 XML unmarshaller) to simplify reading a sequence of objects from an XML-encoded stream.

There is also an example of wrapping the contextphone connection to extracted only limited information via callback(s): equip2.contextphone.test.j2me.ContextPhoneClient (listener interface equip2.contextphone.test.j2me.ContextPhoneListener)

Sample applications

• equip2.contextphone.test.j2se.ReadXmlFile - reads a (local) contextphone-formatted XML file and prints some summary information about it. Used to check that the marshalling is working. Also addOrUpdates the unmarshalled tuples into a (transient) EQUIP2 dataspace, to check that this works as well. Usage: <filename>
• equip2.contextphone.test.j2se.TcpDumpServer - listens on a specified TCP port and prints out the received data. Used with the J2ME test MIDLet to create the sample XML file(s) from the phone. (see midlet)

• the "Copy" option will try to connect to a pre-configured server (see static field SERVER_URL) and to the local contextphone tuplespace, and copy bytes from the tuplespace to the server. Typically this would be an instance of the TcpDumpServer mentioned above, to get a copy of the raw XML from the tuplespace. This is implemented by the CopyTask internal class.
  
• The "Connect" option will connect to the tuplespace and unmarshall objects as they become available, updating three views: a time-ordered list of objects (events) received from the tuplespace ("View updates"/"Recent notifications"); a list of the tuples received from the tuplespace including their internal (contextphone tuplespace) IDs ("View tuples"/"Tuples/events"); and a the property values for a single selected tuple ("Details"/"Tuple details", from the tuple list view only). This is implemented by the PullTask internal class and supporting screen update methods (handleUpdate, etc.).
  
• The "Test client" option will instead use the equip2.contextphone.test.j2me.ContextPhoneClient class to connect to the dataspace and print a summary of current and recent cell id and network status only. This is implemented by the ContextPhoneAdapter internal class.
  

Future plans/options

• two-way interface to tuplespace
• use in hitchers instead of placelab
• use in Participate, e.g. Prof. Tanda
• a unified cross-phone bluetooth discovery/communication facility
  

Change log

• document created