JavaFX on iOS and Android: Six Degrees of Separation
JavaOne for 2013 has just come and gone and there is much buzz within the JavaFX community in relation to the announcements made for this technology. Unfortunately, there is just as much buzz (if not more) that relates to announcements that weren’t made. Specifically, another year has passed and we still have not heard from Oracle if/when they are releasing a port of JavaFX (or Java for that matter) for the significant mobile and tablet operating systems in iOS and Android.
Sadly, many have come to the conclusion that this is the beginning of the end for JavaFX and that Oracle “just don’t get it”. Well, I am fairly sure that Oracle do indeed “get it” and that JavaFX on iOS and Android will happen… eventually!
Is it too late for Oracle to release a JVM and JavaFX port for these platforms? No, it isn’t. Not by a long shot! The combination of the power of the Java platform & langauge, the rich APIs and the absolute awesomeness of JavaFX itself mean that when such a port is finally available it will actually be a much better toolkit to develop mobile applications than anything I can think of that currently exists (in any language). Plus, your apps will work on just about every hardware platform on the market today including devices ranging from Raspberry Pi to high-end workstations.
So, let’s hang in there for now. Personally I am “betting my house” on JavaFX and even though I don’t expect you to do the same, I would really like to encourage you to keep the faith.
OK, what follows is based on the assumption that sooner or later JavaFX will be running on iOS and Android (and well enough to support commercial app development).
I have come up with what are my six conditions which must be satisfied for any such port to be successful. You can think of them as a kind of “Six Degrees of Separation” in the sense that the more of them which are not satisfied then the more “separated” the JavaFX apps are from true native apps. And the greater the degree of separation, the lower the likelihood of success.
Here are the six conditions that must be satisfied by JavaFX apps when compared to native apps.
1. Their look and feel is indistinguishable from native apps
This is the most important of all the conditions. We must not repeat the mistakes of the past. By “mistakes” I refer to such situations that arose when the “native” Swing look-and-feel for Windows was released (for example). This look-and-feel was initially only vaguely similar to the native look and feel and it was extremely simple to identify a Swing app that was “pretending” to be a native app. There were so many visual inconsistencies and defects that end users were made to feel very uneasy using such apps. The fact that they were “impersonating” native apps only made this worse. In fact, I remember some people actually making a conscious decision not to purchase an app once they (easily) detected that it was a Swing/Java app.
So, to me, if there are any (unintentional) characteristics of a JavaFX app that make it easy to be identified as just that then this condition has not been met.
Please note that having the standard/default look-and-feel of the OS is not absolutely required for this condition to be met as there are many types of apps such as games or visualizations or any app of a nature where “standard” widgets are not prominent that can have their own stylised look-and-feel.
2. They must load as quickly as a native apps
These days most phone/tablet apps launch pretty quickly and users expect this. JavaFX apps must do the same. The challenge here is that a JavaFX app will have to load a substantial Java platform when it launches unless Oracle can figure out a way to load the “platform” once and then have it accessible by all Java apps on the device.
To put it simply, if your JavaFX app takes anything more than a few seconds to launch then this condition is not met. Ideally, it will load almost instantaneously.
3. They must perform as well as a native apps once loaded
It’s all well and good to launch/load quickly but it is even more important that the app performs as well as a native app once it has been loaded and the user interacts with it.
Another problem with the “native” look-and-feels that ship with Swing is that even after many years of development whereby many of the visual inconsistencies were ironed-out, there was something not quite right about using such apps. For mine, whenever I used a Swing application with the Windows look-and-feel, there was always a tiny-but-perceptible “lag” every time I clicked on something, resized a window or simply navigated around the application that once again brought the fact that this was not a true native application into the front of my mind. Such delays/lags may not actually be longer than half a second or so and sound insignificant on paper but do indeed play an important role in the “user experience”.
So once again, if the user detects noticeable lagging or pausing in a JavaFX app then this condition is not met. Similarly, if rendering graphics or loading content is noticeably slower within a JavaFX app than within a native app then this condition has a “fail” mark next to it.
4. They must be able to utilise all (or at least most) of the native APIs, devices and features that native apps can utilise
Getting Java and JavaFX to run on iOS and Android is really only the start of what is required to have a toolkit/platform suitable for serious commercial software development.
For these types of devices in particular, it is absolutely vital that native APIs and native devices can be utilised by JavaFX applications. For example, on iOS there are several keyboard “styles” and configurations such as QWERTY, a numeric keypad and a keypad with symbols such as ‘@’ and “.com” for simpler entering of email addresses. There’s nothing more annoying than visiting a text field that only accepts numbers and being presented with the full QWERTY keyboard minus the digits or needing to enter an email address and having to change key layouts to locate the ‘@’ symbol.
Also, in addition to native OS quirks, a JavaFX app has to be able to communicate with devices such as the camera, GPS, battery etc. or the range of possible mobile apps will be seriously limited. Fortunately JNI/JNA will probably come to the rescue here for any features not accessible from the standard JavaFX/iOS/Android API.
So for this condition to be met, JavaFX apps will have to be as competent at interfacing with the native OS and devices as any true native app.
5. They must be as available as native apps and available from the same channels (e.g. iOS app store)
There’s little point in developing apps for mobiles and tablets using JavaFX if they come with “special” (read irritating) deployment requirements.
Basically, for this condition to be met, JavaFX apps must be available wherever native apps are available and be able to be installed in exactly the same way. This definitely presents some challenges for Oracle given that some of these stores (especially the iOS app store) impose strict conditions on many aspects of the apps submitted for release there. JavaFX apps must (somehow) be free of any limitations imposed “just because they are written in Java”. If they are hobbled in any way, this condition is not met.
6. They must be as easy to update as native apps and through the same channels
This clearly follows on from the previous condition. Once JavaFX apps are installed on mobile and tablet devices, they must be able to be updated in precisely the same manner as true native apps. If any extra or non-standard steps are required to update a JavaFX app then this condition has not been met.
Only when all six conditions have been satisfied will we have a viable port of JavaFX to mobiles and tablets. Anything less than that is a fail.
I hope Oracle both agrees with me and is taking notice!
Just my 2 bits