Two geeks discuss Mobile/RIA stuff over coffee

Transcription

1 JavaFX / Android Competing technologies or ideal partnership?...or (preferred title)... Two geeks discuss Mobile/RIA stuff over coffee Set up One Sony-XPeria mobile device complete with JavaFX demo loaded Two-coffee cups filled with hot, imaginary coffee Some slides

2 Introduction Mike: Andreas: Hi, my name is Mike and this is Andreas from Canoo, Basel... also known as The Mecca of RIA. For your entertainment, we've created a short piece of theatre in which Andreas plays the Android guy! And I play the JavaFX guy. Part 1 - Comparing apples with pears? Hi Mike. Nice to see you back after JavaOne in San Francisco. Didn't you give a presentation on JavaFX? I did. Sun is really pushing JavaFX at the moment and subsequently there is loads of interest in it. JavaFX is really Sun's attempt to win back the client for the Java platform... which has largely been lost to AJAX frameworks, Flash and to a lesser degree Microsoft's Silverlight. Sun invited us to become an official launch partner back in 2008, which lead to us presenting some apps at the official launches in December and more recently in February at the Mobile World Congress. Yes, I've heard that JavaFX is "the new big thing" in RIA technology. But still I've been focussing on Android. Cool. Did you know that there's a version of JavaFX which targets mobile devices called JavaFX Mobile? Have you compared it to Android? Actually I have, and it seems to me that there is some confusion out there concerning the scope of JavaFX Mobile.

3 JavaFx Mobile Android

4 I agree. JavaFX is really just a presentation layer software stack, although it does include some web service and XML processing APIs. JavaFX Mobile is the same thing only with some pieces taken out to reduce footprint and improve runtime performance. However, we CAN compare JavaFX Mobile + JavaME (with CLDC etc.) with Android. Some of the functionality is clearly covered by the JSRs. This includes multimedia and Java3D support. But I would expect quite a bit of innovation in this area over the coming months. And comparing the two directly we can see some more important differences: Firstly, JavaFX doesn't appear to have much of an application framework. Not exactly true, because there is a lot of functionality available through the APIs behind JSRs. Multimedia support and 3D support, for example although it would be a mistaker to confuse a library with a framework. Also, not all JSRs are supported on all mobile devices. And at the same time high-level application concepts like Android's Activity have no equivalent yet.

5 I think it's fair to say that Android runs closer to the hardware. Many of the libraries are for the most part native. The whole Dalvik VM was designed from the ground up to conserve memory and power consumption. Part 2 - Presentation matters! That is all true, but what this picture does not show is that JavaFX has a powerful DSL, which enables the creation of some pretty cool looking GUIs in relatively little time. Professional designers can also participate in the development process using their favourite tools such as Photoshop or Illustrator. Let me show you an example! The following screen shot is of Photoshop CS3, which a UI designer used to construct the static look of an application we call Music Pinboard. Music Pinboard is a music browser, a demo application created specifically to experment with JavaFX.

6 NetBeans 6.5 was subsequently used to add functionality to the UI. Our experimentation with JavaFX continued with the development of a mobile version of Music Pinboard, which runs under JavaFX Mobile. Incidentally, I don't really consider JavaFX to be scripting language in the Groovy sense because you need to compile at design time. Nevertheless, even a number of improvements could certainly be made to the DSL, it is already pretty powerful, as you can see. A couple of things that make it so easy to do animations, for example, are the concepts of binding and the Timeline.

7 Yes, but Android can do stuff like that too. Whilst it's not a DSL and it doesn't have Timeline or bind concepts, the API is still pretty easy to use. Let me show you an example... In just a few hours Andreas succeeded in duplicating much of Music Pinboard Mobile's UI functionality. Most of the UI was determined using XML files external to the Java code. I have to admit, that is pretty cool. But how can you involve designers in the development process? At JavaOne Sun previewed a next-generation Design Tool, which will enable the UI designer to define the application's complete interaction model. Most of the GUI's layout and look is declared in XML files external to the main program. It wouldn't take much effort to create a tool which exports XML in this format.

