MoneyLounge has a Graph

For the last month or so progress has slowed somewhat but I have been able to implement a nicely encapsulated graphing module to MoneyLounge. Now when clicking on a account, investment or currency a graph will appear showing details for those transactions. The graph can be a line graph or bar chart depending on the context of what is being displayed. It's all working quite nicely at the moment. Ideally I'd like users to be able to select several accounts and see a combined graph for all those accounts and doing that shouldn't be at all hard. I'll also need to add some extra reports such as "Net Worth Over Time" and "Spending/Month" etc. 

It's starting to come together

My understanding of Cocoa is getting pretty good now and I'm churning correct code out at a pretty quick rate now. Long gone are the days where I needed to check manuals or download code samples to figure out how to do things. I've changed the main selection menu to a outline view, allow the user to see context dependent information for accounts, investments and currencies. Next to a account name is the $ balance of the account. Next to an investment is the current value of that investment and next to a currency is the exchange rate of that currency to the base currency. Stock and currency prices are automatically downloaded from the Internet in a separate execution thread when the application starts. The yahoo.finance download site seems a little tempermental at the moment, but at least it doesn't cause my application to hang. Also I've changed the popout drawer to also handle investment transactions, meaning the user can add buy, sell, dividends etc.
I'm trying to get foreign currency exchange rate calculations setup. I still need to properly implement two-way account transfers and tidy everything up. The litmus test will be if I can start using the application to record my own financial data.
Finally the user interface needs to be cleaned up and graphs implemented. A big decision is going to be whether to install and develop this in leopard. Leopard does have some nice features included in X-Code but it would be cool to keep this application compatible with 10.4 - Tiger.

Category maintenance

The whole of the last week has been spent trying to get to grips with the NSOutlineView provided by Cocoa. This gives you a standard leveled and expandable list, as shown in the window to the right. I've finally managed to implement to maintain Categories and SubCategories. No drag and drop yet but the basic functionality to allow users to view, insert, delete is all there. Even better it directly links in with all the underlying class datastructures, meaning that if you change the name of a category, say from "Cars" to "Vehicles" it will update all transactions from immediately. Surprisingly getting this all working wasn't exactly a trivial exercise. The documentation provided by Apple was a little terse and I resorted to plagiarising the only useful example I could find on the web from Big Nerd Ranch.
On a side note one thing I've started noticing about Cocoa is that is operates a quite different development for coding object events then all other development environments I've encountered. Visual Basic, Powerbuilder etc all allow you to object on an object in the interface builder, a push button for example, and directly let you write your code directly as an object property, in the "click" event for example. This means that the code tends to get scattered around the various objects that make up the window. In cocoa you write all your GUI code in a specific class for the window or application. I like this, in that it keeps the code together and hence makes debugging much easier. However for a complex window or application controller, I'm starting to find that the actual objective-c file starts getting enormous in size. Delegate methods get shared objects so every delegate needs to test what object it is that is sending the message. My AppController.m file is already up to 1,000 lines (including comments), and I've hardly started (gulp).

MoneyLounge gets a Drawer

To the right is the latest screen shot of MoneyLounge. Progress has been somewhat slow over the past 10 days but a few enhancements have been made. The most visual addition has been the implementation of a Drawer, to the right of the window. When you click on a transaction the drawer opens upon allowing you to edit the details of the transaction. For example you can change the Payee from "Woolworths" to "New World" or the amount. You can also add and remove accounts. Most importantly I've made some changes to the way that the data is stored. Since I'm new to Mac development I've been developing MoneyLounge with a very much iterative prototyping approach, and I have hit a few roadblocks that have meant that I've needed to alter the underlying classes and data structures. Hopefully now everything is in better shape and this should speed up future work. As always the biggest problem has been memory allocation and trying to debug segmentation faults and core dumps. I still haven't got my head around this aspect of Cocoa development yet and am debugging with a trial and error approach.

MoneyLounge, 9 days old

