We’re running a little survey here at FX Experience to get input from JavaFX developers (and everybody else!) as to the ways they would use a port of JavaFX to smartphones and tablets (think: iOS, Android, and WinRT). This is your chance to really influence the future of JavaFX! Get your friends to participate!
[feedback id=”1″]
Thanks for the communication and listening to us!!! Javafx is an awesome technology and far superior to html5 in every way that matters to us.
JavaFx is the future of RIA
Without JavaFX on mobile devices the use case is very limited. Classic Desktop applications will only stay for some business cases, maybe not in the next 2-3 years but sooner or later. JavaFX on mobile will allow us to develop applications for current Desktop env. and to reuse this code for mobile applications. Also the runntime is a major plus. You are not depending on some browser implementations on Device A or B. Oracle has full control to deliver an optimized environment for all devices to ensure the quality of delivered applications is the same on all deployments.
When JavaFX will run on mobile it will become our platform of choice.
Using Groovy via GroovyFX (http://groovyfx.org/) rather than Java makes writing applications a lot easier.
This doesn’t seem particularly relevant to the survey being discussed here. We’re wanting to know if people want JavaFX on embedded devices – not what language they want to write JavaFX applications in.
I was already in the mindset of “yes it would be good”. Having JavaFX as part of the Android platform would be a great addtion, and having it on iOS would imply being able to use Java instead of ObjectiveC for applications going through the Apple stores.
I hope threre will be a Main stream for javaFx development
I’m interested in providing customers with the best possible experience on the device they use and there are many factors, not least of which is following the platform style and feel as best as possible.
Android is heavily fragmented in this area so JavaFX would be no better or worse in my opinion, but I think it’s unlikely that a JavaFX on iOS devices will work well. It’s things like responsiveness and elasticity that really stand out when it’s wrong.
I really don’t want a phone app that feels like a tablet app that feels like a desktop app. There are plenty of examples of how this is a bad user experience.
I think JavaFX has a future on the desktop (and will probably save Java on the desktop) but that’s about it.
The good thing is that, if you don’t like it, you don’t have to use it. Other developers may like it and decide by themselves to use it.
I don’t see why an app written in JavaFX has to be unresponsive or in any way different from an Objective-C native app. When we say that JavaFX needs to run on mobiles and tablets, it is a given that it runs on those platforms in a sufficiently performant manner, otherwise what’s the point?
I am sure Oracle will not embark on developing support for those platforms if they are not absolutely sure that the results will be worth the investment. It is true that something like a traditional Swing application tends not to feel or behave in a manner completely consistent with a native application on Windows for example but this is a different situation. For JavaFX to run on mobiles and tablets, AOT compilation will be required meaning that you effectively have a native app anyway. There’s nothing to prevent the JavaFX AOT compiled app from looking, feeling and behaving like every other native app on the respective platforms.
Also Adrian, I think you wrong to say that JavaFX has a future on the desktop even if it doesn’t run on those other more modern platforms because existing on the desktop alone is not going to be enough to keep the product alive when in just a few years almost no one will be running software on the desktop.
I’d really like to see JavaFX on at least a couple mobile platforms. I think migrating from Swing to JavaFX for desktop apps will be a relatively easy transition for most Java developers and having a couple mobile targets for JavaFX creates a lot of incentive to start that transition.
If HTML5 is left as the only option, I’d consider sticking with Swing on the desktop and moving to Bootstrap or something as an option for mobile. I won’t even evaluate something like ADF because there are so many HTML5 platforms that I know I can find something technologically competitive, but with better licensing terms and support options that are more accessible to independent developers like me.
That said, even if JavaFX were only usable with Android, it would be far and away the best option for me.
Even though the user experience differs between desktop and mobile it is still a huge advantage if you can reuse parts of your UI. There a plenty of use cases for JavaFX on mobile devices.
From my perspective mobile os support is a key feature. When I started to evaluate JavaFX I did this in the hope that some day it will be possible to use JavaFX on mobile platforms as well. Isn’t this what Java is all about?
It is incredibly hard to implement an application for different platforms! I wrote applications for Desktop, iOS and Android. The need to update the application separately for each platform made it impossible for me to support all of them. I know that even if JavaFX would run on all platforms not all problems would be automatically solved. But it would help a lot! I use Java for exactly that reason.
Does it make sense to support desktop and embedded devices without adding support for one of the fastest growing markets? NO! Support for mobile platforms is obligatory!
Thanks for listening to us!
Your quantity question is not ambitious enough. I am planning a fx application for 100K + installations
I need to decide on a new framework to migrate the user interface of a large client server application currently using spring-rich-client.
Killer feature would be seamless rich-client and thin-client (mobile) programming.
I am keeping a close watch on JavaFX2 and have great expectations on its evolution.
A requirement is good integration with the springframework / hibernate stack.
I am currently starting some testing and always glad to contribute
As I see it, you need to adjust your user interfaces for each targeted device depending on factors such as:
– screen size (you can show more information on a 17” display than on a 4” display)
– input device (controls need to be bigger for touch devices than for devices controlled by a mouse and keyboard)
Apart from desktops (big displays, mouse and keyboard), possible devices are:
– smartphones (small display, touch screen)
– tablets (medium size display, touch screen)
– smart TVs (big display, limited input devices)
– navigation devices (similar to smartphones, possible other hardware components)
– smart landline phones (similar to smartphones, possible other hardware components)
– [add new devices here which will emerge in the coming years]
Currently, you need to multiply the number of targeted devices with the number of targeted patforms. E.g. even if you want to deploy your application only to smartphones and tablets for iOS, Android and Windows RT you will have to develop 2*3=6 applications, using 3 completly different technologies, skill sets and thus different developers. (And no, I don’t want to write complex logic in JavaScript.)
And it gets worse the more different devices and platforms you target.
Which companies apart from the really big ones, can affort to build functionally equivalent apps with about the same quality for all these different devices and platforms? Especially the more complex ones?
JavaFX can come to the rescue here. Although it cannot reduce the number of different devices, it can reduce the number of platforms from at least 3 (iOS, Android, Windows RT) to one (JavaFX).
Not only have you then reduced the numbers of applications to build by a factor 3 (here: from 6 apps to only 2), but you also need only one crew of developers (JavaFX developers).
I absolutely agree. Plus the network stack gets exponentially more complicated. Just imagine being able to dump the entire web stack in favor of something like Netty.
We still have to build a different interface (or portion of the interface) for each device, but, if you’re using JavaFX on the desktop anyway, that goal becomes a lot more attainable, especially compared to the nightmare scope creep described above.
The scenario Florian just explained is the exact reason I haven’t been able to do any mobile development yet. It’s not that I don’t want to. It just seems like an insurmountable task that requires a ton of investment and risk just to test the waters. With JavaFX I could ease into the mobile side of things as it makes sense for me to do so.
JavaFX can only survive if oracle port it to mobile space. We JavaFX on mobile devices
I believe it would be THE breakthrough for JavaFX if it was a platform for desktop, tablet and mobile devices.
JavaFX main competitor is HTML/Javascript, which at least promises to cover “all devices”. We all know that this is not really true (compatibility issues, …), but at least the promise has reached and attracted people (and decision makers… ).
It would be so useful to have a consistent UI architecture via JavaFX cross all these devices. There are enough Java (and other) developers who would much much much prefer such architecture – instead of going the HTML/JavaScript way.
In 2012 JavaFX has become cross-desktop to offer same features as Swing.
The JavaFX 2013’s target should be the compatibility with iOS, Android and W8 to leverage oldest API.
When we will be able to write once and deploy everywhere JavaFX will take the lead of the market.
Most of swing applications need better performances and new user interactions (multitouch and gesture), but also require to be mobile and lightweight to prepare the future. JavaFX can address these requirements.
In JavaFX Mobile I Trust
Go JFX Team
As long as mobile JavaFX provides native look and feels on each platform, and memory consumption, CPU overhead and loading time don’t become an issue, then we might have a winner.
I don’t know what’s the status of alternative JVM languages support in JavaFX, but in my opinion that’s also very important to help boost adoption.
I’ve been pitching several clients on the idea of WORA for mobile with modern graphics – and they love the idea! For them to commit to JavaFX, however, they at least need to hear Oracle commit to mobile. It’s painfully obvious (and also just painful :-).
Replied to the survey but stuck at “Processing you request”. Not sure if my results were posted. Happy to resubmit and feel very strongly about the use of JavaFX on tablets. Absolute must!
JavaFX Runtime on Android would be realy nice!
We have found Android development to be very tedious and expensive. Our first attempt had to be almost completely rewritten because of the complexities of coordinating the Android activity lifecycle with background tasks.
Please what happened to JavaFXmobile. http://en.wikipedia.org/wiki/JavaFX_Mobile
A project like this once existed couple of years ago before Oracle acquired Sun. What was Sun thinking when they came up with this idea of JavaFX Mobile. I think Simplicity and Performance is the key reason any end user tool will thrive.
we need javafx on tablets and mobile it will be a game changer for javafx
He: “Oh JavaFX, that’s this weird looking scripting language which runs on mobile devices, right?”
Me: “That was JavaFX 1. They dropped it and replaced it with Java, now”
He: “Oh great! So it still runs on mobile?”
Me: “Nope, they dropped that, too”
He: “Oh….”
I would love to be able to say something different.
C++ with Qt5/Qml flavor seems to have the same target as the possible future with JavaFX in mobile space. Both try to create common ground for sharing code between apps developed for multiple mobile platforms. With Qt5/Qml this is done with the combination of Javascript and C++ with the HTML5 option.
If thinking solely the performance, C++ with Qt/Qml is a strong contender. Also the libraries of Qt/Qml seem to cover wide area of use cases.
That’s a valid opinion.
Without the intent of starting a my-programming-stack-is-better than yours argument, the JVM has languages like Scala than can dramatically increase productivity and reduce development costs.
While a seasoned C++ programmer can get nearly-optimal performance with one processor architectures, Scala is more suitable for taking advantage of multiple processors (with its actor model, and libraries like Akka, which is also available for Java). The way things are evolving (dual core in mobile devices is commonplace are we are going fore more) an average program written by an average JVM programmer will soon outperform the average C++ program written by the average C++ programmer.
Also, JVM languages, with implicit garbage collection, make the task of writing memory-leak free programs much easier.
I am not saying C++ with Qt/Qml is bad. Just that JVM + JavaFX has the potential to badly kick ass (any other development stack’s ass). I think its strongest advantages of JVM + JavaFX are:
– The richest collection of libraries of any platform
– Same technology at client and server
– Scalable
– Rich choice of development languages (Java, Scala, Jython, Groovy, etc…)
All of these amount to quicker development times with higher quality and lower costs.
Oracle could easily sort out this issue if they provided a native code compiler for Java, but alas they seem to be busy with other stuff.
If one bets on HTML5, Javascript stays in the centre of table. After little bit of extending and polishing, it can be used as such and not just something to compile into. C++ with Qt/Qml increases the reach of Javascript even further making the need for other languages quite obsolete. This holds true even in the case where both UI and server side development are in the center of argument.
With Qt 5 and Qml the amount of lines of code needed for average programs has dropped dramatically and the development experience even for graphical web designers has been made into a whole new ball game. More info about multi-processor support in Qt can be found over here –> http://qt-project.org/doc/qt-4.8/threads.html
JavaFX is all right when needing to extend Java-skills or when continuing to protect the investments to Java in some corporate setting.
What remains to be answered is, should it be used in new projects. I don’t think so.
As you say “after a little bit of extending and polishing….making the need for other languages quite obsolete.” A very similar argument can be made for JavaFX “after a little bit of porting and polishing, Java developers would be able to – using a single language – write applications for Desktop, Server, and every form of mobile or tablet device available.”
Considering that the number of developers with existing Java skills are second only to those with C skills (according to tiobe), that could very well make the need for other languages quite obsolete.
But alas… variety is the spice of life.
Finally, if anyone is considering a new project the first thing they would do is to utilize their existing skills set. If that skill happens to be java, you can be rest assured that it would be used in new projects.
JavaScript is slow and tends to stay in the confines of a web browser.
Just create an open-source java OS for hand held device and see how it’s gonna take-off. I think it would be an advantageous unique feature Oracle would have whereby substantial industry support would trickle in automatically.
JavaFX is needed on mobile devices.
As mobile CPUs have become more powerful, they allow programs to run that previously were confined to desktop computers. Software of almost any kind can be expected to be available on mobile devices, including dedicated business, technical, and scientific applications that are deployed in smaller numbers, albeit with high value per unit.
JavaFX is very advantageous for the latter category because of WORA, relatively quick development, and use of Java programming skills, which are important advantages for products where development time, quality, usability, and maintainability are a primary concerns. However, JavaFX needs to be available on mobile devices, as these constitute an increasing fraction of where software is supposed to live.
I would like to start a little discussion here:
What is the actual purpose developing apps for mobile with JavaFX if one can take advantage of the native platform?
iOS and Android have both own platforms/frameworks natively optimized for their needs: ready to use predefined animations, h/w-acceleration, IU widgets, h/w access, etc.
What will make JavaFX so different on mobile?
(No offence here, just want to hear your opinion)
The answer is quite simple, one language – Java.
It is said that the jack of all trades is the master of none. For most business efforts targeting mobile platforms, it quickly becomes clear that targeting only one platform would not be viable. You would need to target as many as possible. Consequently, you need a dev. team for iOS, another dev. team for Android another dev. team for Blackberry, and so forth.
Given this scenario, even the simplest theme change for the app can become a very expensive and complex process to manage!
You can achieve native looks by skinning your components (there are some already available).
You many need to interact with the device’s sensors, camera reel, contact list, calendar, native notifications, etc. You will be able to do this with the JNI bridge. Since these are quite common needs, someone will likely write a library specific to your mobile OS that you will be able to reuse.
This model works: Adobe Air does it that way, for example. Google Air Native Extension, and you will find quite a few.
For me, the simple fact that java is not on android -the big winner over windows- makes java a problematic choice.
The fact that only html5 is compatible with both :
– computer ( wintel, Mac) and
– Mobil (android, ios)
… makes this plateform the (the only) choice on standard gui.
The fact that android is SO VERY cloth to our java desktop programming makes me rage. I know all is about big money, but still…
Thanks for reaching out. JavaFX just feels altogether more approachable than Java as an open source project.
But is it just on Oracle’s hands ? What is Apple’s and Google’ position on this ?
Write Once – Run Anyware
Lol! Tamim Ziai, nice one!
I have given up on Java for the desktop and nowadays just use Qt/C++.
As someone who developed a complex realtime financial markets application with a JavaFX client earlier this year and then later had to create a separate HTML5/JQuery browser client with the same functionality, it seems to me that the best short-term approach that Oracle could take would be to produce an HTML5/js compiler for JavaFX, along the lines of Google’s dart2js. SceneBuilder already generates FXML representations of the UI structure that would be trivial to convert to HTML. Conversion of JavaFX controller logic to js/JQuery, while not as straightforward, should still be very doable in a reasonably short timeframe.
Such a compiler would enable developers to write both server and client side code in a single, clean, strongly-typed language and then deploy the client as a standalone desktop app and/or a web app (that could run in both mobile and destop browsers). If/when AOT compilers for native mobile platforms subsequently become available the same code base could be deployed to those platforms as well (true WORA!), but in the meantime a JavaFX web compiler could serve as a bridge that would provide a compelling reason for adoption of JavaFX by those developers targeting mobile/browser users. It certainly would have made this past year much easier for me!
ok
Thanks Jasper,
I did fill out the questionnaire. This is the questions I think should be asked:
If you as a developer had a choice between programming for the and you could do this using a cross-platform language, would you nonetheless prefer to use Objective C?
Then ask a similar question for Android.
Would not the answer to that mean something to the marketing suits? Wouldn’t the answer scream: MARKET OPPORTUNITY!!! Is not the whole premise of Java from very beginning this: program once, run everywhere? Is not this still one of the great value propositions? How can it be that we have to reeducate the suits about this? How can it be that the marketing and product managers do not — at the deep subconscious level — know the intrinsic value of this without a poll to tell them?
You need to show them the money …
Seriously, we are well aware of the benefits from the developer’s side. But what is in this for Apple ?
JavaFX absolutely needs to be on mobile platforms. I was hugely disappointed with JavaOne this year when there was no announcement regarding JavaFX on Android or iOS given that the direction is so obvious and given that it was generally alluded to the previous year. I actually stopped all work with JavaFX after JavaOne and am now working directly with Java on Android. I also will not go back to JavaFX unless something happens in the mobile space. I should note that I think highly of JavaFX from a technical perspective and think that the development team has been doing a fantastic job but I am afraid all of this is quite meaningless in the long term unless JavaFX runs on modern mobile platforms.
Talking about the Javascript/C++ combination. The following link to a video presentation at Google Developers Live tells you, how you can write your Chrome App with 90% Javascript and 10% C++. In the video you’ll see C++ Bullet-library used in a Chrome App. https://www.youtube.com/watch?feature=player_embedded&v=JcQdl8x0tws
Why not create Chrome Apps instead of JavaFX apps? Personally I’m waiting a lot from Dart VM. In recent tests it already outperforms V8 by 50% –> http://news.dartlang.org/2012/12/dart-vm-improves-performance-by-50.html
It’s true that there are little bug in javafx. But I love develop in javafx.. So It will be a great news if it become available for mobile
Although research is needed on this topic?
99.8% will certainly agree with javafx mobile.
My question is when will it be available?
Excuse my ignorance on this, but why can’t java do the same thing the unity game engine does, where you write it in one language (in java’s case, that is java) and for ios deployment it is compiled into an objective-c program which then you compile with Xcode.
To be successful JavaFX for mobile must perform very well on all devices – comparable to native apps. Another major issue is that JavaFX has to support device specific components such as GPS, Accelerometer… – I think a simple port without supporting device subcomponents isn’t enough and developers will strongly demand such support as soon as JavaFX becomes available for mobiles and tablets. Also support for input gestures could be an issue.
It would be great to have JavaFX available for all major Mobile platforms. At the moment we use Sencha to build reach User Interfaces.
For internal enterprise apps I need to be able to do the most I can with limited resources – I’m looking for WORA over space and time – ie my app not just work on different platforms with the minimum of effort ( with different screen sizes and touch v mouse there is always going to be some effort ), but work over time without endless porting from one version of an OS to another.
Currently we have a large java server code base and a significant number of Swing clients. Clearly Swing, while there isn’t a rush to move, isn’t the future and we are considering our options:
– the web gives us the biggest reach – but the development environment and deployment platform is far from ideal
– JavaFX would allow the simplest transition but we worry that:
– the wide platform support isn’t there
– the wide vendor support… isn’t there.
Oracle need to increase the platform support – IOS and Android etc
and they also need to build that multi-vendor community again.
If it’s just Oracle I will always be nervous.
Another interesting statement from “TIOBE Programming Community Index for December 2012”:
“[…]Other mobile phone application languages such as C, C++ and Java are rising too but not fast enough to compete seriously with Objective-C. In fact it seems that if you are not in the mobile phone market you are losing ground.[…]”
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
It would be super interesting you can make your application in modules and power modules to provide some of the mobile device.
In my case I’m making an application to control the museum ultilizando RFID, the module parts identification could be made available via mobile app for visitors to interact with the acquis would be too …
You can be sure that if the JavaFX run on mobile devices, it will take another big leap
Accompany the javafx since version 1.3 and is iincrivel see how much it ta growing community and staff and dp javafx contribute to its growth …
I’ll be happy to help in any power for that platform to work
Congratulations for the work
Currently I’m planning to start project for tablets and desktop systems. I’m considering html5 but I HOPE that the JavaFX will be available for tablets either. I wrote sample application in JavaFX and it looks impresive. So, I will track the discussion about future of the JavaFX.
Hurry up!
Java and Java FX are running late. Once a few apps are developed in another existing solid (?) technology (HTML5), it will be hard to go back to JavaFX
Of course we would like to see (and invest on) JavaFX on mobile: to use a mature advanced OO language with free/open-source toolset! We don’t want to go to stone age again with javascript… Nor do we all want to be locked to hardware from one vendor just to develop iOS apps.
So… Hurry up!
Please provide a follow up article which provides the survey results, analyzes them and discusses their impact on the JavaFX project.
javafx on mobile is a complete no-brainer, particularly with the performance level of current hardware – it makes Android look positively archaic (and very poorly designed). And HTML5 is just a cruel joke to anyone who has ever programmed in anything else. Qt is really it’s only competitor, but that has a very big drawback: c++.
The problem for Oracle is they want to make money from it – but there is too much free stuff around to compete with it, and no matter how much better it might be it wouldn’t be better enough to make enough money to cover the administration costs of charging for it. And it would remain a tiny niche platform.
So it has to be free – cost wise and license wise – in order to become ubiquitous. And then maybe the big O can make money selling tooling to the big end of town.