In the previous posts about UIOverlayView and KPMiniPickerView I’ve already talked about my calendar picker test case that I use to “hello world” new UI platforms. So far there is a Java Swing version, a JavaFX 1.3 version, the JavaFX 2.0 version is in the works, and there is a iOS (iPhone / iPad version).
The main excuse I had to write one for iOS is, because I found the normal picker to have a few drawbacks:
It is inaccurate; if I want to go back, say, 10 days, I give the thing a swipe and have to hope it stops somewhere around 10 days.
It takes up a big chunk of screen, relatively, for the information being shown.
The styling of the UIPickerView in general is not easily fitted into another look and feel; the rolodex-in-a-box look is very distinctive.
It is totally clear what Apple tries to do with the UIPickerView, but I do not believe that UI controls modeled after real world things (like a rolodex) are a good idea. History has shown us that writing computer programs in languages styled after human languages (Cobol) is not working out well either; all though there is something in common, the two worlds are far more different than alike. And the more I see UI’s made up of thing resembling real world objects, the more I get the feeling that they are not working out very well (the occasional exception excluded naturally). Continue reading “KPCalendarPicker”→
About 20 years ago, during the time that I was working on my bachelor, I came in contact with a small company selling wall decorations. They had a need for some simple software, so I wrote a MSAccess application for them. During the years they grew and so did their software requirements, which resulted in a major overhaul about 10 years later when the whole code base was moved to Java 1.2 on top of an Informix database (back then considered a real competitor of Oracle’s RDBMS). The best way to access the database was using JDBC, so that was the approach that was chosen. Persistency frameworks were still immature (SDO) or expensive (Oracle’s Toplink).
The whole JDBC-combined-with-Swing did not work really well, partially because I had not figured Swing out when setting up the application’s architecture, but also because Swing uses objects and I had resultsets. Jumping forward another 5 years or so and persistency frameworks finally became an affordable foundation, so it was time to slowly migrate the code base over to Toplink (which soon was renamed to Eclipselink). Using Eclipselink made my Swing life that much easier, more than I expected, but also introduced new challenges.
Up until then, using JDBC in the 10 years old style, business logic was spread throughout the application screens. Initially this was a nuisance, but it could be dealt with. But soon, because of the growth of the company, it became a problem; there were additional interfaces required on top of the database for EDIFACT, website, webshop, email data exchange and support of mobile devices. The whole thing had grown into a full-fledged ERP and all these interfaces needed to make sure business rules were followed; it became clear that another approach was needed. Continue reading “The road to a fully encapsulated layered business model”→
At the beginning of my previous post I mentioned that I was stuck in the implementation of the calendar picker, because I was using one listener for 42 ToggleButtons, and I could not find out which of the 42 ToggleButtons was actually clicked. The code I have looks like this:
* create the skin by using other controls
private void createNodes()
for (int i = 0; i < 6 * 7; i++)
ToggleButton lToggleButton = new ToggleButton();
lToggleButton.selectedProperty().addListener( iSelectedListener );
// one listener for all 42 buttons
final private InvalidationListener<Boolean> iSelectedListener = new InvalidationListener<Boolean>()
@Override public void invalidated(ObservableValue<? extends Boolean> observableValue)
// selected or deselected
boolean lSelected = observableValue.getValue();
// TODO: which ToggleButton was pressed?
After having dropped this at the JavaFX people I went into pause, assuming the InvalidationListener API would be extended to include the origin of the event (like Swing events do). After some time Richard Bair came back to me and explained that extending the API with a reference to the bean would mean additional bytes for each property. My initial reaction was; so??? It’s just a few bytes? But then I realized that JavaFX is not about controls, but about graphics; controls are just a subset in which I’m very interested, but the real focus of JavaFX is much more basic and raw. There will be applications with thousands of nodes, and then a few bytes per property quickly become megabytes and the rise of the mobile devices suddenly make memory important again. So it became clear that extending the InvalidationListener API is not wise indeed. Continue reading “JavaFX 2.0, Swing 2.0?”→