8 There are several open source design tool projects for Android. Whether or not their scope will include animation, timelines etc. remains to be seen. Part 3 - Prospects of marriage? One thing I really noticed at JavaOne was that Android was barely mentioned at all during any of the Keynotes, even though Jonathan Schwartz actually demo'd JavaFX running on Android at JavaOne '08. Some of us have since been hoping for an Android compatible version of JavaFX. So suppose I've written an app using JavaFX mobile. Is there any prospect for getting it to run on an Android device today? After all, I don't want to have to write it twice. Common Java bytecode, but the similarities stop there. Here the respective development cycles of JavaFX Mobile and Android. The brick wall represents the barrier to porting the JavaFX application: SRC JavaFX Java(A) COMPILED Java Bytecode + javafxrt.jar Java Bytecode + android.jar Dalvik Bytecode RUNTIME JavaME VM (JSRs) Dalvik VM (Core libraries) Let's consider for a moment what this would involve technically... One option would be to cross-compile the JavaFX program to Android (Java) code.

9 Running JavaFX programs on Android Option 1: Cross-compile to high-level Android code: SRC JavaFX Java(A) COMPILED Java Bytecode + javafxrt.jar Java Bytecode + android.jar Dalvik Bytecode RUNTIME JavaME VM (JSRs) Dalvik VM (Core libraries) The problem with this, however, is that JavaFX is based on Java2D and Android's UI libraries use a different API. So in addition to the cross compilation, we also a new version of the JavaFX runtime plus a new version of the JavaFX compiler which produces code for that runtime.

10 Running JavaFX programs on Android Option 2: First port or wait for Sun/Google to port - the JavaFX runtime to Android. Next, use an Android-complient JavaFX compiler to compile the JavaFX program to Java bytecodes, which depend only on the android runtime and libraries: SRC JavaFX Java(A) COMPILED Java Bytecode + javafxrt.jar Java Bytecode + javafxrt.jar (A) + android.jar Dalvik Bytecode RUNTIME JavaME VM (JSRs) Dalvik VM (Core libraries) Luckily the JavaFX compiler project is open source, but I'm guessing that modifying the compiler's backend to output bytecodes compatible with Android would be the cooperation of Sun's engineers. This all goes to show how radical Android's decision to use a brand new VM was. All of the options for getting JavaFX to run on Android are distinctly heavy-weight in nature which means someone would have to invest substantial resources in order to get an industrial strength solution. Part 4 - Conclusion Indeed!

11 With it Google addresses the problem of JavaME fragmentation by creating an entirely new implementation of Java, in which developers can program using Java syntax - thus leveraging their hard-won Java knowledge. They can also use tools they're familiar with, such as Eclipse and Intellij. Correct!... and since Android is based neither on Java byte-codes nor a Java virtual machine, it avoids licensing issue with Sun. Correct! Google then leveraged it's name with handset providers to set up the Open Handset Alliance; made everything open source and generated interest with developers by creating a $10 mio competition for the best app. An active community was therefore established in record time. Clearly it pays to have gazillions in the bank! And don't forget the major mobile handset vendors, which Google brought into the alliance. In the meantime, Sun creates an entirely new offering, which attempts to span both desktop AND mobile spaces. Included in this is a value proposition for UI designers, although it's not completely clear at the moment if this will have a big impact on acceptance. It makes the technology open source, but effectively retains full control over product development (like it did with Java.) The whole time it barely acknowledges Android's existence and is probably pretty annoyed that Google has gone off on its own, independent track. It certainly looks that way. Therefore we, and companies like Canoo, are confronted with a choice: a. Do we cover both bases by investing in both technologies today?

12 b. or pick one of the two technologies (JavaFX Mobile or Android) and focus on that? c. or withhold investment until the market decides? Let's ask the audience what they think! Audience, a show of hands please for: THE BIG QUESTION 1. JavaFX Mobile will win over Android! 2. Android will win over JavaFX Mobile! 3. The two platforms will exist happily albeit independently! 4. Sun (or someone else) will offer an Android JavaFX Mobile port! 5. Sun will sue Google for license infringement! M/ Thank you very much for your attention!

13 JavaFx / Android links Official JavaFX site: A brief introduction to the JavaFX Designer/Developer workflow (video): OpenJFX: Open source JavaFX compiler project: Official Android site: Dalvik VM, core libraries internals - Jörg Pleumann (Noser Engineering AG): JavaFX, Android, and J2ME: Sun Java licensing issues (speculation): Technical and legal Dalvik VM discussion: Dalvik VM internals (video): Official designing for performance guidelines: Brief architectural Dalivik VM introduction: