Delayed

Took some time in the morning to evaluate what I had done so far. Considering the main point of this weekend's coding was to create code of such quality I would not ashamed to show it in a job interview, it didn't look that good. Most of the code was hard-to-test database glue, and none of it especially interesting or beautiful.

So I decided to put the implementation on hold. I'll take some time to think again how the persistence should be done. Even in this trivial case, I found that the object-relational mismatch really hurts. I've seen it said that ORM is the Vietnam of computer science, and I'm starting to see where those opinions come from.

Anyway, hopefully I'll get back to this later.

Progress report

Did the initial failing test, then started implementing. One thing led to another, and six hours later I've got a whole bunch of classes and a semi-complete ContentProvider backed by SQLite database. This didn't go quite like planned. Oh well, not wasted effort anyway. Will have to re-think the interfaces tomorrow to be able to create something testable.

Eclipse tricks: relative paths in linked source folders

One useful trick which I haven't seen properly documented anywhere: You can get relative paths to linked source folders in Eclipse by using the variable PARENT-N-PROJECT_LOC in the path. For example, the link from my test project (parent/TagListTest) to the main project (parent/TagList) in .project file:

<linkedResources>
    <link>
      <name>test-src</name>
      <type>2</type>
      <locationURI>PARENT-1-PROJECT_LOC/TagList/test-src</locationURI>
    </link>
</linkedResources>

EGit troubles

Damn, wasted an hour trying to push changes to GitHub. The relevant commands were grayed out and couldn't figure how to get them enabled. Finally just removed the projects from Eclipse and re-cloned the repository and re-imported the projects. Now everything works.

Mental note: Should add a Git book to reading list.

First Robolectric test running

Decided to try out Robolectric for testing, got everything set up and the first test running pretty quickly. The only problem I had was that the latest 2.0 snapshot didn't seem to work, it crashed with a ClassNotFoundException trying to locate Android.R. Switched to 1.0 RC4 and everything started working.

A screenshot for proof:

Initial design

To get started, I first grabbed a pen and paper and started drafting the minimal initial UI. I decided I need four views:

1. Home view with buttons to add an item and view a list
2. Add item view
3. Tag filter selection view
4. List view

 From here I could see that the interface the "engine" has provide to the UI has to contain at least the following methods:

1. Add an item
2. Remove an item 
3. Get a list of items for viewing

For previous experience I knew that Android had convenient UI elements that can be backed by the local SQLite data. However, this could potentially couple the data model and UI to each other. I decided I should take a few minutes to study the Android UI APIs and see if I could figure an acceptable compromise.

After some though I identified there is two levels I can try to achieve with decoupling the UI:

• Not leaking the engine's implementation details to the UI layer (easier)
• Making the engine code completely Android-independent (harder, especially if I want to use Android-provided UI and DB APIs)

The first idea I had was to split the code to three layers:

1. Android UI
2. Android Client
3. Generic Engine

The client layer provides an Android-specific interface for the UI to use. It hides most of the implementation details, but not the fact that we are using Android APIs. The engine provides a generic Android-independent API for the client layer to use. The Android would probably need inject the concrete Android-specific classes to the engine.

The second interface seems harder to get right, so I decided to start at the Android UI/Client interface first. I could define the the second interface later.

At this point it seems I could go and start writing some tests for the Android Client interface. This requires another short detour to evaluate the Android testing frameworks...

...but I'm feeling quite sleepy now

All right, about three hours spent planning and setting up. Time for bed. Trying to find a couple hours tomorrow to set up unit testing tools. Let's see if I can get some TDD going on on Android!