So, as promised in my previous post, I said I’d talk about some frameworks to get you up and running quickly with building android applications. In fact there are 2 which I found invaluable. RoboGuice, and Robolectric.

RoboGuice

If you’re familiar with dependency injection and your normal run of the mill IoC frameworks, then RoboGuice will make you feel right at home! I’d already had quite a bit of experience with Spring, so using RoboGuice was relatively straight forward. They have a very good “Getting Started” guide on their site,  which I encourage you to read if you need a little nudge in the right direction. What sealed it for me was that RoboGuice could take care of the boring stuff for me, like injecting my Views, Resources and Services which I would have normally had to painstakingly code the lookups for myself. You’ll find that without RoboGuice, you’ll be coding a lot of lines that look like this (Unashamedly plagiarized from RoboGuice’s getting started page!):

class AndroidWay extends Activity {
    TextView name;
    ImageView thumbnail;
    LocationManager loc;
    Drawable icon;
    String myName;

    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        name      = (TextView) findViewById(R.id.name);
        thumbnail = (ImageView) findViewById(R.id.thumbnail);
        loc       = (LocationManager) getSystemService(Activity.LOCATION_SERVICE);
        icon      = getResources().getDrawable(R.drawable.icon);
        myName    = getString(R.string.app_name);
        name.setText( "Hello, " + myName );
    }
}

So as you can see, there is a fair amount of plumbing going on here, and this is just a simple view. Imagine a form input view which has a myriad of input and label fields, from drop downs, to TextViews, to Lists etc. Man I’m getting a headache just thinking how messy it could get! So, lets face it, who really wants to have to type that line to find the view, and remember to cast it correctly,  or do that laborious resource lookup – quite frankly, its a waste of time!

So by simply using the @InjectView, @InjectResource or just plain @Inject, you can avoid all this pain quite easily, and here is a sample of the above example using RoboGuice (Unashamedly plagiarized from RoboGuice’s getting started page!):

class RoboWay extends RoboActivity {
    @InjectView(R.id.name)             TextView name;
    @InjectView(R.id.thumbnail)        ImageView thumbnail;(Unashamedly plagiarized from Roboguice's getting started page!)
    @InjectResource(R.drawable.icon)   Drawable icon;
    @InjectResource(R.string.app_name) String myName;
    @Inject                            LocationManager loc;

    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        name.setText( "Hello, " + myName );
    }
}

Robolectric

Now with RoboGuice and all its injectable goodness, you wouldn’t be accused of wondering if this makes your testing easier… well let me put your mind at rest and tell you, that YES, it most certainly does! And what better way to test your functionality, than with an android testing framework known as Robolectric. I’ve seen in the past, quite a few approaches to testing android apps, and some of them involved actually booting up an emulator, deploying the package, and running the app with the tests. This is a very time-consuming operation, and to be honest, most of the time, we just want to test the functionality that we have written, which can’t be done without the inclusion of the activities and views along with their respective interactions. How does Robolectric achieve this? Well, to quote from their website:

Robolectric makes this possible by intercepting the loading of the Android classes and rewriting the method bodies. Robolectric re-defines Android methods so they return null (or 0, false, etc.), or if provided Robolectric will forward method calls to shadow Android objects giving the Android SDK behavior. Robolectric provides a large number of shadow objects covering much of what a typical application would need to test-drive the business logic and functionality of your application. Coverage of the SDK is improving every day.

So, what this essentially boils down to is that, Robolectric has its own Test runner(which you use with the @RunWith annotation), which will mimic your android device, by returning what effectively is a mock object for things like location services, or views, or resources etc. You can then even override these mock objects – also referred to “shadow objects” – which you can code yourself to return a predicted outcome. This allows you to test your android app from within a JVM, even inside your own IDE! No need for bootstrapping an emulator, no need for compiling and packaging it into a dex and deploying. Just write the test, and run. The beauty of this, at least for me, is that I can now run these tests via maven, and include them as part of my CI build. Job Done. You might not be able to catch form factor bugs in this manner, but I believe that trying to test for different form factors on different devices provided by different vendors actually requires a different approach which I haven’t yet had to tackle – but when I do, my solution will be up here.

Well that’s all for now. I hope this helps any of you out there thinking of writing an android app, and need help getting started. If you can get your project structure right, and use these two frameworks I’ve mentioned, you’ll be well on your well to a painless and happily filled developement life!

