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...