Right now I use the Eclipse with Scene Builder.
I've built the code using an MVC.
I want to change the Scene Builder but I can't understand if I need to change my controller.
I can't find anywhere the web if it's necessary to change the Controller if a technology is changed (in this case: Scene Builder).
No, you don't have to change anything. SceneBuilder just creates FXML files which you could also create by hand if you like to.
After searching the web and testing myself, I have found out that if you I change the technology, the controller is also has to be change. for example: Switching from Scene Builder to developing to mobile.
Sorry for such a simple question but I'm finding it hard to believe that I can't actually view the fxml whilst developing a user interface using JavaFX Scenebuilder.
I'd expect that I should be able to write a user interface using the controls as well as being able to directly write the fxml.
How do I view/edit the fxml of my user interface in SceneBuilder without doing the following: -
Saving
Editing with text editor
Re-open with JavaFX Scene Builder
i.e. http://www.webhostingplanguide.com/wp-content/uploads/2013/12/CoffeeCup-HTML-Editor.jpg
As above, I would like to be able to work on either the FXML or the WYSIWYG front end.
Well for now, there is no such option to view the FXML from the Scene Builder. I can confirm it for Scene Builder 2.0.
Though this can be a great addition to Scene Builder(If not the split screen, just viewing the FXML). You can file a feature request here https://github.com/gluonhq/scenebuilder/issues.
Use IntelliJ Community edition. It has a built in FXML editor that lets you switch between wysiwyg and code.
There actually is a way. Save your file and from the file explorer, open your .fxml file with an IDE, say VSCode
I am building a JavaFX application and I am wondering if there is a recommendation (best practice) on how to load new Scene in current Stage as fast as possible.
Currently what I am doing is (more or less) this:
Parent root = (Parent)myFXLoader.load();
currentStage.setScene(new Scene (root);
The above works fine and fast enough for simple Scenes BUT when loading more complicated scenes that initialize TableViews, Comboboxes etc the transition between Scenes takes many seconds which is annoying.
All the initialization I do in inside the Controller's initialize(URL url, ResourceBundle rb) method.
There I add the items to the Choice/Combo boxes, initialize TableView etc but as I said, it takes too much time.
Am i doing something wrong? Should I initialize somewhere else?
Thank you.
EDIT:
Anyone interested in helping with this, or even get ideas for their project, I have uploaded a part of my project (Netbeans project) at google.com.
You can check it out using SVN. This is the link:
http://tabularasafx.googlecode.com/svn/trunk/
userName: tabularasafx-read-only
no password required
Instructions after you run the project:
First screen is login screen, just click OK
Second screen is "homePage", there you can see a treeView menu and navigate to 4 different screens
My issue is the loading time of classes->create page. Take a look at it and let me know if you find anything
EDIT:
I made 3 changes that #jewelsea suggested.
1. I used a HashMap to keep all the controllers for each screen
2. I update only part of the Scene and not the whole Scene
3. I used the answer of JavaFX2 - very poor performance when adding custom made (fxml)panels to gridpane dynamically to help the controllers load faster as described in the answer.
Everything is much much faster now!!!!
Feel free to use the project as a guideline
Also I update the program to navigate through 3 screens for better understanding
note that my code is a messy
Some Background
I took a look at your project Dimitris.
I timed your load creation time (Java 8 b129 on OS X 10.9, 2012 Macbook Air) for the "classes create" page. It took just over a second for me.
To simplify testing I removed the section where you load new FXML using a concurrent service and just loaded the FXML directly on the JavaFX application thread when it was requested - its a lot easier to work with that way.
Sorry for the long answer here. Things like this usually don't fit well into StackOverflow, they end up best in a tutorial or blog kind of form, but I was curious what was going on, so I thought I'd take some time to look into it and write it up.
Don't create a new Scene for every FXML you load
You set a new scene (with a new size) every time you load the FXML. For whatever reason, this is a pretty expensive operation and you don't need to do it. You already have a scene in your stage, just reuse that. So replace the following code:
stage.setScene(new Scene(service.getValue().getRoot(), service.getValue().getX(), service.getValue().getY()));
with:
stage.getScene().setRoot(service.getValue().getRoot());
This will save just over half a second on the load time, so now classes->create takes about 400 milliseconds the first time it is run.
This change is an example of an easy performance win.
It also provides a nicer user experience as on my machine the stage flashed gray while you were changing scenes, but when you just replace the scene root of an existing scene, there was no gray flash.
Because the JVM runs with a just in time compiler for Java, subsequent requests to display classes->create go faster, so after opening the scene two or three times it takes about 250ms (or quarter of a second).
The FXMLLoader is slow
Of the remaining 250ms to load, about 2ms is spent in your initialization code, another 2ms is spent by JavaFX rendering the controls and the other 246ms are spent by the FXMLLoader loading up the FXML and instantiating the nodes to go into your scene.
The idea with UI code is you want to get the target time for a transition down to < 16 to 30ms. That will make the transition quick and smooth for the user.
Separate your UI code from your Network and Database Code
Network and database calls are things which are best done off of the JavaFX application thread, so you can use the JavaFX concurrency tools to wrap those tasks. But I'd recommend separating concerns. Use concurrent services to fetch data, but once you have the data back, use Platform.runLater or a Task return value to transfer the data the JavaFX application thread and run the population on the JavaFX application thread (because that population task is going to be pretty quick anyway).
This way you have compartmentalized the multithreading in the system to different logical components - networking runs on its own thread and UI operations run on a different thread. It makes stuff easier to reason about and design. Think of it a bit like web programming, where an ajax call fetches data concurrently to the UI, then provides a callback that is invoked to process the data into the UI.
The other reason to do this is that many networking libraries come with their own threading implementations anyway, so you just use that rather than spawning your own threads.
How to make FXML Load Quicker
You shouldn't really need multi-threaded code for loading FXML files. The initialize function of your FXML runs extremely quickly (just a couple of milliseconds). The FXMLLoader takes 250ms. I haven't profiled it in detail to see why that is the case. But there are some indications in Sebastian's answer to JavaFX2 - very poor performance when adding custom made (fxml)panels to gridpane dynamically. I think the main performance issue is that the FXMLLoader relies so heavily on reflection.
So the best solution in situations where a slow FXMLLoader is an issue would be to use some alternative to the FXMLLoader which performs better and doesn't rely on reflection. I believe the JavaFX team are working on a binary equivalent of the FXMLLoader (e.g. the FXML files are pre-parsed in the build stage into binary Java class files which can be quickly loaded into the JVM). But that work (if it exists) is not released by the JavaFX team yet. A similar piece of work has been done by Tom Schindl, which pre-compiles the FXML to Java source, which can then be compiled to Java classes, so again your app is just working with compiled classes, which should be nice and speedy.
So the solutions to make FXML load quicker are currently in the works, but not really stable and usable on a production system. So you need other ways to deal with this issue.
Make your forms simpler
This may seem like a cop-out on my part, but IMO the design you have for your "create classes" scene is a bit complicated. You might want to consider replacing it with a multi-stage wizard. Such a wizard will generally load faster as you only need to load a handful of items on each wizard screen. But the more important point is that such a wizard is probably easier to use and a better design for your users.
Replace only the sections of your scene that you need to
You are loading FXML files which create your whole application UI for each new page. But you don't need to do this because things like the top menu, status bar and navigation sidebar don't change just because the user loads a new form - only the central section where the "create classes" form is displayed is changing. So just load up the nodes for the part of the scene that is changing rather than the entire scene contents.
Additionally this will help fix other issues that you will have with your application by replacing the whole UI at each stage. When you replace the navigation menu, the menu doesn't automatically remember and highlight the currently selected item in the navigation tree - you have to go and explicitly remember it and reset it again after doing a navigation. But if you weren't replacing the whole scene contents, the navigation menu would remember what was last selected and display it (because the navigation menu itself isn't changing on navigation).
Cache FXML load node trees and controllers
You are only ever displaying a single "create classes" form at a time within the application. So you only need to use the FXMLLoader to load the "create classes" form once. That will create a tree of nodes for the form. Define a static HashMap that maps "create classes" to the CreateClassesController object (of which you also have only one in the application). When you navigate to the "create classes" screen, see if you have already been there before, by retrieving the controller from your hash map. If there is already an existing controller class, query it to get the root pane for form and display the form in your scene by replacing the center panel of your scene with the new form. You can add extra methods on the controller that you can call to clear any existing data values in the form or to set any data values which you have loaded from a network fetching task.
In addition to speeding up your application, you now have the advantage that the state of the "create classes" form is kept until you or the user decide to clear it. This means that the user can go through and partially fill out the form go somewhere else in the application then return to the form and it will be in the same state as they left it rather than forgetting everything the user entered before.
Now because you load the "create classes" form only once, you could load up all of the forms at startup (and have a preloader page which indicates that your application is initializing). This means that initial startup of the app will be slower, but operation of the app will be quick.
Suggested Design
Create forms for different panel sections in your app (nav bar, "create class" form, "home screen", etc).
Create and manipulate UI elements only on the JavaFX UI thread.
Only replace panel sections on navigation, not entire scenes.
Precompile FXML to class files.
Use a Splash Screen pre-loader if necessary.
Abstract networking and data fetching code into its own thread.
Reuse cached node trees created for panel forms rather than recreating them.
When new network data is available, transfer it to the UI thread and fill it into a cached node tree.
Review the SceneBuilder Implementation
Follow the principles used the SceneBuilder implementation itself - it is the best current design example for a reasonably sized JavaFX project that makes use of FXML for its UI. The SceneBuilder code is open source and distributed under a BSD style license, so its good to study.
Outcome
I prototyped some of the ideas mentioned in this answer and this cut the initial load time of the "create classes" screen down from over a second to about 400ms (for the first time the screen is loaded). I didn't replace the FXMLLoader with something else, (which I am sure would have greatly decreased the 400ms value). Subsequent loads of the "create classes" form based a cached node tree that was just re-added to the scene took about 4ms - so operational performance was instantaneous as far as the user was concerned.
Update for Additional Questions
Do you think that I should use Tom Schindl's solution for compiling FXML or is it "too Beta"?
My guess is that (as of today) it is "too Beta". But try it out for yourself and see if it meets your needs. For support on the Tom's FXML => JavaFX compiler, post to the e(fx)clipse forums, as the project falls under the larger umbrella of the e(fx)clipse project.
And I tried 'stage.getScene().setRoot(service.getValue().getRoot());' but got OutOfMemoryError: Java heap space do you think that line caused it or it is not relevant?
I was doing some profiling of your code as part of creating this answer (by attaching the NetBeans profiler to an already running instance of your application). I did notice that every time the "create class" scene was loaded by your program, the memory usage would grow quite significantly and the memory did not seem to be released. I didn't spend time trying to track down what the reason for that was, but that was profiling your code unmodified. So I suspect that the ultimate cause of the system running out of memory is not to do with whether you swap out a scene or just swap out a scene root. I noticed a lot of memory was consumed by CSS psuedo-classes, though I couldn't tell you the reason for that. My guess is that if you follow the principles outlined in this answer, then overall, your application will be a lot more efficient and you may circumvent the memory related issues present in your current code. If not, you could continue to profile the application memory usage to see what the root issues are.
the speed of the scenes are going to have a lot to do with how many object you are trying to initialize in the scene right from the beginning. So if you can lower that number to the minimum and create the rest while the scene is running everything will run a lot smoother. If that is impossible in your situation maybe just try limiting other things to reduce the strain on the system.
If you are using scene builder, then run it as administrator externally (not from the ide side).
Problem will be solved.
Hello everyone i am quite new to JavaFx and is currently creating my programs with JavaFx Scene builder. i have never been a pro at creating GUI's and therefore the JavaFx Scene builder allows me to optimize the visual effects!
Ive been given an assignment at work to create an applet for one of our companies websites, the content of the applet should be a graph that will show some detailed information.
Since i enjoy JavaFx and and i find the graphs that you can create in JavaFx and manipulate in CSS quite awesome i wanted to use JavaFx to create my applet.
My Question is however am i able to use JavaFx scene builder to create my applet aswell or am i forced to write to code from scrats?
Also on a side note does anyone know any tutorials on how to apply JavaFx to an Applet ive been looking for some on Google but i only found some pretty advanced guides?
EDIT
I did find a tutorial on Applets for JavaFx however it did not state anything about JavaFx Scene builder
Link: JavaFx Applet tutorial
Yes, you can use JavaFX scene builder with applets, I work as a website administrator for an educational project that require applets to plot graphs, communicate with hardware and look nice and stay secure and hard to download; that is why we are using JavaFX for most of our applets.
Even though I am not involved in the applet making process but I know for a fact that we use JavaFX scene builder to create the graphical user interface.
Also the main reason for creating JavaFX and JavaFX scene builder was for creating applets, because this is what Oracle intended from the sart.
NetBeans for JavaFX I tried, but its really not stable, lot of things getting often changed and also it does not shift with NetBeans nightly builds. Also I am afraid will JavaFX remain or it will be deprecated by Oracle.
So, I was thinking if there is something else which has more advanced way of doing JavaFX UI designing, as an alternative tools of NetBeans for JavaFX.
Question: Is there any good JavaFX gui builders which generates readable code, with less mess?
Thanks in advance.
ex: http://www.reportmill.com/jfx/
You can try JavaFX Scene Builder to create visualy your FXML files. FXML files are the "UI" of your application! JavaFX Scene Builder is only for JavaFX 2.0!
Here is the documentation: http://docs.oracle.com/javafx/scenebuilder/1/user_guide/jsbpub-user_guide.htm