So to start, lets talk about how to structure your project. I’ve used eclipse to develop my android goodness, and I’ve found it to suffice for what I need – although I am pretty tempted these days to IntelliJ, but thats a story for another blog post!

The best way I found to structure my project, was to use maven. Honestly, I could have just stuck with the standard project that comes with the android SDK, but there’s something that really erks me about not describing my dependiencies in a POM file! This also makes me feel a little more cosier inside for when I eventually try and set the beast up to run a Jenkins build!

OK, so we’ve established that we need to use Maven. Thats great, but how do I go about trying to structure where my files go, and what about the nice feature in eclipse that allows me to build my android project, and even deploy it?! Well, here comes the neat little plugin called : maven-android-plugin This is a fantastic little maven plugin to help you build you project, and to help you along, below is a xml snippet of what it would look like configured in your pom:

<dependencies>
	<dependency>
		<groupId>com.google.android</groupId>
		<artifactId>android</artifactId>
		<version>2.2.1</version>
		<scope>provided</scope>
	</dependency>
</dependencies>
<!-- Other config ommited for brevity -->
<build>
<plugins>
	<plugin>
		<groupId>com.jayway.maven.plugins.android.generation2</groupId>
		<artifactId>maven-android-plugin</artifactId>
		<version>2.9.0-SNAPSHOT</version> <!-- 2.8.4 -->
		<configuration>
			<sdk>
				<path>${env.ANDROID_HOME}</path>
				<!-- platform or api level (api level 4 = platform 1.6)-->
				<platform>8</platform>
			</sdk>
			<device><!-- Insert the device ID here if you want to deploy to an actual device --></device>
			<!--  emulator>emulator_name</emulator -->
			<deleteConflictingFiles>true</deleteConflictingFiles>
			<undeployBeforeDeploy>true</undeployBeforeDeploy>
			<coreLibrary>true</coreLibrary>
		</configuration>
		<extensions>true</extensions>
	</plugin>
</plugins>
</build>

One thing worth mentioning here, is the version of the maven-android-plugin I’m using. Its actually my own rolled version which I forked from the github repo because I needed to fix a bug. The bug fix has been included into the currently 3.0.0-alpha-1 release. You can read about it here. I haven’t yet updated to the 3.0.0-alpha-1 version, because I haven’t had time yet to make sure everything still works. I can’t see anything majorly wrong with using this version for now, but do be warned.. it is an alpha after all!

With that started, I’ll be writing next about some really cool frameworks there are for the android platform, that could easily cut down on the amount of code you’d have to write!

Till next time…

The last two summits I’ve attended here in London, have had increasing amounts of attendance, so I wasn’t too surprised to find that they had split up the day with different tracks for the different types of customer they had anticipated. Namely the newbie, who wants to know what AWS and the cloud is all about, then the advanced user, who’s been using it for a while and needs some tips and tricks, and then the “guided track” for those interested in Cloud Solutions.

For the most part, I found myself hopping between the novice and advanced tracks, trying to squeeze out the best I could from each session. However, I’m not going to describe all that I learnt there, because to be honest, a lot of what was covered there I’m pretty sure is material you could find on their website with a good enough search. No, what I am going to talk about it something that really struck me about AWS’s success.

It’s no secret, AWS are good at what they do, and they’re only getting better. What once started out as a modest attempt to offer services with names such as Elastic Compute Cloud (renting out computing capacity), Simple Storage Service (renting data storage) and Mechanical Turk (I didn’t know what that was either!), has now grown into what I think is a rather large, and ever-growing business. One of the reasons for their renowned success, hit me like a brick during a talk by Matt Woods – AWS are actually Agile!

Amazon have consistently displayed their uncanny ability to deliver small sets of features to their customers, allow for feedback, then iterate and improve. Rinse and repeat. This constant delivery of features – which by the way I think has been something like 6 new features a month on average – is what creates the buzz, and we as developers really love to try out new things. And as we do, we find some aspects which aren’t always to our liking, we tell AWS, and BINGO! they fix or enhance it. And in some cases I’ve heard from customers that they no sooner have given feedback, and the fix just happened to be released the next day!

AWS have been very focussed on customer feedback, and they take it very seriously. They listen, react, and in doing so, help strengthen their relationships with their customers. And I think they should be commended for adopting such a simple but effective strategy.

