Frank Sommers: What is JavaFX Mobile, and how does it differ from the version of JavaFX you released late last year?
Jeet Kaul: JavaFX is a platform for creating rich Internet applications, not just for desktops, but also for mobile devices, and JavaFX Mobile targets the latter. Over time, we will add [support for] other types of “screens” to JavaFX as well.
JavaFX Mobile has two key components: a revision to the JavaFX SDK, and, second, the JavaFX runtime, which includes support by various partners for that runtime.
The JavaFX SDK was downloaded over 100,000 times since last November, and there were many additional downloads of the JavaFX Eclipse plug-in. We have taken the JavaFX SDK, and made some revisions to it to make it suitable for use on mobile devices. There is no separate mobile and desktop SDK, just one JavaFX SDK.
The SDK has a common set of APIs. If developers write to that common API, they can test their application immediately in a mobile emulator that we just added to the SDK. We also extended the JavaFX platform to a [Java ME] mobile profile. The mobile profile has the APIs to allow a JavaFX developer to tap into Java ME directly and, through that, into specific device capabilities, if needed.
Frank Sommers: How does JavaFX Mobile relate to Java ME?
Jeet Kaul: When you develop an application in JavaFX and deploy that application to a mobile phone, the JavaFX runtime on that device runs on top of Java ME. JavaFX allows you to tap into any of the capabilities of the Java ME stack, and get access to any device functionality ME provides.
This way you can create apps that have great UIs—text, animation, graphics, audio, video, and so on—but also have direct access to the ME stack. Any ME capability, such as access to Bluetooth, location data, access to a phone’s camera, is available to the JavaFX application. If you’re building a location-based application, for example, you can directly tap into the ME Location API. We have several content partners already building applications that make use of those capabilities.
At the same time, JavaFX Mobile brings an entirely new set of capabilities to Java ME-based mobile devices. For example, the JavaFX Production Suite, which is a set of plug-ins for [Adobe’s] CS3 and CS4, can now be used not only to integrate assets into desktop applications, but also into mobile ones as well. And you can view those assets in the context of your mobile application via the JavaFX Mobile emulator. Folks who have done mobile development know that graphic integration with a smaller screen size is an even harder problem than similar integration for desktop applications. So we extended the Production Suite to work with the Mobile emulator.
Frank Sommers: How do you intend to ensure that the JavaFX runtime is available on many popular mobile devices?
Jeet Kaul: The JavaFX runtime can be deployed in two ways: It can be embedded into a device via OEM partners, or it can be delivered over the air. The JavaFX runtime can be packaged with an application, and the entire package can be delivered to MSA-class [Mobile Services Architecture, JSR 248] devices. We are giving operators a choice in this way: to deploy JavaFX on new devices or deploy content on existing devices [with Java ME and MSA already present].
The most important thing for us now is support and validation from industry partners, and two of the world’s largest OEMs, Sony-Ericsson and LG Electronics, are already providing support for JavaFX, and will be rolling out devices with the JavaFX runtime. We are also in discussion with other OEMs. Orange and Sprint are two operators that have expressed their support already as well. In addition, some ISVs are already building applications, and we’ll be showing some of those apps running on Sony-Ericsson and LG devices at the [upcoming] Mobile World Conference. Because JavaFX is built on top of Java ME, these OEMs and operators realize that they can leverage their existing investment in Java, and extend it to build rich Internet applications for mobile devices.
Frank Sommers: You mentioned the MSA APIs. Does JavaFX require that a device have an MSA-compliant Java stack?
Jeet Kaul: There is a whole range of devices that are covered by Java ME, all the way from voice-only phones to smart phones with really capable processors. The low-end phones don’t have the screen size or processing power and other capabilities needed for delivering rich Internet applications. Java ME will continue to target the very low-end, while JavaFX targets the mid-range and higher-feature phones with the MSA profile.
That way, we know what sort of processor and graphic capabilities and basic set of JSRs are on the device, and that makes the [JavaFX] developer experience good. A device’s [Java ME environment] conforming to the MSA standard is a good baseline for what we need for a good JavaFX developer experience.
In addition to providing a consistent developer experience, we also want to provide a consistent user experience: If someone delivers a JavaFX application, and there is a basic MSA profile in place, the developer can be assured that the application will function, and will provide the user with an acceptable experience. It is possible that an OEM may want to deploy JavaFX on a different subset of Java ME, and they can do so. But we do recommend MSA for consistency.
Frank Sommers: The Java ME world has for a long time struggled with the reality of device fragmentation: Device manufacturers want to distinguish their devices from those of competitors by offering unique configurations and formats. How does JavaFX address the diverse mobile device space?
Jeet Kaul: We’ve taken two approaches. JavaFX itself is delivered only in a binary format. It’s not delivered in a source format, so you have a consistent binary across devices.
Even though we deliver binaries, it’s not one single binary that’s delivered across all the OEM manufacturers. We work with each OEM, and help them tailor it and optimize it to specific stacks available on a device. We help OEMs do the mapping from JavaFX to what’s available on the device in terms of graphics stacks, multimedia, and so on.
In addition to customizing the binary for a device, we can also take advantage of hardware acceleration, when available, which then degrades gracefully when hardware acceleration is not available. As well, we have runtime support at the API level to [help a developer] do scaling and make the application look appropriate as you move from one screen size to the other.
Second, in the programming model, if someone writes to a common set of APIs, they know [their application] would consistently run on the JavaFX runtime. The majority of applications will likely only be using the common API and the binary stack, and those apps will run fine across devices.
At that point, the question becomes what depth of integration you need into Java ME. If you look at the MSA stack, the basic services you need [for most mobile applications] are there. We think that by targeting MSA as a common layer for Java ME, we ensure a great deal of consistency across devices as well for JavaFX applications.
In fact, other [mobile] platforms may face more strongly the possibility of fragmentation, as they take open stacks and create their implementations around those stacks. We’ve had a lot of learning in this space, and we’re coming back with an approach that has so far been very well received by OEMs and operators.
Frank Sommers: What can a developer do to ensure that a JavaFX application adapts well to a variety of possible target devices?
Jeet Kaul: From an application programmer’s point of view, there are at least two approaches to making sure an application nicely adapts to whatever mobile device it may run on. Part of the problem can be solved at the API level, and part at the tooling level.
On the API level, there are calls developers can make to discover the device capabilities the application is running on, such as finding out the Java version, the screen width, and so on. You can obtain those values and build some configuration logic to tailor the application to the specific environment.
We will have, over time, both in our IDE as well as in designer tooling, templates where developers and designers can get started to ensure that their apps work in different form factors. The templates may encapsulate best practices under different circumstances, and help someone customize an application for various screen sizes and resolutions. There is no magic here, though.
For developers, NetBeans is one tool you can use to develop JavaFX applications. NetBeans knows how to deal with device profiles, and has addressed the device fragmentation problem by pre-processing and conditionals. They have something equivalent to the IFDEF statement, and a lot of the more tedious part of Java ME programming is handled by NetBeans. We are also looking into providing similar functionality in our Eclipse plug-in.
JavaFX 1.0 and the current release is targeted much more at developers than designers, and hence we’re focusing on providing an IDE environment. Later this year and into the next, we will shift our emphasis to interaction designers. We’re already putting things into the platform to support that. We’re looking at building design tools that will allow people to assemble applications in a simple, non-coding environment. Those tools, too, will help ensure consistency of JavaFX applications across devices.
Frank Sommers: How can developers distribute their JavaFX Mobile applications? Are you planning to create an “app store,” or a market place, for JavaFX Mobile developers?
Jeet Kaul: All our activities are done in partnership with OEMs and operators. There are already thousands of Java ME applications in the ecosystems of these OEMs, and our goal is to add to that JavaFX applications as well, and to strengthen those ecosystems. At the end of the day, it’s the OEM and operator partners that will help bring those applications to market. We want to make sure that ISVs have distribution access for their content. It’s a bit too early for me to make announcements around this topic, though, but will have a lot more to say about it shortly.
Previous Topic
