The application has a need for local data storage. One simple solution is the usage of using files to persist/retrieve the application-specific data, and the other end of the spectrum is using proper database services (like Microsoft's MS SQL server, MySQL etc.) to persist and retrieve the data in a relational manner.

For this application, I wanted something that is simple (ie. it does not require a service, and has simple deployment), but still has an API that allows me to focus on the object model rather than the storage semantics. It was also important to make sure that the persistency framework has cross-platform support. I've looked at various options, like SQLite.NET, and BerkeleyDB, but since the Mono website had a couple of announcements about the new GPL-licenced Db4o framework, I expected that it had been properly integrated with the rest of the environment, so I went ahead with it.

The Db4Object homepage says:

The Db4o package can be downloaded from the following location:

Db4objects Download page

Overall I am happy with this framework, as it has numerous benefits:

I did find some shortcomings, but I believe these could be addressed in subsequent releases.

I think a good desktop application platform should contain a simple persistency solution, so maybe one of the available libraries should be integrated more closely with Mono. Microsoft obviously has the Desktop MSSQL thing, and Apple just introduced the Core Data framework (using SQLite).

In terms of the framework usage, I've decided to use a DbManager facade which holds a reference to the DB4o ObjectContainer. The constructor on this Manager configure the cascading levels for the various entities. The methods on this facade return the required object hierarchies, or arrays for the application Controller.

As Visual C# Express does not contain unit testing tools (which has a bad message - not only "professional" developers should unit test), I have separately downloaded the NUnit framework and toolset.

NUnit Download page

As I've worked with unit testing tools in Java and Ruby before, the API was straight forward for me. What I was quite happy about is instead of just porting the Java Junit framework, the developers actually used .NET features (like declarative attributes) to mark test setup, teardown, and actual test methods, instead of relying on the naming conventions as in Java.

Figure 2. NUnit Graphical Runner

The Test Runner tool itself was simple and good enough. I had a bit of a difficulty to get it configured properly, but after some googling around, I realized that I need to configure the nunit .config files to the exact version of my .NET runtime:

<requiredRuntime version="v2.0.50215" /> 

The other challenge was to decide how I will structure the unit tests in the solution. Eventually I decided to separate the Unit Tests into their own project. This meant that the tests themselves did not see the private classes in the other package. There's a "Friend Assemblies" feature in .NET 2.0 which enables access for designated assemblies, but for the purposes of this little project I could have just set the classes to public.

Here's how a simple test looks like:

namespace BroadCatcherTest 
{ 
    using System; 
    using NUnit.Framework; 
    using com.db4o; 
    using Bc; 
    using System.IO; 
 
    [TestFixture] 
    public class DbManagerTest 
    { 
        private DbManager DbMan; 
        [TestFixtureSetUp] 
        public void Init() 
        { 
            string path = @"c:\bc.db"; 
            Console.WriteLine("deleting now.."); 
            File.Delete(path); 
            DbMan = new DbManager(); 
        } 
 
        [Test] 
        public void Add() 
        { 
  /* actual test code with asserts */

The User Interface is one of the most challening aspects of desktop applications. The look-and-feel and the behaviour of the application really separates hobby programs from professional development. Although the application I'm building is really something that is only useful for me (I use it to catalog and track my recorded/acquired TV shows and episodes), I wanted to make sure that I can use it as a reference.

I decided to follow the Gnome Human Interface Design guidelines for development, primarily because I am a crap designer and this has several recommendations which hopefully helps me to design something that looks OK and works consistently. As the Gnome environment works on the same GUI toolkit, the guidelines there should be achievable with this framework.

The HIG document can be browsed online, or downloaded as a PDF document.

HIG homepage

To actually design the Windows and Dialogs of the application, I've used the Glade tool. Now I'm not sure if it's just because of my Windows background, but I find the multiple small-windows-flying-around layout of the tool extremely inconvenient. For a while I thought it's just something that does not work very well on the Windows port, but after testing it under Linux I can now tell you that it sucks pretty badly on Linux, too.

Figure 3. I'm Glade You Like It

On a functional level, it's also not great, as it does not have Undo support, but it works pretty reliably.

I have experience building VB/MFC/Swing user interfaces with various tools, and compared to them, there's no surprise in Glade. You need to define containers (windows, dialogs) and drag-and-drop widgets in layouts, plus define events raised by the widgets. What I did find very positive is that I was able to lay things out very quickly, and have found the alignment and sizing process rather painless compared to Swing for example.

When the windows and dialogs are laid out propery, there are two additional things that need to be done:

Glade persists all this information in an XML file. The GtkSharp assemblies contain functionality to read this XML file, build up the windows runtime, and connect the event handling code in the custom Controller class.

namespace Bc 
{ 
    using System; 
 
    using Gtk; 
    using Glade; 
    using GtkSharp; 
 
    public class BroadCatcher 
    { 
        [Glade.Widget] 
        TreeView seriesView; 
   /* the same attribute to any widget we want to bind. The name is the same
    * as in the Glade XML file.*/

        public BroadCatcher(string[] args) 
        { 
            Application.Init(); 
 
   /* This loads the glade file glade.glade,  
    *  selects MainWindow and connects it to the current Controller object*/

            Glade.XML gxml = new Glade.XML("bc.glade", "MainWindow", null); 
            gxml.Autoconnect(this); 

Unfortunately with the current MS .NET runtime I have, the "Autoconnect" method crashes with a NullPointer exception with my current glade file, while it works when executing with the Mono Framework. I will investigate this further with the latest releases, but as it works with Mono, I just decided to continue working with the Mono runtime.

The Gtk components themselves work in a "Model-View-Controller" pattern. This pattern is not exactly how I envisioned it. As an example, there's a TreeView component, which uses a Model property to store the elements for the tree/listview. I expected that I can just use my typed CSharp classes as the Model, however Gtk only works with simple arrays containing the elements rather than a collection of typed objects. This caused me a lot of mapping and iterating over my Model objects.

Other than this, I have found the API quite straight forward. Some of the components would need much more documentation, but overall I managed to hack it together. When I ran into a problem (I could not find a property on the ComboBox which controls the selected item), I got a response on IRC pretty quickly. What I'm lacking most is a set of guidelines about how to do an end-to-end application rather than just simple tutorials with one window and one simple widget. I have found numerous tutorials about how to autoconnect one window with one Controller class, but there are no tutorials on how to structure a complex application.

Currently I am using the following pattern:

I have one class per window/dialog. When a new dialog should be raised, the main controller instantiates the controller class for the specific dialog, which in its constructor uses autoconnect to bind to the new dialog. I'm not entirely sure about what mechanism to use when I want to enable communication between the controllers.