These very agile tenets of short cycles of delivery, frequent customer communication, and rapid response to what your customers regard as the most important focus, are what makes for delivering quality goods. In the case of AWS, it’s delivering a quality service, and in the case of software development, its delivering quality software.  So really they’re not very different. It just goes to show that, agile isn’t something that only has to be practised in a software development environment.

I recently attended the SpringSource S2G Forum Series at the London Hilton. There were some good sessions being presented, and sometimes I wish I could clone myself, as more often than not, there’s always more than one really good session running in the same time slot!

My three big take-aways were Tomcat 7, Spring MVC 3.1 update and the Spring Data Project, which I’ll talk about here.

Tomcat 7

So, first up, after the keynote, was a brush over what’s new in Tomcat 7. I must say, there are some rather neat enhancements in v7 that I’ll be looking forward to(but not necessarily using):

• Support for parallel deployment
  • This is fantastic IMO. This enables you to deploy multiple different versions on the same web application (WAR) concurrently, all being accessed by the same context path. Tomcat will automatically route new sessions to the latest version of the application, while current sessions on older versions will continue their requests to those versions until their session expires. This greatly reduces deployment costs, and having to worry about deployment upgrade schedules/windows. Upgrading using parallel deployments will make upgrading seamless.
• The ability to configure an active tomcat instance via JMX from just running the server component.
  • I think this is great news for those who want absolute control over how their Tomcat instance is configured. With the capability of being able to configure tomcat in this fashion, opens the doors for tools/utilities to be written to programmatically create instances just how you like them.
• The new Cross Site Request Forgery(CSRF) protection filter
  • This filter basically generates a nonce value after every request, and stores the value in the user’s session. The nonce has to be added as a request parameter on every request, and Tomcat will verify if the values are the same, to check to see if the request wasn’t from somewhere else.
• Various default configurations
  • Access Logs on by default
  • LockoutRealm used by default
  • DefaultServlet serves content from the root of the context by default

I was glad to hear that SpringSource tc Server and the Tomcat 7 source were being kept in line , and felt at ease when I was reassured that whatever changes are being made in TC7 are soon finding their way into SpringSource tc Server.

Spring 3.1 MVC Update

I’m noticing more and more of a focus these days on Java based configuration with Spring, and this was highlighted in the Spring MVC session. Rossen Stoyanchev did a good job highlighting this point, and gave some good examples which demonstrated this. I’m still not 100% converted though, and I still feel that there is a place for xml configuration, but if I’m honest, I am beginning to find myself coding my configuration more these days.

There is much better support now for making customisations to any one or more aspects of the mcv namespace. whereas before if you were happy with the default configuration setup, all you previously had to do to setup most of the web bits was to have the following line in your xml config:

<mcv:annotation-config/>

However, if you wanted to setup an xml marshaller for example, then you pretty much had to redefine all the parts that the previous convinience xml fragment did for you. This was very much a pain, and now is easy to accomplish.  All that is required is that you annotate your configuration class with @EnableWebMvc(yes, you have to use the java based configuration route if you want to avert the previous pain) and extend the WebMvcConfigurerAdapter class. The WebMvcConfigurerAdapter class provides you with many callback methods to add to/modify what is configured by default.

Along with easier MVC configuration, there is also now a bit more transparency about what gets configured for you under the hood. If you take a look now at theWebMvcConfiguration class, you can now see what’s being configured for you now by default.

Other areas which were mentioned, but I am yet to explore, are features around pre/post validation hooks, as well as pre/post bind when binding your form object to a controller method invocation.

Spring Data Project

Now this is something quite exciting, and rather new to me. I like the idea Spring has here to build a data-access framework to give developers the capability to have their business object data stored in different data stores. The clever people over a SpringSource have built it in such a way that you can even have different parts of your domain object for example, stored in different data stores, so you might have some info stored in a graph database, some info in a regular RDBMS store, and if you have data that has no relation to anything, but you still need to store it, you can have that stored in a NoSQL data store, and all this, will be transparent to the user. Brilliant! If you have a application that stores data(who doesn’t?!), then I’d strongly suggest that Spring Data be given a once over. I for one think its a move forward in the right direction, empowered to store your data where it needs to be stored best, without having to worry about the vast amount of plumbing involved to get it done!

