MoneyJar Updates – Saving user data…

Screen Shot 2013-06-18 at 17.48.40Last week I spent some time finishing the income and expense features of the MoneyJar application. Much of the work was focused around working with Swing than it was programming the underlying model (which was a simple list containing entry data). The main interesting aspects of the implementation was working with ListSelectionListeners and finding a way to select and remove transactions from the list. Hopefully I’ll be able to use some of this knowledge to implement more polished ways of adding and editing table data.

This week I am spending time trying to make the application useful. And a major part of that is being able to save user data, and then open it again later. After all, it won’t be a very useful application if you have to keep entering your information over and over.

The design problem here was how to store that information? Several ideas came to mind,

  • a comma-separated file which stores all the user’s data in a single file, separated with a comma delimiter.
  • a XML document, which nests different information in various XML tags.
  • or a database – which stores user information in a series of database tables.

The one that seemed to pop out was an XML document. A comma-separated file was problematic as it would be difficult to separate different types of data – i.e. transaction data from income and expenses in a single file. One way to overcome the problem would be to create several files, each storing specific information, or create a document processor to split the document into various sub-categories depending on the data it was representing. A database just seemed too big for this little project – although it may be a feature I may want to implement further down the line.

So my heart settled on XML, and I immediately started searching for a way to export the application’s data into an XML file. The first library that caught my attention was XStream. An opensource library that allows you to export whole objects into XML tags and fields. It’s very simple to use, and created files that were exactly what I was looking for.

I still had the problem of storing different information in a single file. But it was much easier to process the file using String tools such as substrings. To break the file apart and then parse it back through XStream to retrieve the original object.

Now the problem I’m facing is deciding on a mechanism to update and refresh all the displayed information on the UI in the easiest (quickest) way possible. It’s not as straightforward as I would like it to be, as much of the running application will have references to objects that were derived from the previous set of data. Now that the data has changed, I need to recalculate and refresh all the objects.

A few problems that I am discovering is that I am still not in the habit of creating and developing tests for my application. I still come up with a design upfront and then start coding the API and figuring out the implementation on the fly. By no means is my code what I would consider production quality, but at the same time having no previous experience in the industry and having little access to production quality code, I have nothing to compare it against.

Anyway, I’m sure my application is overdue for a little refactoring, and once I have this feature sorted I’ll have a look at how I can refactor my code to be more flexible. A little OO Analysis and Design is in order.


Comments are closed.

Powered by WordPress. Designed by Woo Themes