JavaFX on iOS and Android: Six Degrees of Separation

Background

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

Felix

Posted on September 30, 2013, in JavaFX and tagged , , , . Bookmark the permalink. 32 Comments.

  1. Stephen Finlay

    Good points and I agree that without all six it would be a fail.

  2. “this is the beginning of the end for JavaFX and that Oracle ‘just don’t get it’”

    The fact that JavaFX still exists at all is evidence to me that Oracle doesn’t get it. For better or worse, HTML already addresses most developer’s needs for cross-platform UI.

    “Here are the six conditions that must be satisfied by JavaFX apps when compared to native apps…”

    You have basically described what I have been lobbying for for the past couple of years: “AWT 2.0″. Forget JavaFX – let’s start over and build a nice, clean abstraction over the various native windowing toolkits. There should be one set of widgets for desktop and another for mobile. Layout management and MVVM-style data binding should be supported, as should markup for declaring the structure of the UI. Common business logic can be written in Java – only the view layer needs to change across devices. Since the Java language itself is already cross platform, this would make it much easier to build apps that target multiple platforms and form factors, but still provide the native experience you’re looking for.

    • Greg, what you are describing with your “AWT 2.0″ sounds very much like what JavaFX is today. Have you had a good look at it?

      And as for “HTML already addresses most developer’s needs”, have you seen my previous post http://justmy2bits.com/2013/07/22/javafx-lame-duck-or-golden-goose/ ?

      • > Greg, what you are describing with your “AWT 2.0″ sounds very much like what JavaFX is today. Have you had a good look at it?

        Yes. I was a member of the JavaFX development team for 2 years. I did most of the design and implementation of FXML.

        The difference between JavaFX and AWT is that, like Swing, FX widgets are all lightweight. They have their own implementation and unique L&F that is different from the underlying native OS. You’ll always be able to tell that an FX app is not native.

        AWT, on the other hand, actually uses native widgets under the hood. For example, an AWT button is actually backed by a native button. The same is true for SWT, the toolkit used by Eclipse. In theory, an AWT or SWT app should be indistinguishable from a native app. However, both of these toolkits have been around for a while and aren’t as easy to use or as capable as I’d like. So, I’d like to see a “next generation” version that applies the same philosophy, but incorporates some of the more modern design elements I mentioned (layout management, data binding, and markup).

        > And as for “HTML already addresses most developer’s needs”, have you seen my previous post http://justmy2bits.com/2013/07/22/javafx-lame-duck-or-golden-goose/ ?

        Yes, I commented on that post as well.

      • OK, you are the Greg Brown that used to work for Oracle? What are you up to now?

        Yes, I get what you are saying about AWT 2.0 and heavyweight v. lightweight. However I happen to think that lightweight gives you much more flexibility and power because you can basically build anything. Toolkits like AWT and SWT are very limited because they have to support the Lowest Common Denominator i.e. only the native controls that exist on *every* platform.

        This approach simply doesn’t scale.

      • > OK, you are the Greg Brown that used to work for Oracle? What are you up to now?

        I’m working on investment management software.

        > Toolkits like AWT and SWT are very limited because they have to support the Lowest Common Denominator i.e. only the native controls that exist on *every* platform. This approach simply doesn’t scale.

        I disagree that it doesn’t scale. All major platforms today support the majority of controls you’d want to use in any given application. Obviously, you’d expect to find buttons, text fields, drop-downs, etc. but tree views, table views, tab navigation are also commonplace today. Anything that isn’t common to all platforms could be implemented using a lightweight control, but native widgets should generally be preferred. This is the same philosophy used by SWT, and Eclipse is a pretty good example of what you can do with it.

  3. By the way, when I say “cross-platform UI”, I’m talking about an app that looks *the same* on every platform. In other words, it provides a common user experience regardless of the platform on which it is run. Many companies want this type of app because it reduces their training and support costs. For most developers, HTML is good enough to meet this kind of requirement.

    Apps written using a hypothetical “AWT 2.0″ might share the same underlying functionality but would (intentionally) look *different* on each platform. These kinds of apps would provide seamless integration with the native OS and would be indistinguishable from a native app (because they would be using actual native controls). MonoTouch provides something like this but there is no equivalent for Java. I think a lot of developers would be very interested in such a platform.

  4. There are plenty of bugs being fixed for the ios and android ports in the JavaFX bug database (JIRA). So clearly they are actively working on these ports.

    • Yes, I agree. The very fact that Oracle had announced several “JavaFX on mobiles/tablets” related sessions at JavaOne is a clear indication to me that they are working on something and that they even expected to be able to announce something significant at the conference. For whatever reason, these sessions were cancelled but that to me is just a temporary impediment. I urge everyone to “hang in there”…

  5. HTML5 is better than JavaFX in my opinion.

  6. > I’m working on investment management software.

    Incidentally, the app I’m working on now is one of the reasons I’d really like to see an “AWT 2.0″. Our client app is built using WinForms (.NET) but our back end is all Java. It would be great if we could use Java on the front end as well. Not only would it allow us to standardize on a platform and language for both client and server, but it would make it easier for us to deploy the app to non-Windows platforms. If “AWT 2.0″ supported both desktop and mobile widgets, we could theoretically deploy to tablets and phones fairly easily as well.

    • Sorry to be late, but this available-on-non-platforms-other-than-windows AWT 2.0 style thing sounds much like Qt :)
      (yes, non-managed)

      • I looked into Qt a few months back, but I couldn’t find any documentation on whether it uses native or emulated widgets. I emailed Digia support to ask them about it, but they never got back to me. :-(

      • Greg, Qt most definitely uses emulated widgets on all platforms. Having said that though, it does a much, much better job than Swing ever did…

      • It’s good that the emulation is better than Swing, but I’d still prefer a toolkit based on actual native widgets. If I had more free time, I might try to build one myself. Unfortunately, I don’t. :-(

  7. Hi Greg,

    You need to check out these blogs. http://www.guigarage.com/

  8. Indistinguishable look and feel! Sure, why can’t Oracle just do on iOS what Swing hasn’t been able to achieve on Unix or Windows desktops in over a decade, from font smoothing oddities to the impenetrable mystery of the combobox? Should be a simple matter of programming…

    This little laundry list actually show quite well why Oracle does not, and should not, put much effort into “porting” JavaFX to iOS and Android: It is hard to do really well, and it may simply not be worth the effort. The company would have to dedicate a sizable team of devlopers, working closely with Apple and Google (not bloody likely), and the result would be a second-rate way to develop iOS and Android apps that would forever be playing catch-up with the fast-moving targets that these platforms are, instead of doing much GUI innovation itself. And it would hold no appeal at all for committed developers wanting to build top-notch mobile apps, because they would learn and use the native APIs, because that’s what you do.

    Oracle would be wiser to spend their resources turning Java, and JavaFX, into a strong force of its own in the “embedded computing” area in a broader sense, and then see where it goes from there. Luckily that seems to be their plan exactly.

    • You make some good points Sebastian but you are overlooking one key point:

      Swing != JavaFX

      There’s already a project named AquaFX which shows what can be done with CSS and other methods of styling JavaFX controls (in this case for MacOS). A similar thing could quite easily be done for iOS etc.

      Besides, there is an entire class of apps that do not need to have a “standard” look and feel (games, visualisations etc.) for which JavaFX is perfect!

      • I find it amazing how quickly you do away with the vast, vast task of providing native-like look & feel on several completely different platforms as something that’s not even hard.

        And then, you know, iOS != MacOS. From a desktop developer’s point of view, these are strange lands. We’re not talking about buttons and checkboxes, we’re talking about stuff like action bars and side drawers. [1] Do you really think you could just slap some CSS on something to make that happen?

        [1] http://developer.android.com/design/patterns/navigation-drawer.html

        As for fullscreen games, sure. But the cross-platform game engine market already sports a pretty smart lineup, and I’m not sure that the future of JavaFX lies there.

      • I am not “doing away” with the task of providing quality emulated look and feels. I am merely stating that such a look and feel has been developed for MacOS and building something of a similar quality for iOS should be achievable.

    • Exactly. Emulated L&Fs are a dead end. From that perspective, Swing == JavaFX.

      AquaFX and similar projects are always going to need to play catch-up with the native L&F. They will always lag behind and will never look exactly like their native counterparts. That’s why I’d prefer a toolkit that uses actual native widgets under the hood.

      Re: games – I agree that JavaFX would be appropriate for this type of app.

      • I definitely agree that emulated PLAFs can be a bad idea (as with my comments regarding the Swing Windows Look and Feel which I still think is a disaster). However, not many people could pick a native MacOS UI from an AquaFX UI and I am hopeful that the same level of compatibility can be achieved on iOS etc.

        Anyway, for my own projects I do not need my iOS or Android apps to have a UI based on standard native components because they fall into that category of apps where this is not required. I concede though that for most developers this is not the case.

        For all of this, only time will tell. It may be a moot point if a “proper” JVM is never released for these platforms, is not properly supported or if it is released in over 6 months from now. Or, of course, if it suffers from any one of the 6 Degrees of Separation.

        Fulfilling all these requirements is certainly a tough ask…

  9. Personally I think JavaFX is coming too late to the party.

    Oracle still hasn’t bothered to provide a native code compiler for iOS and Windows Phone, which could address the lack of JIT in those platforms. And for Android, we all know the current Google vs Oracle situation.

    When targeting all mobile platforms, we already have C#, C and C++ for games, C# and HTML5 for business applications. And have been investing into these technologies for the past years.

    The lack of quality of most J2ME implementations, coupled with Sun/Oracle’s lack of interested killed Java in the mobile space, which only exists thanks to Google.

    Then Oracle presented that ADF based joke last year, which might impress MBA guys at companies, but not us doing the real development in mobile space.

    Even on the desktop, we moved back to Qt/C++ or WPF, leaving Java for the backend.

    So JavaFX in the mobile should be really be worthwhile, otherwise we won’t bother.

    • Well that’s the big, big question: has Oracle left it too late even if they release a AOT Java compiler or high-performance JVM for iOS, Android or Windows Phone tomorrow? Personally, I think not. I think there’s still a window of opportunity open there but I concede that it’s a very small window and it’s rapidly closing.

      Your reference to ADF follows along with my own impression that Oracle has its fingers in too many pies when it comes to front-end technologies. They “fully embrace” HTML5, “fully embrace” ADF and, if you believe it, “fully embrace” JavaFX. One can only suspect that at some stage they are going to “streamline” their product offerings or strategic technology choices. When (and not if) this happens I am hoping they will walk away from ADF and focus on just HTML5 and JavaFX which (as I have blogged about in the past) can quite happily co-exist as they serve different markets/niches.

      As an aside, I read today that Qt now has what they are calling a “truly cross-platform” solution for desktops, mobiles and tablets. They have the distinct advantage that they have both *announced* a solution for iOS and Android *and* actually handed it over to developers to sink their teeth into.

      I sooooo wish Oracle would do the same with a JavaFX-on-iOS-and-Android solution…

  10. Good 6 points really I like them. But what Sebastian wrote in his first comment is even better. Fulfilling all 6 points would make JavaFX firstclass crossplatform toolkit. Probably the first toolkit ever capable to be on par with native applications. It is rather naive to expect something like that. Especially in startup time or performance of ui controls. To get there would really require significant investments and still would be one step behind native platforms anyway. Not only good integration to native APIs (or better say device services /calendar, contacts, location …/) is rather difficult but also to achieve 100% compatibility with all javafx desktop APIs is a challenge (just look at WebView or media) My guess is that Oracle will deliver something that just works and throw it to the community to let people play with it. It may evolve to something successful or may not, who knows. But definitely not any game changer in Android or iOS space. JavaFX may find its customers though. I can picture javafx bussines apps running crossplatforms with the same look and feel everywhere and giving decent performance. In certain cases download size or startup doesn’t play such significant role.

    • I simply don’t accept that fulfilling all 6 criteria is impossible. And, I do in fact believe that if Oracle can pull this off then JavaFX *will* be a game-changer and something that is adopted by developers with backgrounds in languages other than Java.

      It’s certainly a very big ask but to dismiss it before it has even been released is not justified in my opinion.

      As I have mentioned, for me Oracle has to release a viable iOS and Android version of JavaFX within 6 months and by “viable” I mean something with a tick in all 6 boxes.

      If they don’t deliver then it becomes a totally different story but let’s not give up until that threshold has been breached,,,

  1. Pingback: JavaFX links of the week, October 7 // JavaFX News, Demos and Insight // FX Experience

  2. Pingback: Java desktop links of the week, October 7 « Jonathan Giles

  3. Pingback: JavaFX on iOS & Android? | Kynosarges Weblog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 134 other followers

%d bloggers like this: