Multiplatform JavaFX for real – polish

Things work, they look pretty good, so it is time to start polishing. First we focus on those hard coded values for host, user and password that are so convenient for testing. The thing that is needed here is a kind of cookie, something stored locally on the device, that holds the last typed host and user. But the file system on Android and iOS are very different, so that would be quite a challenge to set up. But again Gluon already solved this problem: from the PlatformFactory you can get an instance of Platform, which again provides an implementation of the SettingService, and that is a platform specific key-value store. Perfect! Just store the values after a successful login, and retrieve when starting. That was an easy score. And the Platform class holds many more gems, like the PositionService, which most likely will come handy in another app. (more…)

Continue ReadingMultiplatform JavaFX for real – polish

KPCalendarPicker

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). (more…)

Continue ReadingKPCalendarPicker

KPMiniPickerView

In the continuing story of iPad development one of the issues that became obvious was that the UIDatePicker looked really lousy in the overall design of the hour entry application. The UIPickerView component that is used by UIDatePicker has a fixed skin that is hard to fit into another layout. This was mostly caused by the appearence it generates that it is a scroll wheel inside some kind of casing, but the casing has no outside border. So It really did not fit-in well.

Secondly the UIDatePicker takes up quite a bit of space on the screen but you cannot quickly pick another date in the same month; you have to scroll to it, possibly 30 days. I like the “normal” date pickers better. So I found the required excuse to write one.

(more…)

Continue ReadingKPMiniPickerView

UIOverlayView – painting on top of your subviews

My first baby steps are becoming toddler steps and the first classes of a generic library are forming. I have found that making my infamous calendar picker part of my technology shake-down projects, usually forces me to code parts that are very educational. So by now there is a Swing version (JCalendarPicker), a JavaFX 1.3 version (FXCalendarPicker, part of JFXtras) and soon an iOS version (KPCalendarPicker). The Swing version actually was very straight forward. The JavaFX version required me to build a spinner component for the year and month selection. The iOS had the same requirements as JFX, because the default UIPickerView takes up way too much space on the screen to be used as a subcomponent for CalendarPicker. So I developed KPMiniPickerView which basically is UIPickerView on the scale of a text field.

KPMiniPicker has the looks of a text field, but I needed some way to visually make it different, so users know that it is not a text field. I decided to do this by painting blue arrows on top of the childeren, showing the direction in which the minipicker could be slided.

(more…)

Continue ReadingUIOverlayView – painting on top of your subviews

First baby steps in iOS

Everyone seems to be developing iPhone / iPad applications lately. And let’s be honest; it’s great hardware. Long battery life, good UI, looks great. I must admit that I’m one of those “I don’t like the way Apple treats its customers and therefore I do not buy Apple” people. So I have a HTC phone, an Acer laptop, a Popcornhour media streamer, anything but Apple.

But recently someone asked me if I would be able to develop an iPad application and I had to say no. However, the fact is that business is still slow and that I’m still using my reserves frequently to make ends meet (living in a somewhat country side area doesn’t help my opportunities either). So I decided do a trial project for myself, just to see what iOS is like. Having done Objective-C somewhere in ancient history and remembering I liked it back then, was a good motivator, and I figured I would be able to pick it up fairly easily considering all of the programming languages I have coded. So I bought a book and spent a number of evenings reading through it, until I felt ready to give it a try.

I’m a strong believer in that every trail project should take on a real world situation, so you will be forced to tackle actual problems and not just the ones you think are interesting. We have a hour registration system we use internally and is used by a few of our customers. The main hour entry is done via an applet and I figured that would be an interesting test case; hour entry on the iPad / iPhone. It required me to do GUI and communicating with the back-end. (more…)

Continue ReadingFirst baby steps in iOS