MoneyLounge is now in development. After several weeks swatting up on Objective-C and Cocoa development I've kicked the project off and have managed to put together a very simple interface with some limited functionality. So far I can import .QIF account files, load and save data and scroll through accounts, transactions and categories. Not too bad a start, given it's only been 9 days so far. I was a little worried about how I was going to store all the data, but Objective-C supports a quite robust class archiving and encoding protocol, that allows you to very easily store an object-graph directly to disk. This means that assuming you've followed the flavor of Object Oriented Design encouraged by Objective-C, i.e. wrapping all data in classes, then load and saving the data stored in those classes is quite trivial. My one big headache so far has been memory allocation. Objective-C doesn't do background garbage collection for you and it's system of object retention is a little confusing for someone like me. I've been developing in languages like PL/SQL, PeopleCode & Powerbuilder for a few years now and allocating memory and cleaning up objects is something you just don't have to worry about. I've also found Objective-C to be somewhat verbose. To append one string to another string and assign it to another string in most languages you'd use something like:
s1 = s2 + s3.

In Objective-C that becomes:
s1 = [[s2 stringByAppendingString:s3] mutableCopy];

Still, you get used to it. The screen-shot attached to the blog is NOT some sort of early, primitive GUI design for how the final application will look. It's simply a bunch of text views to allow me to check that data has been loaded correctly. If this thing ever gets finished it'll be fun to look back at how the application looked when it was nine days old.

MoneyLounge

Tired of hanging on to that old PC just to run MS Money when you wish you could keep track of your finances on your Mac? This is the situation I’ve found myself in for the last 3 years since switching over to OS X and finding a serious scarcity of applications that could load all my old MS Money data and allow me to do all the same things that MS Money could. I know there’s Quicken, and Moneydance and a whole host of financial programs on the web that I could potentially use but aside from the various lackluster reviews I’ve read there’s also the issue that none seem to have anything close to the groovy Mac interface that we expect from programs running on OS X. Why can’t we use a Coverflow like interface to swipe between our bank and investment accounts. How about dragging a transaction from one account to another to setup a transfer or throwing $100 from your Visa Card to the petrol pump icon to record that money you spent at BP last week. Let’s face it, keeping track of your finances is a pretty boring chore for most of us and the spreadsheet style interfaces of most of the applications we have to choose from aren’t exactly making this task any more interesting.

The idea of building something like MS Money for a Mac as been floating around in my head for a few years now and I’ve decided to take 2008 off work to have a crack at actually doing it. I’ve got a whole bunch of obstacles that’s going to make this a tricky ask, the trickiest being that I haven’t coded in Objective-C or Cocoa before. Objective-C is a ominous looking language that has been chosen by Apple as their preferred development tool for building OS X applications. I’ll be working alone on this at the start and keeping myself motivated is going to be a challenge. When you’re working at home and it’s a nice sunny day outside it’s sometimes hard to stay focused on fixing that annoying bug or researching some obscure piece of Cocoa API. The actually code required to keep track of financial transactions, download stocks and so on is actually quite simple, it’s going to be the User Interface that will be the big ask. I’ll try and keep updates of my progress coming through on this blog, so stay tuned and I hope I can come up with something to impress.

Of microphones and Mac's

A few months ago I tried making a movie in Final Cut HD 3.5 of a recent trip around the world. During the editing process I needed to make lots of voice over's, to say stuff like "..and here I am in New York, oh, and look, there's the Statue of Liberty"... As well as having a terribly boring and unexpressive voice I was also let down a little by the microphones that I was using to record the voice overviews. Today I decided to get to the bottom of what the problem was and try and figure out exactly what the issue was with my sound input. To do this I tested 4 different microphones that I've somehow accumulated over the years. The first was a simple Philips SBC ME570 showgun Mic (as shown to the left). This Mic is self powered (it has a battery in it) and plugs into the computer thru the standard analog audio-in Port. When using this the sound levels were terrible. Even when I raise the input volume to maximum on my Mac I can still hardly hear anything. After doing some reading up on this problem it seems that you really need to buy a Griffin iMic and connect the microphone thru that in order to get decent sound levels. I next tried the USB microphone on my Steel sound gaming headset. The volume levels this time were excellent, although it only picks up sound close to the microphone. For voice-overs it seemed fine, and the Mac was able to detect the "C Media USD Headphone Set" immediately. I next tried an external iSight camera, connected via firewire. This couldn't directly feed into GarageBand but I was able to record a voiceover into iMovie. Again the sound was pretty good, but the camera itself was somewhat unwieldy to hold when making the voice over. Lastly I tried the internal microphone on my iMac. Input volume levels were pretty ordinary unless you stick your face up right next to the screen. It also picks up a fair amount of background noise and there is a faint echo and the hint of distance when listening to the playback. 

I'll be using my USB headset next time I need to make a voiceover for a home movie. The sound levels are good and it let's me keep my hands free and doesn't pick up background noise.