JavaFX Android, Early Access builds

I have uploaded a new Early Access build for JavaFX 8u40 on Android to bitbucket. You can download it here. There are a number of new features in this build that open up new possibilities.

Some of the most important features of 8u40 for dalvik are:

• created from the OpenJFX 8u40 source code
• basic support for JavaFX 3D
• basic support for DatePicker control
• basic support for Android Fragments
• integration with the Gradle Android plugin and build system

We also added a separate repository for samples, which is available at https://bitbucket.org/javafxports/samples. Since those samples use the new Gradle Android plugin, you can build and deploy them using a single gradle command.

We will provide more information about these features once we are at a stable release. Please be aware that this is an early access release, and it may contain instabilities. There is a lot of new stuff going into this build, and we are now working very hard on samples, bugfixes and documentation.
If you have time to download and test this release, please do so. Make sure to try the samples from the sample repository. All issues can be reported to https://bitbucket.org/javafxports/android/issues.

JavaFXPorts winner of Duke’s Choice Award

Yesterday, it was announced that LodgON receives a Duke’s Choice Award for its work on JavaFX Ports (http://javafxports.org) and more specifically for the port of JavaFX to Android.

I am a strong believer of Java on Mobile Clients. For a Java developer, the benefits are clear. It makes the Java paradigm “Write Once Run Anywhere” really come true. Write a JavaFX client application once, and use different stylesheets and skins for desktop, iOS and Android. From a strategic point, there are a number of reasons why I think the time is now for Java to increase its market share in mobile client applications.

Mobile Apps are the way forward

First of all, there is a clear move from desktop and laptops towards mobile devices: smartphones and tablets. This is a game changer. Client application on these mobile devices have different requirements than applications on desktop and laptop, which today are mainly web-based.
That brings me to the second reason. Where the browser is the dominant application on desktop and laptops, it doesn’t have a leading role on mobile clients. There are a number of statistics about this (e.g. see http://cdixon.org/2014/04/07/the-decline-of-the-mobile-web/) and there is also lots of discussion about it.
Many see the failure of the “mobile web” as a threat to the Open Internet. While I understand some of the fears, I rather consider the decline of the mobile web as an opportunity rather than as a threat. Agreed, the tight grip of Apple on the AppStore and of Google on the Play Store might be dangerous. But the browser as the beneficial dictator deciding what can be run and what not is dangerous as well.

Today, Java is a valid choice for Mobile Apps

I don’t want to downplay the role of HTML 5, as it is a combination of interesting technologies that still have their place. However, I think the Enterprise World is overreacting by embracing it. The Enterprise World ignored the web for too long, but today we should be looking further.
Many years ago, the Enterprise World was mainly using dedicated fat clients that connected to back-end systems using protocols that were fat, proprietary, or both.
In that time, I didn’t like this approach. I still remember I re-wrote a rather complex Java client application in 1999 in JavaScript, so that I could show it to others without having them to install the Java Runtime. It was very frustrating, and it never worked on all browsers at the same time, but I felt there was no other choice than using HTML and the Web. Java wasn’t really open, and the process of installing and maintaining Java on the client was cumbersome.
As a side note, it still is cumbersome and embarassing. I feel ashamed when people come to me with their laptop at family parties and ask me what they have to do with all these requests to update “Java”. They don’t know what Java is, and there is no reason why they should.

Today, there is another choice. Today, the Java Specifications are developed by the rules of the Java Community Process (JCP). Everyone can be an individual member of the JCP. Companies can become member of the JCP. Together, they elect the executive committee, and they can propose JSRs and work on them.
The Reference Implementation for the Java Specification, Standard Edition, is created in the OpenJDK project, which is very transparant as well. Also, today we don’t require clients to have the JRE installed. We simply bundle the JRE with our applications. The JavaPackager is a very important and yet underestimated component. I hear worries about filesize now and then, but first of all, the average user today spends a few orders of magnitude more bytes on transfering media than transfering applications. Also, tools can become better, and unneeded modules, packages, classes or methods can be removed from the final application.

There are no technical reasons on why Java and JavaFX on the client should not be considered. So far, I considered my work on JavaFX on Android as a Proof Of Concept. The RoboVM people also showed that Java and JavaFX work on iOS. For LodgON and Trillian, the porting effort is considerable, but when placing this in the right context, it wasn’t a huge issue. Granted, the work has just started, and there are lots of things to do, so an increase in resources will be a requirement. But the combined effort shows that it is possible to write Java applications that run on mobile clients as native apps, which is the way forward in the industry.

Mobile apps will influence Enterprise Development

Native mobile apps are not only popular in games or entertainment, but increasingly in business applications as well. While in 1999 I was hoping the Java Enterprise world would embrace the Web, today I hope the Java Enterprise World will pay more attention to Java Clients, and not only to HTML 5. In many products and projects, the added value is often realized in the back-end.  Without providing a vendor or technology lock, Java provides a silver key for this: Java mobile apps can use REST technologies to connect with Java Enterprise rest-based webservices. The JAX-RS spec is therefore extremely important as it defines both the server component as well as the client part of the REST protocol.
Apart from REST, I think there are 2 other very relevant technologies for client-server communication: Server-Sent Event (SSE) and WebSockets. The latter is already covered in the Java Specification as JSR 356 and support for SSE is already part of some REST implementations, including the Jersey Reference Implementation.

One of the other projects I am involved in, DataFX, has a JavaFX component that allows easy interaction between JavaFX Controls and WebServices that either use REST, SSE or WebSockets. I really believe these technologies should be supported as first-class Java components, as part of a strategy for Java on Mobile clients generating traffic to Java on the Server.

Many IT projects today still require a rather complex back-end, often developed using Java EE technologies. Typically, this back-end is made accessiable using an HTML 5 website, and the Java EE specification make it very easy to create HTML 5 based web applications that communicate with a Java EE backend. However, an increasing number of clients also requires mobile clients for Android and iOS. In most cases, native clients are written from scratch for this purpose. That means the total project requires three separate clients, in three languages. That is expensive. But with the growing attention for mobile clients, it might also be dangerous for Java EE. Where the “desktop website” is today in most cases the first client, I think this might change, and the mobile clients will be the preferred clients. It will become tempting for the developers of these apps to use vendor-specific (either from Google or Apple) enterprise cloud services rather than standard protocols that connect to Java EE servers.

In summary, Java on Mobile benefits developers (write your client applications on a desktop and publish them to the AppStore and the Play Store) and it can lead to an increased usage of Java server-side technologies (e.g. cloud services). Time to take it seriously.

Mobile JavaFX Enterprise at JavaOne

I am glad the two session proposals I submitted for JavaOne are both accepted. I will be talking about DataFX and about JavaFX on Android. In this blog post, I try to explain why I focus on exactly these two topics.

There are a number of tendencies in the IT industry that we can’t ignore.  

Mobile is overtaking the desktop

As shown in the article at http://money.cnn.com/2014/02/28/technology/mobile/mobile-apps-internet, people today spend more time using devices than using a desktop. Desktops and laptops still hold a strong part of the market, but the mobile devices (mainly smartphones and laptops) are simply more relevant today.

Apps haven overtaken browsers

The same article shows that in the case of mobile, the use of applications outnumbers the use of web browsers.

If we combine both trends, we can conclude that the market of mobile applications is a very interesting one. That doesn’t mean web browsers and traditional web sites are vanishing very soon, but it clearly shows the hot spot is shifting from web pages to mobile applications.

The two major platforms for mobile devices, Apple’s iOS and Google’s Android, dwarf the other platforms. While you can write applications using Objective C for iOS, or the Android SDK for Android devices, I believe there are a number of advantages in writing your application in Java, using JavaFX as the User Interface platform.

• cost efficiency: there is no reusability of code between an Objective C application and an Android application. Using Java and JavaFX, developers can leverage the “write once, run anywhere” paradigm of Java.
• portable to the desktop: the success of appstores for mobile devices is starting to influence the desktop. We see a growing number of application stores for desktop operating systems. The same JavaFX application that is being used on a mobile device can also be used on desktop devices. The use of CSS or separate skin classes can lead to a combination of same codebase yet platform-familiar look and feel.
• JavaFX is simply a great interactive user interface platform. I like the Android services (and they are very interoperable with JavaFX, so they can be used in a JavaFX application), but for UI development, JavaFX is the clear winner for me.

In Session CON1804, Running JavaFX Applications on Android, we will discuss the current state of JavaFX on Android, provide an overview, show how to create a JavaFX Android application, and talk about future plans.

 

Another trend is the growing interest in (REST-based) “microservices” at the back-end. This is important for client applications as well. A typical business application makes a number of requests to a back-end, and expects responses as well. Mobile devices are getting more and more powerful, but still they cannot be compared with servers, clusters of servers, or a cloud environment. Many of the techniques used in server-side software simply won’t work on (mobile) devices. It is extremely important, though, that client applications can easily interact with back-end applications. This is where the DataFX framework helps. The JavaFX Platform provides a great client platform, with a strong focus on the user interface and interactions. DataFX extends the JavaFX Platform by providing components that can be used to communicate with back-end systems, and by providing a simple API that allows developers to define the flow between different parts and views of the application. We will discuss DataFX in Session CON 3640, DataFX: From External Data to a UI Flow and Back .

I preferred to focus on 2 presentations in a single area, but that does not mean I have no interest in other areas. I am still watching the evolutions for Java EE 8 from as close as I can, since I realize this is a very important piece of the whole end-to-end puzzle. Looking at the presentations in the Java server-side track, I’m convinced this is going the right way.

I hope to see many developers at JavaOne. Those are interesting times, let’s make the difference.

Pro JavaFX 8

Last week, Pro JavaFX 8 became available as a printed book and as an e-book. Being the lead author of this edition, I’m very excited.

When James Weaver and Stephen Chin asked me to take the lead on Pro JavaFX 8, I hesitated for a while. I wrote a couple of chapters for Pro JavaFX 2, and that was already an intense process. Pro JavaFX is an in-depth book, and it describe many parts of JavaFX in detail. It is not easy to have detailed knowledge about all the different parts of JavaFX. Good enough, Weiqi Gao stepped up to write a few new chapters and the original authors Dean Iverson, James Weaver and Stephen Chin promised to provide assistance and suggestions. That convinced me to accept the challenge. During the process, Mark Heckler became the tech reviewer. The knowledge that the whole book was screened with his high-quality standard, gives me a confident feeling.

There is a lot of information in Pro JavaFX 8. While updating chapters, I was often amazed on what a big change JavaFX 8 is compared with JavaFX 2. Many API’s became richer and easier to use. Apart from the updated chapters, we have a few new chapters. There is a whole new chapter on FXML and SceneBuilder, as those tools are becoming more mature and easy to use. Also, the new JavaFX 3D deserved a chapter devoted to it as well. With JavaFX being available now on embedded and mobile, we felt it was required to provide a chapter on this as well.

The table of contents for the book goes as follows:

1. Getting a Jump Start in JavaFX 8

In this chapter, you learn about the history of JavaFX and you create your first JavaFX Application.

2. Creating a User Interface in JavaFX 8

You learn how to write a JavaFX Application that programatically renders a user interface

3. Using SceneBuilder to create a User Interface

A user interface in JavaFX can be created using the API’s described in Chapter 2, but also in a declarative language called FXML, and with the help of a tool called SceneBuilder.

4. Properties and Bindings

Many cool features in JavaFX are possible because they use Properties and Bindings. Those concepts have no dependency on graphical components, but they allow a program model where the graphical components get their rendering information from values in a model.

5. Building Dynamic UI Layouts in JavaFX

In this chapter, we give an overview of layout techniques that allow you to create dynamic user interfaces.

6. Using the JavaFX UI Controls

The list of Controls (e.g. Button, ScrollPane,…) that are available out-of-the box is increasing. For example, in this chapter we describe the DatePicker.

7. Collections and Concurrency

In this Chapter, we describe one of the strong concepts in JavaFX which are Observable collections.

8. Creating Charts in JavaFX

The JavaFX Platform comes with a simple, powerful API that allows developers to render a variety of charts with just a few lines of code.

9. Using the media classes

A rich application platform requires support for multi-media. Learn how JavaFX supports audio and video.

10. JavaFX 3D

The JavaFX 3D API has been added in JavaFX 8 and is described in this chapter.

11. Accessing Web Services

Many JavaFX Applications that provide business value have to interact with (REST-based) webservices. In this chapter, we show how to connect a JavaFX Application to webservices.

12. Java on Embedded, Mobile and Tablet

Write Once, Run Anywhere. The number one advantage of Java also holds for JavaFX. This chapter talks about how to deploy JavaFX applications on embedded and mobile devices.

13. JavaFX languages and markup

There is a rising interest in alternative languages on top of the JVM. Learn how to use JavaFX in those languages.

All chapters in Pro JavaFX 8 come with code samples. We decided to make those available for free, allowing all JavaFX developers to check them out, learn from the code, and provide us and the community with feedback and suggestions. You can find the samples at https://bitbucket.org/projavafx/projavafx8

Distributing the samples for free fits in the open spirit of the JavaFX Community. In all projects I’ve been doing, I’ve hardly ever seen such a close interaction between the creators (the JavaFX team at Oracle) and the users (the JavaFX developers all over the world).

Pro JavaFX is available on Apress at http://www.apress.com/9781430265740 and on Amazon at http://www.amazon.com/gp/product/1430265744/

JavaFX Ports and Duke’s Choice Awards

JavaFX Ports, the initiative for supporting JavaFX on mobile, has been nominated for the Duke’s Choice Community Award. This is already great news, it means that the value of the porting effort of JavaFX to iOS and Android has been recognized.

This is our opportunity to give a strong signal to the community itself, but also to the industry. JavaFX Developers want to Write Once and Run Anywhere. This is still one of the strongest points of Java and we (the community and the industry) have to keep working hard on this point.

Do you want more support for JavaFX on Android and iOS? Do you think Oracle (or Google and Apple) should take it more seriously? Cast your vote at this poll.

Thanks.

It’s time to make a decision

This blog-entry is cross-posted to the Devoxx website, as I am the track-lead for this year’s server-side track.

For the Java Enterprise world, 2014 is the year in-between. The Java EE 7 spec has been launched last year, and the Java EE 8 spec won’t be released this year. At Devoxx, we’ll be looking back and forward. For some companies, it is time to decide when and how to migrate to Java EE 7. For the Java Community Process, it is time to decide what should go in Java EE 8.

While the Call for Papers is open, you are very welcome to submit your proposal on a session, BOF, TIA, Quicky. The Devoxx audience will be very interested to hear your opinion on a number of areas:

• How does Java EE 7 work in practice?
• What is the status of Java EE 8? Which JSRs will be addressed?
• What other server-side frameworks or components are improving (e.g. Spring) and why should the server-side developer bother about this?

 

Now that the first implementations of Java EE 7 are available, we would like to hear how it really works. Are there stories that show real-world numbers about productivity or performance gains, about integration with other technologies (e.g. HTML 5)? Submit them. We are not really looking into general overviews of Java EE 7 technologies, as those are already covered. But there might be a specific technology that really made a huge difference for you, and that you want to share with other developers.

Work on the Java EE 8 specifications has started, so the time is now to influence the specification. Do you have interesting ideas about something that is missing in the current Enterprise Specification? Or do you think a particular JSR is missing something important? Are there other, non Java EE technologies that are becoming more and more relevant? As you know, Devoxx attendees don’t want to hear ideas only, they want to see solutions and code. It doesn’t have to be Java EE 8 related, as long as you think there is a new technology that makes the life of the server-side developer easier or more interesting, submit a proposal.

We already received a large number of interesting proposals. The program committee will have a very difficult job but you are very welcome to make it even harder.

Using the LeapMotion Controller in location-based software

In this second part of my blog series on location-based software in JavaFX, I use a LeapMotion controller to navigate a geo map.

The May/June issue of Java Magazine contains an article I wrote on developing JavaFX Applications leveraging the LeapMotion Controller. The LeapMotion Controller is a small USB device that tracks the movement of fingers and hands. LeapMotion has its own App Store called Airspace, containing lots of applications that use this intuitive way of user interaction.

In the Java Magazine article, I explain how you can write JavaFX applications that interact with the LeapMotion Controller. Since I’m also working on location-based software, I had the idea of using the LeapMotion Controller for navigating through the map. I got lots of help from José Pereda, and in the meantime the map software I started to develop in OpenMapFX is greatly enhanced thanks to Geoff Capper. The result is a map application that allows you to browse through a map by moving your hands horizontally. Moving your hand down will zoom in, and moving your hand up will zoom out. Below is a screenshot of this application:

The OpenMapFX project is a Gradle project with a number of subprojects. One of these subprojects is called “leapmotion”. It contains only 3 classes and an fxml file.

• LeapMotionMapView contains the main application
• SimpleLeapListener deals with events received from the LeapMotion controller
• Overlay and the mymap.fxml file contain the overlay showing visual feedback on hand movements.

Apart from these classes, the leapmotion subproject depends on the core module for general map display functionality.

The OpenMapFX is an Open Source project, feel free to browse through the code on https://bitbucket.org/lodgon/openmapfx . Again, thanks a lot to José and Geoff for contributing. I hope more developers will follow and join the team.

 

Since we keep improving the OpenMapFX project, I created a tag named “leapmotion-b2” that contains the source code at the time when this blog entry was written.

In a next entry in this series, we will run the OpenMapFX software on Android devices. If you are interested in the OpenMapFX project, either from a technical or business perspective, feel free to drop me a note at johan at lodgon.com.

Location-based software in JavaFX

This is the first part in a series of posts on location-based software using JavaFX. In this entry, we will show how you can easily provide basic map functionality in a JavaFX application, by using a mapserver that renders map tiles. We build a desktop application that allows users to zoom in and out, and to drag the map. Tiles will be loaded when required.

My very first presentation at JavaOne was about map software for the JavaFX 1 Platform. Jim Weaver and I explained how you can create software for rendering maps using JavaFX Script, and we showed a few examples rendering location-based maps as well as topic maps. The code for these demos was based on a Swing-based map application from James Gosling. The code in the current project is still based on that Swing application.
Today, we can use JavaFX with its powerful concepts of Binding and InvalidationListener. Combine this with the Java 8 Lambda’s, and you have a recipe for success.

Ever since I worked for telematics provider Acunia in the late nineties I have been interested in location-based software. The possibilities with location-based software are endless and still growing. In this post, we only show some basic location functionality using JavaFX. In a next post, we will show how you can use the LeapMotion device in order to navigate through the map intuitively. After that, we will demonstrate the functionality on the Android Platform. With a growing tendency towards mobile computing, and with the increasing number of devices that are equipped with a GPS, the potential for location-based software using JavaFX on Mobile is huge.

The location-based functionality is demonstrated using an open-source project, hosted at https://bitbucket.org/lodgon/openmapfx. As this project will move on, we created a tag “b1” that reflects the project at the time of this writing. I created a Gradle project for this, and you can easily open it in Netbeans if you have the Gradle plugin installed. You can immediately run the project, and a map will be shown. You can drag the map, and zoom in and out.

The main class for this JavaFX Application is the class MapView, in the org.lodgon.openmapfx.desktop package. The code for the start method in this class is very simple:

    @Override
    public void start(Stage stage) throws Exception {
        LayeredMap map = new LayeredMap();
        Scene scene = new Scene(map, 800, 600);
        stage.setScene(scene);
        stage.show();
        map.setZoom(4);
        map.setCenter(4.2, 50.2);
    }

As you can see, we create a LayeredMap instance, and put it on the Scene. We set the initial zoom level to 4, and the initial center of the map is somewhere in Belgium.
The LayeredMap class that we instantiated is provided in the org.lodgon.openmapfx.core package. This package contains the classes that we consider common functionality across a number of location-based applications. The reason we named it “LayeredMap” is because we will add some layers on top of each other in a next blog post. Think of layers as location-based functionality, e.g. the location of your friends, or thumbnails of pictures of a specific location,… The LayeredMap takes care of the dragging and zooming, by defining some lambda expressions:

        setOnMousePressed(t -> {
            x0 = t.getSceneX();
            y0 = t.getSceneY();
        });
        setOnMouseDragged(t -> {
            mapArea.moveX(x0-t.getSceneX());
            mapArea.moveY(y0-t.getSceneY());
            x0 = t.getSceneX();
            y0 = t.getSceneY();
        });
        setOnScroll(t -> mapArea.zoom(t.getDeltaY(), t.getSceneX(), t.getSceneY()) );

A LayeredMap needs at least some basic geo-map. This is provided by the MapArea class in the same package. As you can see from the previous snippet, requests for dragging and zooming are delegated to this MapArea instance. The MapArea is a JavaFX Group, containing the map tiles that need to be rendered. The Map Tiles are obtained from the OpenStreetMap project, which — amongst other services — provides a webservice which returns map tiles as small images (256 by 256 pixels). OpenStreetMap, and other map providers, provide different images for different zoom levels. At zoomlevel 0, there is only a single tile. At zoomlevel 1, the world is divided in 2 by 2 tiles, and at zoomlevel n, there are 2^n by 2^n tiles. For each tile, we create an instance of the MapTile class. The MapTile contains an image, which is loaded from the OpenStreetMap server:

    String url = TILESERVER + zoom + "/" + i + "/" + j + ".png";
    Image image = new Image(url, true);
    ImageView iv = new ImageView(image);
    getChildren().addAll(iv);

The URL containing the request to OpenStreetMap contains the requested zoom-level and the x and y indices containing the tile coordinates.

The position and scale of the tiles is dependent on the current zoomfactor and on the translation of the map. In order to make the zooming a bit more fluent, we use a double to indicate the active zoom — actually, we use a DoubleProperty since we want the MapTile instances to use invalidation listeners that will recalculate their behavior when the zoom level changes. We scale the image up or down depending on how near the active zoom is to the real zoom factor of the image.

The MapArea controls which MapTile instances should be visible at a given time. A MapTile will be visible when its zoom level matches the active zoom level, or when the tiles for a finer zoom level are still loading. In that case, the covering() method on the tile will return true, indicating that this tile covers the same area as at least one tile with a higher zoom level that is still loading.

There is more functionality in the code that we didn’t cover, and there is more functionality that will be added to the project later. In the meantime, I am very open to questions, pull requests, suggestions, proposals. I really believe there is a huge potential for JavaFX based location software.

Using Android API’s in JavaFX.

In a previous blog entry, I talked about the JavaFX to Android porting project. Now that this seems to be on the rails, it’s time for some more integration. In this blog post, I will quickly show how you can use the Android API’s in your JavaFX application.

Before showing the code, I should stress that the current way of calling Android services from a JavaFX application is probably not the recommended way in the future. I am looking into better ways, but for now, this is the way it works.

We will create an example that retrieves and prints the location of the user (or the device, that is).

 

We assume you have the Android SDK and the JavaFX-Dalvik runtime, as explained in https://bitbucket.org/javafxports/android.
You have to create a JavaFX project. I use Netbeans 7.4 beta, and create a new JavaFX Application. The code of my application is here:

package locationandroid;

import android.location.Location;
import android.location.LocationManager;
import android.location.LocationProvider;
import java.util.List;
import javafx.application.Application;
import javafx.event.ActionEvent;
import javafx.event.EventHandler;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.control.Label;
import javafx.scene.layout.StackPane;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;
import javafxports.android.FXActivity;
public class LocationAndroid extends Application {

    private LocationManager lm;
    private String provider;

    @Override
    public void start(Stage primaryStage) {
        final Label l = new Label ("Location");
        FXActivity f = FXActivity.getInstance();
        if (f != null) {
            Object systemService = f.getSystemService(FXActivity.LOCATION_SERVICE);
            lm = (LocationManager)systemService;
            List providers = lm.getAllProviders();
            if ((providers != null) &&(providers.size()>0)) {
                this.provider = providers.get(0);
            }
        }
        Button btn = new Button();
        btn.setText("Retrieve location");
        btn.setOnAction(new EventHandler() {

            @Override
            public void handle(ActionEvent event) {
                Location loc = lm.getLastKnownLocation(provider);
               l.setText("Location: "+loc.getLatitude()+";"+loc.getLongitude());
            }
        });
        VBox all = new VBox();
        all.getChildren().addAll(btn, l);
        StackPane root = new StackPane();
        root.getChildren().add(all);
        Scene scene = new Scene(root, 300, 250);
        primaryStage.setTitle("JavaFX/Android Location");
        primaryStage.setScene(scene);
        primaryStage.show();
    }
}

In the NetBeans project, we added 2 libraries:

• android.jar, which is located in the Android SDK
• jfxdvk.jar, which is located in the dalvik-sdk/rt/libs directory

You need the android.jar in order to use the Android API’s, and you need jfxdvk.jar in order to access the FXActivity class, which is the bridge between JavaFX and the Dalvik runtime. We use a static method on the FXActivity to retrieve the FXActivity, which extends the Android Context. This Context can be used to lookup Android services. As you can see, we obtain the Android LocationManager by calling

FXActivity.getSystemService(FXActivity.LOCATION_SERVICE);

The obtained LocationManager can be used to retrieve a list of LocationProviders. We just take the first one, and will use that to query the LocationManager and retrieve the current location whenever the user presses the “Retrieve Location” button.

When you want to run this, you need to ask permission to obtain the location. The AndroidManifest.xml file that is created when setting up your javafx android application needs to have this line:

<uses-permission android:name=”android.permission.ACCESS_FINE_LOCATION”></uses-permission>

 

 

Again, this is just a very quick sample and it is not showing any best practices, but hopefully you can now start writing JavaFX Applications that leverage the Android API’s.

JavaFX and Android

I think we can consider JavaFX to be stable on the desktop, and that is a very important fact. However, the client-side in the IT industry in general is shifting from desktop to mobile. Platforms need to have an answer for this. That is why I started a community project for porting JavaFX to the Android platform a couple of months ago.

When JavaFX 2 was announced, many developers and analysts said its success would be dependent on the ability to run JavaFX applications on mobile platforms. Today, we see that Oracle has done a great job in making JavaFX available on all major desktop systems (Windows, MacOS and Linux) and on embedded systems. The mobile area, including phones and tables, however, is not covered by Oracle. As far as I’m aware, there is no official explanation from Oracle on why mobile platforms are not (yet) officially supported. I’m not happy with that decision, but complaining about it is not going to help.

Developers are usually better in doing it themselves than in complaining. With the JavaFX code being open sourced over the past years, and with lots of work already being done by Oracle people, a community-effort for porting JavaFX to mobile platforms turned out to be a viable option.

I have some experience in porting efforts, as I was part of the Blackdown team porting Java to Linux. One of the things I learned is that the community has the power to drive innovation. Big companies might jump into the area later, and I am very ok with that. The Blackdown team became rather obsolete once Sun Microsystems started to invest in Java on Linux itself, and that was a nice way to become obsolete.

Since RoboVM is already doing great work on the JavaFX iOS port (see http://www.robovm.org and consider becoming a sponsor!), I decided to focus on the Android port. I talked with JavaFX architect Richard Bair during Devoxx, and got a jump-start thanks to Tomas Brandalik who already did lots of work on the native parts and Stefan Fuchs who maintained the Java 7 backport. After only a few weeks, we delivered a JavaFX Runtime for the Android platform.

The JavaFX Android community project is hosted at https://bitbucket.org/javafxports/android/wiki/Home and it contains instructions on how to run JavaFX applications on Android. The code is currently available at https://bitbucket.org/javafxports/android-graphics-rt . This repository is a mirror of the openjfx-8-graphics repository that is used to build the main JavaFX 8 code. Based on this code, a JavaFX Android runtime is created and available for download at https://bitbucket.org/javafxports/android/downloads/dalvik-sdk-b4.zip . Note that we changed the name of the download from android-sdk to dalvik-sdk, as our port relies on Dalvik (which is available on Android devices) and not on a separate JVM. The latter would be possible as well, and some work has been done in this area, but unfortunately there is no open-source JVM that is close enough to be usable right now.

With dalvik-sdk-b4, and with the instructions at https://bitbucket.org/javafxports/android/wiki/Building%20and%20deploying%20JavaFX%20Applications, we reached a milestone. Most of the JavaFX 8 Ensemble applications are now working out of the box on Android devices. I’ve seen many reports from JavaFX developers demonstrating their applications on Android, which is very cool.

Next steps

I think we proved that there is room for JavaFX on Android devices. I know at least a few companies that are considering JavaFX partially base their decision on whether or not their application will run on Android and iOS. I think both RoboVM and our Android community effort show that it is very well possible to run JavaFX applications on mobile devices.

Going forward, there are a number of challenges that need to be addressed. Currently, only applications compiled with Java 7 can be deployed on Android. Lambdas, Streams and Defender Methods are not yet supported. Also, the tools need to improve. Currently, we provide a gradle script that generates an ant-project that allows your javafx application to be packaged into an .apk bundle, which can then be deployed on an Android device — or, in the end, uploaded to the Play store. Integration with leading IDE’s would be extremely helpful to developers.

At the same time, the main JavaFX development is no longer happening in the openjfx-8-graphics repository that we use as the upstream repository. A new repository is created, and this seems like a good moment to try to merge our changes back into the main repository. Clearly, there are a number of challenges we encounter, but I don’t think there is a real show-stopper. For example, we are investigating RetroLambda for allowing the use of Lambda code.

The JavaFX port for Android has been an interesting project so far, and I’m really excited to see videos and screenshots from people who got their applications working on Android. Keep them coming!