This was one such occasion. I use maven for building my android project, but I had recently started using Springs RestTemplate, and there were a few libraries that I had to import while attempting to build REST based communications.

One thing that caught me off-guard, was, that when I came to build the project, I was now presented with a number of errors, all with the same sort of warning which read as:

[INFO] [android:dex {execution: default-dex}]
[INFO] C:\Program Files\Java\jdk1.6.0_20\jre\bin\java [-jar, C:\Program Files (x86)\Android\android-sdk-windows\platform-tools\lib\dx.jar, --dex, --output=C:\dev\android-sample\target\classes.dex, C:\dev\android-sample\target\android-classes]
[INFO]
[INFO] trouble processing “javax/xml/bind/annotation/adapters/CollapsedStringAdapter.class”:
[INFO]
[INFO] Ill-advised or mistaken usage of a core class (java.* or javax.*)
[INFO] when not building a core library.
[INFO]
[INFO] This is often due to inadvertently including a core library file
[INFO] in your application’s project, when using an IDE (such as
[INFO] Eclipse). If you are sure you’re not intentionally defining a
[INFO] core class, then this is the most likely explanation of what’s
[INFO] going on.
[INFO]
[INFO] However, you might actually be trying to define a class in a core
[INFO] namespace, the source of which you may have taken, for example,
[INFO] from a non-Android virtual machine project. This will most
[INFO] assuredly not work. At a minimum, it jeopardizes the
[INFO] compatibility of your app with future versions of the platform.
[INFO] It is also often of questionable legality.
[INFO]
[INFO] If you really intend to build a core library — which is only
[INFO] appropriate as part of creating a full virtual machine
[INFO] distribution, as opposed to compiling an application — then use
[INFO] the “–core-library” option to suppress this error message.
[INFO]
[INFO] If you go ahead and use “–core-library” but are in fact
[INFO] building an application, then be forewarned that your application
[INFO] will still fail to build or run, at some point. Please be
[INFO] prepared for angry customers who find, for example, that your
[INFO] application ceases to function once they upgrade their operating
[INFO] system. You will be to blame for this problem.
[INFO]
[INFO] If you are legitimately using some code that happens to be in a
[INFO] core package, then the easiest safe alternative you have is to
[INFO] repackage that code. That is, move the classes in question into
[INFO] your own package namespace. This means that they will never be in
[INFO] conflict with core system classes. JarJar is a tool that may help
[INFO] you in this endeavor. If you find that you cannot do this, then
[INFO] that is an indication that the path you are on will ultimately
[INFO] lead to pain, suffering, grief, and lamentation.
[INFO]
[INFO] 1 error; aborting
[INFO] ————————————————————————
[ERROR] BUILD ERROR
[INFO] ————————————————————————
[INFO]

Now that’s a pretty scary error to have, and on subsequent investigation, it seems like some marshalling libraries I’ve imported have the same namespace as some included java namespaces. Not to worry, I trust that the developers of this marshalling library know what they’re doing, so I just want it to build. But alas, following the instructions to use the –core-library option, the maven-android-plugin still refuses to build, and you just get back the same build error message.

I then found this nice bug report, which detailed pretty much everything I was experiencing – thank you to whoever you might be! So I thought the least I could do was fix the bug, if it was so well logged!

It turns out that the maven-android-plugin had a small bug in it, where the order of the options weren’t quite 100%. The GitHub pull request is here, and it has been accepted, so I assume it will be available in the next release.

I hope this helps anyone else out there experiencing this problem.

Let me set the scene, first, and tell you my story.  I was über excited to recieve my very own “work purchased” Samsung galaxy tablet yesterday, to be used for, among other things, developing some Android applications. I couldn’t contain my excitement, and this was way more fun than filling in my timesheets, so, I cracked the sucker open and began developing a little something that basically made use of the camera functionality. So I initially set off to create a test Activity which had a Gallery control, and a button to activate the camera. All I wanted to do was create a sample app, which would populate the gallery with the photos that I’d take. However, I couldn’t help but be reminded of how similar grappling with the camera functionality on the Samsung Galaxy tab is issuing a command to my ridgeback dog Bruno. Neither of them does what you expect it to! Instead, you’re just left surprised while it does its own crazy thing! 

So in my example, I thought I’d try something simple. Just start the camera activity with the method call to startActivityForResult, and in the method onActivityResult, when the camera returns, I expected to be able to get both the thumbnail and the actual image in the intent’s data. Alas, this is not the case. It appears that if you populate the EXTRA_OUTPUT extra with a URI of where to store the new photo, then the camera will store the photo there for you. Now in my experience, this is true, however, with a little annoying caveat. Not only will the camera store it in the URI location that you supplied, but it also stores it in the default location of its own!

I had another problem. I wanted not only the thumbnail, but also the actual image. For the purpose of this, I didn’t really need the actual image, but more the location of where I could go and get it. Now when using the method I just previously spoke about, by providing the EXTRA_OUTPUT extra on the request intent, the camera on return to the onActivityResult, ends up passing back a NULL intent, which used to have the thumbnail image in the extra key called “data“. Now you have diddley squat!

Yet another problem I faced was that, the URI I was passing in the request intent, to tell the camera where to save this image, always ended up being NULL when the onActivityResult method was called. So now, not only do I have to somehow persist the URI that I had already passed into the request intent (to prevent it from becoming null), I now also didn’t have a thumbnail to speak of – which I used to get from the “data” extra in the return intent.

Plan B…..

It seemed that from all my reading, the best way was to create a temp file, that always had a deterministic name and location, create the file, then create a URI from that, and pass that as part of the request intent, and you could reconstruct the URI when the onActivityResult was called. Thats great, but where’s my thumbnail? Still not there? <sarcasm>Nice!</sarcasm>

Plan C….

So this is what I eventually had to resort to, in order to get both the thumbnail, AND actual image location in order to populate my gallery control with the thumbnails, and retain the actual image location so that I could display it when the user tapped on the thumbnail, and thereby also avoiding any duplicate images being stored :

Call the Camera activity as per normal Don’t do anything fancy, just create the intent with the ACTION_IMAGE_CAPTURE constant. That way, you don’t create duplicate images all over the place.

On the return call of onActivityResult, you need to do a managedQuery on the MediaStore.Images.Thumbnails.EXTERNAL_CONTENT_URI and MediaStore.Images.Media.EXTERNAL_CONTENT_URI locations, and selecting the last image that was captured. This way, you are able to obtain a handle to both the thumbnail, and the image without having to deal with all the weirdness of before. Once you have these, then you’re good to go! I’ve posted some sample code below to show you what I’m talking about.

private static final int CAMERA_IMAGE_CAPTURE = 0;

public void btnTakePhoto_onClick(View view){
 Intent intent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);
 startActivityForResult(intent, CAMERA_IMAGE_CAPTURE);
 }

 

@Override
 protected void onActivityResult(int requestCode, int resultCode, Intent data) {
 super.onActivityResult(requestCode, resultCode, data);
 if(requestCode==CAMERA_IMAGE_CAPTURE && resultCode==Activity.RESULT_OK){

// Describe the columns you'd like to have returned. Selecting from the Thumbnails location gives you both the Thumbnail Image ID, as well as the original image ID
String[] projection = {
 MediaStore.Images.Thumbnails._ID,  // The columns we want
 MediaStore.Images.Thumbnails.IMAGE_ID,
 MediaStore.Images.Thumbnails.KIND,
 MediaStore.Images.Thumbnails.DATA};
 String selection = MediaStore.Images.Thumbnails.KIND + "="  + // Select only mini's
 MediaStore.Images.Thumbnails.MINI_KIND;

 String sort = MediaStore.Images.Thumbnails._ID + " DESC";

//At the moment, this is a bit of a hack, as I'm returning ALL images, and just taking the latest one. There is a better way to narrow this down I think with a WHERE clause which is currently the selection variable
Cursor myCursor = this.managedQuery(MediaStore.Images.Thumbnails.EXTERNAL_CONTENT_URI, projection, selection, null, sort);

long imageId = 0l;
long thumbnailImageId = 0l;
String thumbnailPath = "";

try{
 myCursor.moveToFirst();
imageId = myCursor.getLong(myCursor.getColumnIndexOrThrow(MediaStore.Images.Thumbnails.IMAGE_ID));
thumbnailImageId = myCursor.getLong(myCursor.getColumnIndexOrThrow(MediaStore.Images.Thumbnails._ID));
thumbnailPath = myCursor.getString(myCursor.getColumnIndexOrThrow(MediaStore.Images.Thumbnails.DATA));
}
finally{myCursor.close();}

 //Create new Cursor to obtain the file Path for the large image

 String[] largeFileProjection = {
 MediaStore.Images.ImageColumns._ID,
 MediaStore.Images.ImageColumns.DATA
 };

 String largeFileSort = MediaStore.Images.ImageColumns._ID + " DESC";
 myCursor = this.managedQuery(MediaStore.Images.Media.EXTERNAL_CONTENT_URI, largeFileProjection, null, null, largeFileSort);
String largeImagePath = "";

try{
 myCursor.moveToFirst();

//This will actually give yo uthe file path location of the image.
largeImagePath = myCursor.getString(myCursor.getColumnIndexOrThrow(MediaStore.Images.ImageColumns.DATA));
}
finally{myCursor.close();}
 // These are the two URI's you'll be interested in. They give you a handle to the actual images
 Uri uriLargeImage = Uri.withAppendedPath(MediaStore.Images.Media.EXTERNAL_CONTENT_URI, String.valueOf(imageId));
 Uri uriThumbnailImage = Uri.withAppendedPath(MediaStore.Images.Thumbnails.EXTERNAL_CONTENT_URI, String.valueOf(thumbnailImageId));

// I've left out the remaining code, as all I do is assign the URI's to my own objects anyways...

}
}

