Datasharing

A slideshow on datasharing between a webservice-server and an Android client is available at slideshare.com  http://www.slideshare.net/sullis/connecting-to-web-services-on-android

Transport protocol

We considered several different transport protocols

SOAP

All team members have a lot of experience with SOAP from earlier projects. But the technology adds a lot of extra functionality and data which is not needed. For instance, we need no state control, no encryption, and no signing.

REST

REST is more of a style than it is a technology ( http://en.wikipedia.org/wiki/REST). Most applications utilizing the web have forgotten about the http protocol, most seem to only use post and get queries, where as REST makes use of all the queries, to distinguish between the intention of the query, and the data.

REST makes for a simple protocol with little overhead, while still utolizing and ripping the benefits off of the transport http protocol. REST depends on another technology to wrap the data.

Here is an abstract description of developing a webservice with the REST philosophy:  http://www.xfront.com/REST-Web-Services.html

The first resource available about REST is from this Doctoral dissertation by Roy Thomas Fielding :  http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

RestLet Ressources and Links

RestLet.org is an opensource implementation of both a server side and a client side REST webservice framework. It's by far out best bet to date, but maybe we'll find something better. There are words in the Android community of a framework called kSOAP2, but it's a port from something else, and not intended for the Android platform.

This section is dedicated to links and ressources on how to use the RestLet framework for Android.

Binary protocol

Building a binary protocol was always out of the question, as it would add an inconvenient layer of maintainability and source of errors.

Data wrapper technology

To wrap the data we are looking for a technology which is easy to implement and maintain.

XML

We all have a lot of experience with XML from a range of different projects, and from using it with the SOAP technology.

The challenge with XML is to get our hands off from the manual labour and settle on a nice framework for building and reading XML data. The Apache foundation has made a Java library called XMLBeans which sounds promising:  http://xmlbeans.apache.org/

JSON

 http://en.wikipedia.org/wiki/JSON JSON is a simple way of wrapping data. It is often used with javascript but could have been implemented in our application aswell, we have chosen not to, since it is completely new to us.

Google have made a very promision JSON library for use witht he Android framework, called GSON.  http://code.google.com/p/google-gson/

Serialization

Client

XStream

Performance unknown. Issues a lot of warnings

XMLSerializer

Settled on this approach. tedious.

Server

XStream

Issues

Handling mocked objects

A mock object is handled as a dynamicproxy object and sent to the converter for these kind of objects. Now we are not interested in unmarshaling back to a dynamic proxy, we just want out stock converter to also handle the mocked objects of the kind it was supposed to convert in the first place. This might do the trick, remember to cut and paste as needed. (Change the accepted class)

    public boolean canConvert(Class type) {
        return type.equals(DynamicProxyMapper.DynamicProxy.class) || Proxy.isProxyClass(type);
    }

It's also important to add an alias because the proxy class will now have a strange name <dynamic-proxy>. But in order to get the proxy class on run time you have to ask the actual replay object for it's own class. Then it'll all work.

@Override
	public boolean canConvert(Class clazz) {
		if (clazz.equals(DynamicProxyMapper.DynamicProxy.class)) {
			return true;
		}
		else if (Proxy.isProxyClass(clazz)) {
			return true;
		}
		else if (clazz.equals(GridCell.class)) {
			return true;
		} else  {
			return false;
		}
		
	}

	IGridCell icc = createMock(IGridCell.class);
		expect(icc.getLatitude()).andStubReturn(35.9237275622272);
		expect(icc.getLongitude()).andStubReturn(14.4889622588559);
		expect(icc.getAverage()).andStubReturn(120);
		replay(icc);

		XStream xStream = new XStream();
		xStream.registerConverter(new MoodMapConverter());
		xStream.alias("MoodMapReading", icc.getClass());

		String xmlOutput = xStream.toXML(icc);
		xmlOutput = xmlOutput.replaceAll("\n", "").replaceAll(" ", "");
		Assert.assertEquals("<MoodMapReading><MoodMapValue>120</MoodMapValue><MoodMapLongitude>14.4889622588559</MoodMapLongitude><MoodMapLatitude>35.9237275622272</MoodMapLatitude></MoodMapReading>",xmlOutput);

The procedure is also described on ExxKA' blog  http://www.1337h4x0r.com/testing-xstream-with-easymock