In my last post, I discussed issuing a GET request to a web API, downloading and converting the response to a string and creating JSONObjects from it. The next step is to create your domain specific objects from the JSON.

Here's an example:

The process is pretty simple. Loop over the JSONObjects and build up you domain specific objects. Then they can be freely used within your Android app.

I'm currently in the midst of writing my first Android application. Android is Google's new open source OS for mobile devices.

Just for fun, I'm writing an application called Complainatron. Complainatron is an application that allows mobile users to bitch randomly about the things that bother them. Users are able to view and vote on other peoples' complaints. Additionally, within the mobile application, users can see where various complaints originated via Google maps.

The application consists of 2 components. Firstly there is the Android application that runs on a user's mobile device. Second, there is the Complainatron API, a RESTful API build using Sinatra, a lightweight Ruby web framework. The web API returns all responses as JSON. This keeps the payload reasonably small.

The Complainatron client interacts with the web API to get lists of complaints and to submit new complaints.

How does the mobile client do this? Android is based on Java, so for the most part is should be a fairly famililar process: make a web request to the API and parse the results. Here's an example of a GET request:

Fairly straightforward, right?

Converting the response to a string for processing is nothing complicated. Just loop over the stream, reading line by line and build up a string.

The next step is to create objects from the response. I achieve this using the classes from the org.json package. These classes include JSONArray, JSONObject and others. Essentially you just need to create a new JSONArray with the response from the web API.

From there, it's simply a matter of looping over the JSONObjects within the JSONArray and creating your domain specific objects from each.

Ultimately, what I end up with is a collection of domain specific objects. In this case, Complaints. These can then be used within the Android Actions to display data to the user, be it in a list, table or map.

I'll write more on this as I go.

This is just a rant. I'm not a web designer by any stretch of the imagination. When I first built this site I thought that the orange-y/red looked ok. In truth, it's that color because that's the color of the tab images! I no longer like it, though. It must (and will) be changed!

It's been a while since I've posted. Things have been busy, but that's no excuse.

Today I wanted to discuss CruiseControl.Net and how useful it can be. What is CruiseControl.Net? It's a port of the Java based Continuous Integration framework CruiseControl. From now on, I'll refer to CruiseControl and leave it at that, since most of my points can be taken in the context of either. Lots of people use and have written about CruiseControl. This is just an account of my experiences. If you are looking for a technical article with lots of instructions, you should look elsewhere as I don't want to rehash what's already been extensively covered.

My scenario:

Recently I was working on a large, pre-existing .NET web application. It was reasonably well written, but was severely lacking in both unit and functional tests. Determining whether it would build properly or not was a manual exercise. 

There were a couple of issues we wanted to solve:

We decided that unit tests and functional tests (using WatiN) were necessary. It would be foolish to try to write tests to cover the existing codebase, but going forward, we would write unit tests for new code. Additionally, we would write tests whenever we refactored the existing codebase. Functional testing would be handled slightly differently since we had a person who would be soley responsible for UI and functional testing. We knew that we wanted unit tests run whenever code was commited to source control. The functional tests would run nightly.

Another problem was that of build and deployment verification. Did the codebase build? Could you build and run the installer project?

Finally we wanted to be notified when there were problems.

CruiseControl helped us deal with these things and so far has been running very smoothly.

Setting up CruiseControl was fairly straightforward. After downloading and running the installer, I configured the Dasboard website that CruiseControl installs to allow developers easy remote access to the status of the build. There was one minor glitch in that the web.config file needed to be modified to run on Windows Server 2008 and IIS7. The details can be found here.

Next, I configured the CruiseControl server using the ccnet.config file. This consisted of defining the projects that CruiseControl would manage. Within each project you define:

The last thing to do was to install the CCNet client, a desktop application that sits in the system tray and monitors the server for changes. It notifies you when a build fails, suceeds, etc. You can also use it to force a build or to navigate the the web dashboard.

On the whole, CruiseControl seems to really have helped the development process for that project. The development team has much more confidence in their product. They know that they are beginning to get a good amount of code coverage. They know that their product builds and installs correctly. When any of these are not true, the developers are quickly made aware and can fix the problem.

I'm working on a Rails project right now. It's been a while, since I've been doing most Ruby work with Sinatra lately.

Millions of posts have talked about DRYing up controllers. I'm not talking about the skinny controller/fat model concept, necessarily, although that should be addressed as well. What I'm refering to is the constant repetition in all controllers. A create action, for example, always has essentially the same code.

I'm not writing this post to claim that I've solved the problem in some unique, world changing way. I'm really just writing to acknowledge that I see it and have decided to deal with it. Repetition bugs me. Repeatedly spec'ing the same controller code bugs me.

The bottom line: I'm writing a module that can be included in my controllers that will remove the need to constantly add index, show, new, create, edit, update, destroy and the code that goes along with them. I will test it well. I will override in the controllers to handle special circumstances. My simple controllers should NOT need to be more that 50 lines long (if that).

I guess this is actually a New Year's resolution. So there!