I hope this helps someone else out there, cause this had me baffeled for a while. I don’t know what this just can’t be easier. Surely there’s no need to have to jump through hoops like this. Anyhoo, I’m working on getting the better managed query working, and I’ll just use this when I need it. It seems to work for the most part anyway.
]]> http://kevinpotgieter.wordpress.com/2011/03/30/null-intent-passed-back-on-samsung-galaxy-tab/feed/ 9 kevinpotgieter http://kevinpotgieter.wordpress.com/2011/03/04/different-responses-with-spring-rest/ http://kevinpotgieter.wordpress.com/2011/03/04/different-responses-with-spring-rest/#comments Fri, 04 Mar 2011 08:15:34 +0000 Kevin http://kevinpotgieter.wordpress.com/?p=20 ]]> So lately I’ve been delving into Spring REST, and playing around with a few things, and something dawned on me which hadn’t occurred to me until I was actually messing around with a side project I have going on at home. Spring provides you the capability to return content in 2 different fashions:

1. Either as a representation of the Model Object OR
2. Either as the actual formatted content in the response body in whatever format(xml, json etc)

It’s important to draw the distinction between information being returned to you directly via the response body, and the model object. An example is probably in order.

Let’s say we have our standard Spring MVC project set up, and we have the controller class HomeController

@Controller
public class HomeController {
private static final Logger logger = LoggerFactory.getLogger(HomeController.class);
@RequestMapping(value="/home", method=RequestMethod.GET)
public String home(ModelMap model) {
logger.info("Welcome home!");
model.addAttribute("attribute", "home-gerome");
return "home";
}
}

and the relevant xml for the spring configuration looks like this:

<bean id="xStreamMarshaller" class="org.springframework.oxm.xstream.XStreamMarshaller">
<property name="autodetectAnnotations" value="true"/>
<!--<span class="hiddenSpellError" pre=""-->bean>
<bean class="org.springframework.web.servlet.view.ContentNegotiatingViewResolver">
<property name="order" value="1"/>
<property name="mediaTypes">
<map>
json" value="#{T(org.springframework.web.servlet.view.json.MappingJacksonJsonView).DEFAULT_CONTENT_TYPE}"/>
<entry key="xml" value="#{T(org.springframework.web.servlet.view.xml.MarshallingView).DEFAULT_CONTENT_TYPE}"/>
</map>

</property>
<property name="defaultViews">
<list>
<bean class="org.springframework.web.servlet.view.json.MappingJacksonJsonView"/>
<bean class="org.springframework.web.servlet.view.xml.MarshallingView">
<constructor-arg name="marshaller" ref="xStreamMarshaller"/>
</bean>
</list>
</property>
<property name="ignoreAcceptHeader" value="true"/>
</bean>

There’s nothing special about this configuration, its pretty standard, and I managed to gleam most of it off of the Spring documentation, and the API docs on the ContentNegotiatingViewResolver

Notice how there’s only a @RequestMapping annotation on the method, nothing else, and the ModelMap parameter being passed in. If you build your HTTP GET request ( I use an add-on called REST Client for Firefox), for the home.json resource, you’ll notice that the response body actually returns like this:

{"attribute":"home-gerome"}

No surprises here that is looks just like the content of the Model, with the key-value pair.

I’d just like to mention that if I made a request for home.html, instead of home.json, I’d actually get the HTML content of the home.jsp page in the response body, and there will be no trace of the ModelMap data here. This is purely down to the ViewResolver chaining where the ContentNegotiatingViewResolver wouldn’t be able to satisfy my request for my .html request, and would then move onto the 2nd ViewResolver I had configured which can. Seeing as though I made the request for home.json, the ContentNegotiatingViewReolver finds a class that can resolve a view for the request, and it uses the MappingJacksonJsonView to resolve the request and format a response, which looks at the ModelMap, to return data back to the calling client. Requests ending in .json, or .xml etc are preferred over the Accept Headers in the request, although this is also configurable in the ContentNegotiatingViewResolver.

Also, you’ll see I’ve added the property ignoreAcceptHeader=true, and I did that because of another “problem” I faced while working with HTTP requests and how Spring uses them to make certain choices, and subsequently learnt that HTTP Headers can be evil… but more on that in another post. So for now, I’ve actually set this property in my project to ignore Accept Headers for now, and just use the extensions on the request to determine how content should be delivered.

Now, having spring deliver content via the @ResponseBody opens up another can of worms. In fact, I was going to try and give you an example here, but after I finished I felt that this post actually ended up being way too massive so I’ll possibly address @ResponseBody use and configuration in an upcoming post. Suffice to say though, that although it is nice to have your objects returned directly via the response body when using the @ResponseBody annotation, doing so doesn’t come without its fair share of additional configuration and hacking about.

In chatting to some others who have used Spring REST, and all the goodness it offers, I’ve come to the conclusion that many are left with the question of when to use @ResponseBody as opposed to just the traditional way before @ResponseBody came onto the scene. From what I’ve seen so far, I’d make the decision based on the following

You have an existing Spring MVC website in place, and you want to make it deliver content in json and xml format.

Well, if this is the case, I’d avoid using @ResponseBody, and I’d just populate the ModelMap object with the content I want to send back to the client. The reason for this being that, I can still then make use of the view resolving that happens for me when I return a string to lookup the .jsp page and render that content back. However if I stick a @ResponseBody tag on my method, I’m effectively responsible for doing all of that myself, i.e. returning the actual content to the response, and I lose all that spring automagic that happened before. So for situations where you want to run your website and your REST requests/responses off of the same MVC controller, then I’d stay away from @ResponseBody.

Another good reason for avoiding the @ResponseBody, is that for GET requests, Spring doesn’t seem to be able to work out (yet) which formatter to correctly pick other than looking at the accept headers. When you use @ResponseBody, as part of the configuration, you’ll setup HTTPConverters responsible for formatting the content, and you’ll configure them to only listen for certain accept headers by populating the supportedMediaTypes property. As I’ve mentioned just previously, I’ve just recently learnt that when relying on browsers coming to your website, accept headers can be evil.. so stay away!

You don’t have to service browser requests, and will only be serving content to clients to have control the accept header.

If all you need is something that interacts with a representations of your domain objects, then I’d say go for the @ResponseBody annotation. Purely because clients are more than likely in control of setting things like HTTP headers, and when using @ResponseBody with GET requests especially, you have to add the headers property of the @ResponseBody annotation to tell spring which method to effectively call for which type or representation. So your controller would look something like this:

These are my experiences so fat while using @ResponseBody. I’ve only just started realising its benefits, but I think it needs to be said that if you;rethinking about using the @ResponseBody feature, think carefully about where, and how you want to use it, because it can give you more headaches than its worth.

The idea simply demonstrates a job listing for an engineer, allowing them to review the job details, and contains the ability to take before and after photos of the job, as well as geo tagging the images with their current GPS location, to pin point where the images were taken. I believe Drew has already beaten me to the post (no pun intended) but if you haven’t seen it there yet, then check out the cool video we put together:

You can also find the original post on my company blog here: ‘Mobile Workforce On Android‘

So without taking up too much time on the first post, I just wanted to say, “I’m back!”

Expect great things on this here blog over time, as I plan to plot my journey ,traversing the world of .NET and Microsoft and into the unknown world of Java and all of its open source goodness!

Until next time….