In the previous posts I have blogged a lot about the ‘one code base’ application that runs on all popular platforms, from desktops like PC and OSX, mobile like Android and iOS, and finally on web with the use of JPro’s brilliant library. The core of that application was the fact that depending on the available screen size, or better: scene size, a different layout was automatically selected. Below on the left the MigPane based layout for desktop, on the right the same controls put into a TabbedPane for mobile.
Beside changing the actual layout, also a different stylesheet was automatically loaded, so (for example) the arrows in the data picker became more touch friendly. This worked perfectly, even dynamically adapting as you resized the application while running on the desktop or in a web browser. However, the code for doing this adaptive layout was intermixed in the application, and I decided to extract it into a layout manager called ResponsivePane. Continue reading “ResponsivePane”
One of my favorite moments every year is the NLJUG Java conference “JFall”. It is a day where you get to immerse yourself into all the latest trends, form an opinion if it is worth additional attention, and you get to catch up with a lot of the people you’ve encountered online or have worked with during the (by now many) working years.
But this year’s JFall had one big difference; I got to speak myself. The submission I made last year was not accepted, but the talk I made about my “epic journey” to run a single code base on desktop, mobile and web apparently was interesting enough. And even though the 1024×768 resolution through VGA was not what I had prepared for, I thought the talk went pretty well. Who would have ever thought that the shy kid from back then loves speaking in public? Anyhow, I’ll be doing the talk a few more times, but I figured I put the slides online anyhow.
One application to rule them all.pdf
Writing a calendar control is great fun; figuring out the algorithm of how to render multiple appointments on the same time, evolving the API, … The ‘I always wanted to do that’ is what makes a hobby project interesting. Of course the control is no where near as refined as the commercial alternative(s), and it most definitely could use a number of additional skins, but it looks pretty decent and -most importantly- works. 🙂
From an architectural point of view the Agenda control has one clear goal: render appointments. Nothing more, nothing less. The API expects a list of appointments to be rendered, given the time frame that the Agenda control’s currently active skin is displaying. It does not care where the appointments came from, if they are unique, pink, blue, or repeating. It just wants to know the raw meta data, so it can draw the appropriate areas and assign CSS to them.
But that is a fairly primary functionality for an Agenda, suited for programmers who own the domain entities and the application Agenda is embedded in. End users may expect some additional functionality, like notifications, or repeating appointments. And the latter is what David Bal is trying to add. Continue reading “Repeating appointments”
Things work, they look pretty good, so it is time to start polishing. First we focus on those hard coded values for host, user and password that are so convenient for testing. The thing that is needed here is a kind of cookie, something stored locally on the device, that holds the last typed host and user. But the file system on Android and iOS are very different, so that would be quite a challenge to set up. But again Gluon already solved this problem: from the PlatformFactory you can get an instance of Platform, which again provides an implementation of the SettingService, and that is a platform specific key-value store. Perfect! Just store the values after a successful login, and retrieve when starting. That was an easy score. And the Platform class holds many more gems, like the PositionService, which most likely will come handy in another app. Continue reading “Multiplatform JavaFX for real – polish”
After having established the communication with the backend, and the functional part of the UI on both PC and Android, the next step is to make it look a bit better by attempting to apply Google’s Material Design. Basically that would mean that I needed to start doing a lot of CSS and emulate the different UI aspects. FlatterFX could be a good starting point… Maybe use JFoenix controls… But after reexamining Gluon, it turned out that they already have done exactly what I was about to create from scratch; menubars, actionbars, views, layers, popup views, and all styled in Material Design… Well. Ahm. Ok. That settles it then.
Refactoring to Gluon’s view based approach was not that difficult; a View extends BorderPane, so you can add your own controls as the center node. The first result was quite pleasing.
Continue reading “Multiplatform JavaFX for real – material design”
The development is progressing nicely. Because I do not like to reinvent the wheel, I decided to try as many of the available libraries as possible. The thing that struck me most was that a lot of the libraries aren’t using retrolambda, even though they can without any problems (because streams are not used that often), and that many are really suited for running on tablets and smartphones. And I blame myself as well, because MigPane (the port of MigLayout for JavaFX I started) was not using it either. But that I could easily fix: as of the 5.1-SNAPSHOT MigPane runs on Android, and quite well I may add. (I know people have been asking for this.)
One of the first libraries I tested was FlatterFX by GuiGarage.com. A styling intended for touch devices, but not compiled with retrolambda. Is that strange? But also easily fixed, and the local snapshot build quickly integrated into the application.
Continue reading “Multiplatform JavaFX for real – basic layout”
I’ve already blogged about running JavaFX on Android and discovered that my first generation Nexus 7 is quite able to run such an application, including an animated gauge. So it is time to step up the ante and go for a fully working application.
Yes, applets / Swing applications can look pretty decent as well. And I think it hasn’t lost much of its looks in these 10 years, it even has some animation going on. The backend also had a web application for administrative functions, but I now just SQL the stuff straight into the database, I don’t need all the fancy logic that was in the web application.
Recent developments in browsers means that I can only start the applet in IE at the moment, and Oracle will discontinue the plugin completely. So that means I either convert the applet into webstart application, or write a JavaFX version, that just happens to also run on Android and other mobile hardware.
There isn’t much challenge in the first option, is there? So the choice was easy. Continue reading “Multiplatform JavaFX for real – Hessian”
On the morning of the JFall I find myself pondering about Java, chatting to the people in the community does that. And I find myself wording to my fellow Javagians the feelings I have been getting lately. Pure from a technical standpoint Oracle’s stewarding of Java has been good. They have picked up the language and platform, pushed it into a new gear; lambda’s were added, JavaFX is maturing nicely, and Jigsaw is on track. One cannot possibly complain about what has been happening to the product Java.So why am I worried?
Continue reading “I am worried”
JFXtras is my pet open source project. I like visual things, and HTML and CSS are way too frustrating, so I’m running with JavaFX. Since 2012 I’ve been submitting controls to it, simple ones at first; the ListSpinner, then the CalendarPicker (date picker), and eventually Agenda (Google Calendar) and gauges. Doing this has resulted in many satisfying moments when a control worked, but the road to that point was littered with many chunks of frustration and sometimes even scrapping whole controls and restarting on them (Agenda has three iterations).
Writing these controls in JavaFX 2 and later has teached a lot of lessons; things that work, things that didn’t work, or worked better than others, and in the end resulted in a few best practices. It’s not like I have all the wisdom on JavaFX or anything, but being on this for so long, well, at least some commonalities were found. So during Christmas holiday 2014 some of this knowledge was wrapped up in a small 1 – 1.5 hour presentation / talk, touching on some of JavaFX’s strong points, slip ups and other topics like code structure and testing JavaFX applications. It’s titled: “Lessons learned developing in JavaFX”, or “Let us make your mistakes for you”. Continue reading “JFXtras: lessons learned developing in JavaFX”
The previous post contains a detailed log of my adventure in getting a JavaFX application running on Android. It highlights the initial hurdles, the amazement how easy it was once those hurdles were taken, and comes with the conclusion that I need a new hardware.
Turns out I do not need a new hardware. Continue reading “JFXMobile – first attempt follow up”