This story begins in 2008, when we, Pär Sikö and Martin Gunnarsson, decided to try to get a presentation into Øredev. We had held a presentation covering the basics of Swing and Java2D at a local JUG meeting, but to present at a big conference, we needed a demo application to show our audiences that what we said wasn't just empty words. We both really enjoy working with graphical user interfaces, so there was no lack of motivation, but since this basically was a hobby project, we'd have to do it all in our spare time. That kind of set the tone for the whole project, and for this article. Since we didn't create this application for a big customer with unlimited resources, we didn't have to do everything by the book. No pre-studies, no design documents and no requirements. Instead, we tried out new things as we dreamed them up, which in the end led to a very nice, and slightly quirky application. The solutions we present in these articles worked for us, but they're not to be considered as universal rules of Swing development. With that said, let's get back to our story.
Since our application was just going to be a container for our main work, the cool user interface, one of our first problems was to figure our what kind of application we wanted to make. We soon settled on an RSS reader, mainly because the application logic is pretty simple, which is a good thing when you want to focus on the GUI. Since there ususally is a ready made implementation of just about anything you want to write in Java, we first took a look around for a nice feed library, and quicly found Project ROME, a very stable, open source RSS/Atom library.
We decided pretty early on that our killer feature was going to be a feed list with "kinetic scrolling", the smooth scrolling effect made popular by the Apple iPhone and iPod Touch. After some prototyping, this turned out to be easier than we thought, but more about that later. Aside from the feed list, we wanted a search box, profiles (saved searches) and a timeline to show feed items from a specific time period.
Feedjii obviously doesn't look like a native application, and this was never our intention. In fact, we're pretty sure it doesn't follow a single design guideline. However, a custom look isn't always the best choice, it depends on your target users. If you're writing an application for people with limited computer experience, or say, for administrative staff at a company, you're probably better off trying to make your application look as familiar as possible - i.e. native. This will make it more trustworthy, and the users will at least have an idea about where to start looking for certain things. We've implemented the design of each component in its paintComponent method, but this is probably only suitable for small projects like Feedjii. For bigger applications, a custom look and feel is probably a better choice. There are a number of highly configurable LAF's out there, so you could get away without writing a single line of code. Using a LAF, you can also let the user select the look they prefer, or distribute different versions of your application to different users. This is also a very effective way to brand an application for a specific company or product.
We will continue this series of articles by deep diving into the implementation details and describe what we've done and how. We're also going to open source the project.
You can run the beta version here: http://www.feedjii.com/beta/launch.jnlp
What's next? Well first of all we're going to talk at JavaOne and if you're attending we'd love to see you there. Our presentation is called "Swing Rocks - A Tribute to Filty Richs Clients", on Thursday June 4, at 9.30 AM, In Hall E 135.