BlueScripts was our first serious attempt at a useful Android application.

BluePanel is a continuation of the theme that BlueScripts started.

BlueScripts was designed to have a single list of all available actions to all target Bluetooth MAC addresses in a single XML file. It is a very functional way to get messages to embedded systems with minimal hassle. What it doesn't do is present the returned messages in a nice way nor provide a very rich UI for sending the messages.

BluePanel is an attempt to remedy both these shortcomings.

Again the functionality is custom and defined via an XML file, however in the case of BluePanel the XML is on the remote embedded system not the SD card of the Android device.

When the application connects to the remote target it requests the XML file (“sendXML”) that defines the interaction of the program with that target system.

The XML file provides information on both what kind of UI to generate as well as the states of the target system. It also provides information on how handle the returned information. For instance it could use a dialog box with an OK button or just a toast message which would disappear after a few seconds.

The goal is to allow for arbitrary user interfaces composed of standard Android View objects, coupled to an arbitrary state machine for the target embedded system.

XML format

The XML format is still under development but in the early alpha version used at Maker Faire the format used was as seen below. We show a toggle button and buttons with different return types.

<xml>
	<control>
	<name>Lamp</name>
	<statemessage>node1 state</statemessage>
	<type>tbutton</type>	
		<state>
			<intcode>0</intcode>
			<label>Lamp Off</label>
			<inputtype>null</inputtype>
			<inputhandler>null</inputhandler>
			<smessage>node1 off</smessage>	
			<returnpreamble>null</returnpreamble>
			<returntype>boolean</returntype>
			<returnhandler>null</returnhandler>
			<returnscaleA>1</returnscaleA>
			<returnscaleB>1</returnscaleB>
			<nextstate>1</nextstate>
		</state>
		<state>
			<intcode>1</intcode>
			<label>Lamp On</label>
			<inputtype>null</inputtype>
			<inputhandler>null</inputhandler>
			<smessage>node1 on</smessage>
			<returnpreamble>null</returnpreamble>	
			<returntype>boolean</returntype>
			<returnhandler>null</returnhandler>
			<returnscaleA>1</returnscaleA>
			<returnscaleB>1</returnscaleB>
			<nextstate>0</nextstate>	
		</state>	
	</control>
	
	<control>
	<name>Humidity</name>
	<statemessage>null</statemessage>
	<type>button</type>	
		<state>
			<intcode>0</intcode>
			<label>Get Humidity</label>
			<inputtype>null</inputtype>
			<inputhandler>null</inputhandler>
			<smessage>gethumidity</smessage>
			<returnpreamble>Humiditiy:</returnpreamble>	
			<returntype>int</returntype>
			<returnhandler>dialog</returnhandler>
			<returnscaleA>1</returnscaleA>
			<returnscaleB>1</returnscaleB>
			<nextstate>0</nextstate>
		</state>
	</control>
	
	<control>
	<name>Send message</name>
	<statemessage>null</statemessage>
	<type>button</type>	
		<state>
			<intcode>0</intcode>
			<label>Send Message</label>
			<inputtype>string</inputtype>
			<inputhandler>dialog</inputhandler>
			<smessage>null</smessage>
			<returnpreamble>Replied with: </returnpreamble>	
			<returntype>string</returntype>
			<returnhandler>dialog</returnhandler>
			<returnscaleA>1</returnscaleA>			
			<returnscaleB>1</returnscaleB>
			<nextstate>0</nextstate>
		</state>
	</control>
	
</xml>

Control - Defines a UI element, it needs a unique name and if it requires state synchronization it requires a command to ask the target system for the state (statemessage). Finally it requires a type which is a Android View object.

Inside the control are states. States are defined via an integer (intcode). If the object is a button the next state to go to on success is nextstate. We will add a state to go to on failure as well before source code release.

Each state has a label which is used to change the UI element's text when in that state.

If input is required to complete the action it can be requested via an input handler (currently only dialog). The input type describes how to pass that information to the target system.

smessage is the message that is sent, if input is required it is appended to smessage thus in our Send Message button there is no message but what is typed in the dialog box.

returnpreamble defines what to display before the returned message.

returnhandler defines how to use the returned message.

returnscaleA and returnscaleB determine for numerical return values how to scale the data. Because most targets will be integer systems two scales are provided to allow for fractional multiplication. This allows the integer system to use printf like programmatic XML generation of an effective floating point scale value.

At present all fields are required for each state, but an assumption of NULL may be added in the near term for unused XML tags.

Changes from BlueScripts

The essential base code from BlueScripts remains unchanged. However we noted that the threaded nature of the program would result in garbled messages if the messages were sent a computer rather than human rates. We fixed this issue by accumulating the message in the listening thread rather than the activity thread.

BlueScripts has this issue as well and could be fixed to deal with the thread issue in the same way.

BlueScripts used the EOT character to signify the end of a message. BluePanel uses ”/r/n” to signify the end of a reply. EOT was used in BlueScripts to allow for longer human readable messages (letting you use new lines etc), while BluePanel does not need this as the UI should reflect the received information.

bluepanel/overview.txt · Last modified: 2014/08/01 20:14 (external edit)
 
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki