Eran Davidov: There are two aspects to that question: what APIs you use, and how a user interacts with your application. Regarding the APIs, JavaFX targets a mobile, a desktop, and a common set of profiles. If you write to the common API set, your application will run unmodified on mobile devices as well as on the desktop.

Regarding user interaction and interface design, we already support a variety of mobile handsets through the partnerships with Sony-Ericcson and LG. Those handsets have very different screen resolutions, anything from 480 by 800 to a smaller 240 by 200 screen size.

While the screen sizes of the phones vary, there isn’t much other physical difference between those screens. As a designer, you may be asking how you would lay out a user interface, if you were just doing that layout on a piece of paper. Where would the [user interface] pieces be that you want your users to look at? How would the actions take place? As you look at the various phones, the differences usually are not in how you lay out an application, but in whether, and how much, information you add to the user interface beyond the minimal controls.

For example, you may have an application that displays a set of images. In that application, the buttons for flipping back and forth between the images are going to be there regardless of device display size. The number of images, and the size of each image, on the other hand, will change from screen size to screen size.

Generally, there are pieces of an application that you see repeating regardless of the phone size, and other pieces that change based on some device characteristic, screen size being one. This concept scales up all the way to the desktop: You will have a similar set of controls on a desktop application for flipping back and forth between images, or across categories of images, but how you show the images will be different.

Thus, the first step is to identify the pieces that will be same: What do you want to show? How would the user interact with the application? Once you’re done with that part of the design, you need to determine the [UI] areas that change, and apply various techniques to tweak the changing parts.

The simplest way is just to decide that you’re designing the application for a screen size of X by Y, and have JavaFX scale the application depending on the available screen size: a very simply scaling, blowing up and shrinking down the exact same elements. That’s good for prototypes, and is very easy to do via our API.

But if you really want your application to look well on different devices, you need to add a little more logic to [scaling] it. Instead of just having JavaFX scale everything for you, you will say what areas of the screen you want to show under different [display] circumstances. You may want a matrix of images show, for example, if there is enough space to display the images. That’s very similar to how you scale a desktop application as the user grows or shrinks the window: there is a piece of code that calculates how many images to show, what spacing to apply, and so on.

JavaFX gives you the tools to say how you want to place those images, how much space you want to have between them, and the JavaFX runtime will draw those components for you, based on the logic you provide.

Frank Sommers: Are there situations where you might need to create different versions of a JavaFX application based on the intended target devices?

You just have one version of a JavaFX application, and then apply some logic in your application to determine what differences will be present given different display sizes, for example. That logic will scale the same application to different phone sizes. You won’t be creating an LG application versus a Sony-Ericcson application, or different versions based on screen sizes or other device factors. That is different from what we have in Java ME. With JavaFX, we are hiding a lot of the device-based fragmentation by providing a layer that works across all those devices.

We are providing several examples of these little glue functions that you can use to tell the system that, say, you want to put some component at a specific location, or if you want to display a component at all. JavaFX provides ways for you to discover the screen size, and you can tie a lot of your calculations to that information. Beyond that glue code, there is no change to the application: The rest of the code is the same.

For mobile devices, even the packaging is the same. The only packaging differences will be between distribution for a mobile device and for the desktop. You would use the exact same source code, but the compilation must take into account the different characteristics of the desktop versus the mobile environment.

Frank Sommers: You mentioned the ability to find out a device’s screen size from the JavaFX API. If you decide to further tweak an application, what mechanisms does JavaFX provide for finding additional information about a device, such as the CPU capability, and so on?

Eran Davidov: One of the nice things about JavaFX is that the developer can actually access the full breadth of APIs available from the underlying Java environment. With JavaFX, we’re adding a layer on top of a platform that’s very rich and that already has a lot of components. If you look at the MIDP specifications, there is a way for a user to identify the model of the device, the available memory, the screen size, and much more about the device.

The interface between JavaFX and Java is exactly the same on mobile devices as it is on the desktop: You can write Java code directly in a JavaFX application, and don’t need to create any hooks or special calls.

The way we designed JavaFX is that if you want your application to flow smoothly between the different devices, including the desktop, you stick to the common API. In our API documentation, there is button for viewing only the APIs guaranteed to be available across all the different devices. If you do want to use specific characteristics of a device, such as do something on the desktop that’s only available there, you can write that part of your code in Java, using the regular Java APIs.

On the desktop, for example, you may want to make a JDBC call. Inside your JavaFX code, you can suddenly say, in Java, Open this database connection and perform this query. You can similarly call the Swing or Java2D or any other desktop APIs. On a mobile device, you may want to access the file system, for example, to obtain records from your address book via the relevant Java ME API. You can, again, write that code in Java.

We have a sample application that shows how JavaFX ties into the accelerometer API on cell phones. If you shake the phone or, in our emulation environment, if you change the rotation of the emulation environment, you see the application actually react to that gesture. Since those APIs don’t exist on the desktop today, that application is very mobile-specific.

Frank Sommers: JavaFX may be available on some lower-end mobile devices as well. What are some of the techniques to gracefully scale down a JavaFX application to less capable devices?

Eran Davidov: Some that scaling we do automatically for you, and some things you’ll have to think about a bit more. One place where you’ll see differences is when you starting adding a lot of animation and effects to your application. As you build a JavaFX application, we hide a lot of device characteristics, but at the end of the day you may be running [your application] on a much lower-CPU device, something with a 200-150Mhz processor, as compared to, say, a 2 GHz desktop machine.

Let me illustrate that with the images example I alluded to earlier. The user clicks on a “Next Page” button, and you want to remove all the images from the screen and plug in a new set of images. If you do this in an interesting fashion, as a designer would usually think of in a rich Internet application, the images would swoon out of the screen and a new set of images would swoop in. As you design the application, you can look at the device characteristics, and you can say that you want the images to swoop in in two seconds. You can use the JavaFX animation framework to specify that from time 0 to time plus 2 seconds the images should move from one location to another. That’s really all it takes in JavaFX to create the animation.

On the device, as the [JavaFX] runtime draws the animation onto the screen, the runtime will calculate how many frames per second it can actually achieve, and it will make sure that within two seconds all your images flow into the screen. The difference [between devices] will be in how many frames you actually see. A lower-end device may only be able to do 15-20 frames per second, whereas a higher-end one may be able to do 30-40 frames per second. The application is still the same, but the flow is going to be different. That happens automatically via the JavaFX runtime.

If you want to actively take part in this, you can use the JavaFX API to change the animation characteristics yourself. You can tell the software that, instead of 2 seconds, take 4 seconds, or that you don’t want animation at all, and you can even limit the number of components you animate on the screen at a time.

There are many tweaks you can do in embedded programming, but we try to hide as much of that complexity as possible with the JavaFX runtime. So your application will work across all the devices where JavaFX runs, and you can decide what to customize as you look at your application in different target environments.