The foundations of the application were built by considering a few of the first use cases:

  • The application should have a single main window, whose position and size is saved on shutdown and restored upon startup.
  • Users want to create new databases, with optional encryption. I used a wizard framework for this, as there were several choices to be made.
  • Users want to open databases, being repeatedly prompted for the password if it’s detected that the database is encrypted.
  • Users want to open multiple databases simultaneously, and switch between them.
  • Users want to be able to close the currently selected databases, or all open databases.
  • Users want the set of open databases to be saved at shutdown, and upon restart, those databases should be re-opened, with the last selected database being made current.
  • All the above should be accomplished from the application menu, with the appropriate menu items being greyed out (disabled) when not appropriate. e.g. If no database is open, the ‘File/Close’ item is disabled;
  • A small number of recently-opened databases should be present under an ‘Open recent’ option of the File menu; the order of this should change to reflect usage patterns.
  • This necessitated the storage of user preferences in a file, separate from any database
  • Once a database is open, allow the user to choose from several views into that database, effectively, the main screens for the application, each view being on a separate tab in the main window. Remember the open views, and the currently active one, restoring it upon restart.

Some software components were chosen during this initial work: Log4J for logging (I’ve always used it, and that’s not going to change just because Sun wrote their own system and shipped it with Java) JUnit 4 and EasyMock for unit/integration tests; Spring for dependency injection; H2 as the embedded database, accessed via Spring’s JDBC Templates (with the possibility of using Hibernate if the DAO-based approach became too onerous); Swing as the GUI framework; the Netbeans Wizard library for wizards. I’m using the JGoodies Plastic Look and Feel for Windows and Linux; Quaqua for Mac OS X.

Build tools: Eclipse, Checkstyle, EclEmma, m2eclipse. Also, some infrastructure: Subversion for version control; Maven 2 for the build; Hudson for continuous integration. Numerous metrics and static analysis tools running in Maven and Hudson to aid investigations into quality.

Writing the code for these led to several other pieces of work, some of which bordered on YAGNI (You Ain’t Gonna Need It), but were essential in any ‘quality desktop application’:

  • There was no actual financial management functionality present at this stage, and so the database schema would inevitably need to change over time to incorporate new functionality. So, ensure that the code and database schema versions were recorded in the database, to allow for schema evolution upon software upgrade.
  • No application is complete without an About Box, but this one was useful, giving developer credits (essential, if a community was to form around the application), and license information.
  • Although using test-driven design and development, with continuous integration throughout, there would inevitably be times when something went wrong and a user would have to repair their database, so a rudimentary facility for diagnosing database problems was added, in the form of a special view screen containing an SQL console.
  • This view wasn’t to be available unless explicitly requested, so a Tools / Options dialog was added, to which parts of the application could contribute options panels.
  • The settings chosen in the options panels were stored in the user preferences file.

I considered the initial user experience, and how the user might engage with the developer community, send feedback/bug reports, and receive notification of new releases:

  • Provide a ‘welcome screen’ that explains the overall facilities of the application. Show this automatically on first startup, but not on subsequent startups; allow it to be started from the menu.
  • Provide a ‘What’s new in this release’ screen that shows a nicely-formatted change log of changes and enhancements in this release of the software. Allow this to be easily shown from the initial welcome screen, and the menu.
  • Allow the detection of fatal exceptions via a problem reporting dialog that would provide a user-friendly synopsis of the problem, and sufficient detail that could be cut-and-pasted into an email, to be sent to the developers.
  • So that users might discover new releases of the software, add an update availability checker. Note: this is not an update download system as in Firefox
  • If an update is available, inform the user via a nicely-formatted display of all new functionality from the version the user is running, to the latest release version.
  • This update check would have to go out over the Internet, and some users are rightly concerned about applications that ‘phone home, so before any update check could take place, the user must be asked whether this is acceptable to them; this choice must be stored in the user preferences.
  • If they allow the update checks, schedule a background check for updates (only runs once in a given day), and also allow the update check to be manually triggered from the menu.
  • Applications that spew many popups into the user’s face when they start up are infuriating if you just want to get work done. Although it’s inessential to the correct operation of the software, I felt that the welcome / what’s new messages on first startup / upgrade were important enough to be shown automatically. An update check would happen soon after every startup, and if the user opened the application each day, this could rapidly become tiring, and they’d want to turn the feature off. So, a simple message queueing system was introduced such that parts of the system that wanted to get the user’s attention would post a message to a queue. The presence of any messages in that queue would enable a button on the main window that would pulse gently, but not in an obtrusive manner. The user could click the button and see the message list – or, they could completely ignore it.
  • Allow for certain messages to be presented with a ‘Don’t show this again’ checkbox whose state is persisted to user preferences.

That’s quite a bit of functionality, and apart from a few screens in the ‘new database wizard’, there wasn’t much in the way of personal financial management functionality present. It was time to rectify that.

However, it was mid-December 2008, and Christmas was approaching. The above code was written using an old IBM Thinkpad running Ubuntu Linux, on the train during my morning commute. (This ‘hour a day’ will be a topic for another post) Over Christmas, the development office kindly provided by South Eastern trains was no longer available, and any spare time I found was spent working on another ongoing project for a while, until mid-February 2009. Then, I switched to a Mac as my main development system. I also had an idea for another project – also a desktop application using an embedded database as its storage.

… to be continued.

Advertisements