• The delete menu item changes according to the current user interface selection. If an account is selected, it displays delete account. If an user is selected, it displays delete user, and if an account operation is selected, it displays delete account operation.
• It is possible to undo/redo the actions made. The major improvement I pointed out on the previous post is almost done, so you can reverse the addition, edition and deletion of users, accounts and account operations.

I've made a new hierarchy in the controller layer. I created the interface UIAction, with methods execute, undo, redo and getName. I created an abstract implementation, GenericAction, where I made final those methods -to avoid the concrete classes reimplementing them-, calling doExecute, doUndo, doRedo and doGetName (which currently doesn't make much sense), followed by a call to update (a private method which updates the information displayed on the main window).

The doWathever methods are protected and abstract, so the actions extending GenericAction must override them. This way, each action implements its own behavior for that methods, but at the same time complying with the generic behavior without the an explicit call to super. It follows the Template method pattern.

Besides, I made a CompositeAction class, following the Composite pattern, so several actions can be grouped into another.

This way, all the defined actions are commands, and the application itself has the responsibility of executing them. Whenever an action is executed, it is stored in an undoable actions stack, and its name is set in the edit menu, so you can read "Undo actionName". If you undo the action, the application takes it out from the stack, invokes its undo method, and adds it to the redoable actions stack. After that, its name will appear in the edit menu, displaying "Redo actionName". Again, if you redo the action, the application takes it out from that stack and invokes its redo method, adding it again to the undoable actions stack. And over and over again (as far as it is well implemented).

In my job I work using C# with Visual Studio 2008. I can develop GUIs real quickly, without having to withdraw time from what it is usually more important: the business logic. Here, I wanted more or less the same. I wanted a language which could let me focus on the logic without too many headaches when doing the GUI. So Objective-C seemed the right option, as there was that Interface Builder tool. But after just some searches in Google, I realized that I wouldn't be able to get the application done if I chose a language I was not familiar with.

And so I chose Java. I've done many small apps in Java when I was studying, so I feel quite familiar with it. Besides, I wanted to try Hibernate, so this seemed a very good excuse. The other reason to choose Java was SWT. Some friends and I developed an application last year using SWT. We were targeting Windows, but I recall reading that SWT was "the ultimate Java interface" in terms of native Look & Feel integration. As our application got to look great in Windows, I started coding in Java with the idea that SWT would save all my problems.

I was wrong. After two weeks developing the model layer with Hibernate, I wrote the first lines of code for the GUI. It was quite strange: I needed several days to notice that something was going wrong. The first days it was due to the following:

The special VM option -XstartOnFirstThread is also required for SWT applications to run properly on the Mac.

It is stated clearly in the Mac OS X section of their page, but somehow I didn't read it, experiencing some real awful exceptions until I found it. After that, I had several issues that almost have PennyBank development stopped. First of all was the lack of a good Visual Editor in Eclipse. OK, there was the Visual Editor plug-in , but I wasn't able to get it working:  its support seemed to have been dropped off, and there was no sign of activity in its section for the last two years (Jump here if you don't want to read the rest and want to find which solution I found). After that, I wrote the first example of a toolbar.

It was... weird. I was looking at the main window, knowing that something wasn't right, but unable to tell what it was. The toolbar! This was NOT an OS X toolbar!After that, I knew that I had no reason to keep using SWT, as it wasn't giving me the integration I was expecting, nor it was giving me any ease of visual programming. I found a blog where someone built an unified tool bar using SWT, but it looked too much of a hacking for me. So I moved to Netbeans: I knew it had a tool for writing GUIs so even if I would be coding a not-so-nice application, at least it would be faster.

Using Maven proved here to be a very wise decision: migrating from an IDE to the other was painless. But I didn't stay with Netbeans too much: after an strange problem with Subversion, I moved back to Eclipse. At the beginning, I even thought about developing the interface by hand. Fortunately, I found a better solution.

Even if the plug-in was officially unsupported, in this page a link is provided to have it working under the last Eclipse build. Now that I was able to do visual programming, the only point missing was the so much wanted operative system integration.

So I started searching for "Java OS X integration", finding lots of resources... until I found The One. Exploding Pixels writer has developed Mac Widgets for Java: some great widgets which gives the application a native look and feel. Another must have link is the Java Development Guide for Mac OS X. With this one and the Apple Human Interface Guidelines I think I have all the technical information I need.

Having just one category  looked enough for me, until I realized that sometimes you may want to highlight, someway, an operation. And that could be done using tags. They should be different from categories, being a more specific way to filter operations, but making easier to develop the application core.

So, right now, this is the selected choice. One operation could be categorized or not, but should be classified in just one category. Categories, themselves, can be arranged hierarchically. And finally, operations can be tagged with multiple tags.