The JavaOne has ended and it was both under- and overwhelming. But on a more personal note I was not satisfied with how my talk went. Being an occasional speaker, I naturally am a bit nervous at the beginning, but somewhere along the line that usually goes away. This means I get into ‘the zone’, and feel inspired by the subject I am talking about.
However, this was not the case during my talk at the JavaOne; it kept dragging a bit, never gaining the momentum I’m used to. And I have been wondering about the reason; I’ve done the talk more often, so it is not that I don’t know what to tell on a given slide. It just didn’t… Take off.
So different from yesterday, when I was in Utrecht, giving a talk about automated testing. The setting there was… Cozy. Informal. I wasn’t even really nervous at the beginning, even though it was the first time I did the lecture, and I wasn’t sure if I had enough slides, or too many. Certainly the deck was way less pruned and polished than the JavaOne’s, but it took mere seconds to get into the groove.
So apparently I’m more sensitive to the setting than thought I was. The JavaOne conference rooms were not inspiring (read the previous post), and the speaker had to stand on a small stage, behind a small desk, above the people in the room. Totally disconnected. And people were constantly on their phones (no blame, I did it as well as an attendee).
I’m not comfortable up there. Put me in a room with inconvenient pillars and brightly colored chairs, and off I go. Exactly the reason why I chose the Edwardian Hotel in San Fransisco, instead of one of the larger downtown ones.
So this is my first visit ever to the JavaOne. I’ve been to many national conferences, but never to a yearly, world wide appealing one. And I’m both amazed and disappointed.
Amazed because of the conference size; integrated with the Oracle World, the conference hands out a paper with the sessions for easy reference. But instead of one for the whole conference, you get one for each day. And it is full. 6 large news paper size page full of almost micro sized printed sessions. You almost start to wonder if every visitor is a speaker. Doing ‘just’ one talk makes you feel insignificant.
Amazed because of the venue size; blocking off a street, people sitting and coding everywhere, distributed over 4 large buildings. Security everywhere. Police guiding traffic. JavaOne occupies only the second floor of Moscone West building, with over 20 conference rooms. Large hallways, several floors high, a HUGE podium for the keynotes, full with displays where just one of them won’t fit in my house. Impressive. Humiliating.
And with all that wealth and grandeur emanating from these settings, the real knowledge is transferred in diarrhea brown conference rooms, with weird blackish tarps behind the speaker and a cold down draft. One wonders if only the outer hull, where the camera’s are, is shiny. Plus you realize that ‘my’ national conference isn’t doing so bad at all; at least every part of the venue has gotten the same level attention. (And I really do not mind a bit of grandeur and bling bling, puts fun in things.)
For those who have been following my blogs, or heard my ‘One application to rule them all’ talk, know that I’ve been hanging a lot of my spare time experiments on my hour registration applet. It has served me well for over a decade, but the fact that browsers no longer support applets forced me to make decisions on how to maintain that functionality.
The simplest approach would have been to convert the applet into a stand alone application. Not that big of a hassle; login screen, connect to the HTTP back end, and off you go. But I decided to try and write a JavaFX application instead, with a login screen connecting to that back end, which is able to run on multiple platforms. Just for the sake of experience.
Continue reading “Full circle – the applet is here to stay?”
The hour registration application is working nicely, on windows, on android, on OSX, but there is always room for improvement. One of the most obvious issues is that the original applet is a lot quicker when retrieving data from the server. I suspect this has to do with the fact that the applet maintains a web session and that the JavaFX app does an authentication on each request. And yes, of course I could (and probably will) improve that, but it also is an opportunity to try out something else; asynchronous communication. Now, I could pull open a can of threads and try to do this myself, but there have been wheels invented for this. So in this post I’m going to try Java 8’s CompleteableFuture, RxJava and JDeferred.
The app’s communication is very suited to try something like this, because there are 6 separate calls being made to the backend, and some of those calls are depending on each other. The calls are:
1. The hours for a given date.
2. Totals per project for the current week.
3. Totals per day for the current week.
4. All projects.
5. The favorite projects for the current user.
Continue reading “The art of waiting”
The common thread running through my hobby software activities lately, is the porting of my hour registration applet to a JavaFX desktop, mobile and web version. Yesterday I picked up work on the favorites; those projects who are currently most used.
In the original applet the favorites (as seen on the right in the image above) are implemented as a list and share the same screen space as the full tree of projects. Switching between either is done using an accordion; a layout similar to a tabbed pane, showing a header and per header a content. The content of one tab is shown at a time, and switching is done by clicking on the tab header. The main difference is that the headers are intermixed with the content, and move up or down when other content is revealed. Not unlike an accordion has ridges that move apart to show the space in between. I wanted to have the same visualisation in the JavaFX version, I could have settled on a tabbed pane, but what is the fun in that?
Now, JavaFX 8 already has an accordion control, but it behaves differently from what I want. In my usage there is only one tab visible, while the default accordion can (un)fold multiple tabs, and even have them all closed. It’s a minor UI/UX difference, but not what I want, so I decided to write it my version.
Continue reading “Is it a screen or control?”
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”
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”