See you in June
I haven't typed a single line of code since the Easter Week Holidays. Besides my daily job, I should be finishing some assignments I've been given, so this personal project has been pushed back in my priorities stack. I'm not going to give up so easily: I think it's just a matter of time, and in the worst case I will be back here in June.It's a pitty, because the application is very close to a functional-enough state. Or maybe it is better this way, as I feel the urge to come back developing as soon as possible, instead of thinking that "as it works right now, there's no need to keep working".
Undo, redo support using patterns
This Easter Week has been very productive. Although I didn't upload the screenshots as I said, I've made several interesting improvements.
- 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).
Swing JTable
I've been working hard these days, and I almost have an usable version of PennyBank. Right now, users are able to create and delete users and accounts, operate with those accounts (deposit, withdraw and transfer), displaying account operations, and importing movements from Cashbox PList files.
I will provide with some screen-shots as soon as possible, but today I wanted to talk about Swing JTables and their TableModel property. Tables are great tools when you need to display a collection of data, so you can arrange it in rows (one row per element in the collection) and columns (one column per attribute in the element).
JTables are quite easy to use. You need to declare the table itself, give it a model, and display it in your panel. Depending on the model you choose, you can edit the table's cells, you can display the elements according to their type...
Even when Sun's tutorial is nice enough to have the basic necessities solved, these three articles I found on InformIT are very good pointing at the changes you may probably want to do with your tables:
Now, I still have to give my table the OS X standard Look & Feel, painting even and odd rows with different colors each one. This link provides some good steps to accomplish that task.
Some (unasked) explanations
When I started developing PennyBank, the first decision I faced was the programming language I should use. I wanted something that looked integrated in the system, like iTunes, Mail, iCal... The first choice was obviously Objective-C, with the interface done in Interface Builder. I had followed a small tutorial, and doing a trivial application (a calculator, I think) had showed me how good its visual programming was.
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.
Misunderstanding Hibernate
These last days I've been doing more JUnit tests. And thanks to them, I've discovered some serious misunderstanding I had about Hibernate, Cascading (yes, again) and ManyToOne, OneToMany relationships.
The first mistake I have was start coding too fast. I started following a tutorial, but I confess that I focused too much on code, an little on the theory. Following that tutorial I set a OneToMany relationship between an user and his accounts. Somehow, I thought that the account list in the user side would get filled automagically, driven by the annotations I was using. As the accounts got dropped from the database when I deleted an user, I thought everything was alright, and I didn't think about too much.
Yesterday, doing some tests on the category entity, I found that in a child-parent relationship, the child didn't have its parent category updated when I deleted that parent category. In the database I had set "ON DELETE SET NULL", and looking at the database while performing the tests showed that it was working there. But Hibernate didn't seem aware of that behavior, and the link to the old parent category still appeared in the child. That led me, after some tries, to understand how cascading was supposed to work and how badly I was using it. I had several cascading annotations in the ManyToOne side of some relationships, which meant that when I made a change on the many side, the other side was getting affected. And that wasn't the behavior I was expecting!
I went to the documentation to learn how should annotations work, and what did they mean according to the context they were used in. After that, I removed most of my annotations, and made some changes, in the update and delete methods in my DAOs to spread the changes when that was needed.
Now, an user has a list of accounts. When an account is created, it sets a reference to the user who has it. And makes that user add it to his account list. When an account is deleted, it makes the user remove it from the account list. As the account operations have a reference to an account, Hibernate is responsible to update that reference.
The categories behavior is similar. When a root category is created, it creates an empty list of child categories. When you add a child category to a parent category, you add that child to his parent list. When deleting the parent, you have to go through the list, updating all the references in his children. When deleting a child, you have to remove it from his parent list.
After these changes, everything is working now. I know that some of the tests I've done are too bound to my interpretation of the behavior they have to show, and so they may be wrong. But at least I get rid of part of the errors I still have.
Hibernate common errors
Just two days after I blogged about the errors deleted entity passed to persist, detached entity passed to persist and id to load is required for loading, some people came here from web searches.
As I'm not sure if those explanations were clear enough, I'll try to synthesise here:
- Deleted entity passed to persist. One entity, supposed to be deleted, is still referenced / accessed. In my case, I had a problem with "cascading". The behavior I expected was "on delete cascade" and "on update cascade". I have those constraints well in the database, but they weren't right in the Hibernate annotations. After I changed that, the error stopped. While I was searching why I was getting this error, I've seen people whose problem was different. They had, let's say, a list of entities. Those entities were related to others, and, when deleting, they had to take care of deleting both the link and the persisted entity. This was the most common scenario of this problem, and is better explained here, for example.
- Detached entity passed to persist. One entity, which is supposed to be up to date but is not, is passed to persist. In my case, I was trying to create an entity (an Operation), related to another (the Account where that Operation was taking place). The persist action was failing because my version of the Account was incorrect. The solution was just to update the entity.
- Id to load is required for loading. Trying to access an entity without giving an actual identifier. In my case this was the easiest problem: I was calling find passing a non initialized long. Passing the correct, initialized values fixed the problem.
Testing…
Today I spent all the afternoon testing. It may seem a tedious task, but after a while it gets quite challenging: you know there are errors in your code, so the objective is finding them. And while doing those tests, correcting the actions which showed wrong, I implemented some new ones.
The application is getting closer and closer to an usable state, and I expect it to be running in about two or three weeks.
Today's odd error was a lot easier than the others: id to load is required for loading. Maybe not the most complete description, before you find the place it is failing, but good enough once you go to the correct line number. I was using some fields in an Action which I haven't initialized yet. D'oh!
Mind the Cascade
Today I decided to go through the model layer, implementing as many JUnit tests as I could, and completing all the actions I hadn't implemented yet. As I said before, I had just decided to stick to one-category-at-a-time scheme, having a hierarchical relationship between categories.
I thought it would be easy: change the Category entity, check the on delete and on update constraints in the database creation script, refactor and go on.I also had in mind some refactor in my JUnit tests: I have just two cases, one for each Facade, and several methods inside, for each of the actions in that facade. But as the application was getting larger and larger, I decided to have one JUnit case for each Facade Method, with several test methods for each of the possible scenarios I can think of.
So I was there, refactoring tests, moving some code to the setUpBeforeClass and tearDownAfterClass methods, when everything started to break:
deleted entity passed to persist and detached entity passed to persist. After some research in Google, I understood what could be causing the second error, so I solved it:
I was using an entity in a call to persist which had been "left" unchecked by the entity manager (detached is the word, but I didn't know it). I got the entity again by invoking find, and passed it fresh, and it worked out.
But the first problem was harder. Google didn't shed any light on me (apparently), as everything was about deleted entities which were still referenced by others related to them. I didn't have any entity left: this was happening in the tearDownAfterClass method, and I was removing the entities left after the test. And then I realized that most of the clean up was supposed to be done by cascading. So, maybe cascading tags were incorrect. I checked out my classes, and I changed some of them: putting the explicit ones instead of CascadeType.ALL. I still have to test some of the Update methods, but for today, it's fixed.