A new entry in the “Real World Applications” series. This time it is SkedPal, an application for managing a busy person’s life intelligently. I have been consulting the SkedPal team in matters related to JavaFX and also when they made the decision to start using the CalendarFX framework for their calendar requirements. Below you can see a couple of screenshots of this attractive application. If you want to try it out yourself then you can simply register on the SkedPal website and download the desktop client (they also have mobile clients).
I have asked Saied ArBabian, the found of SkedPal to answer a couple of questions related to their product, their development, and (of course) their use of and thoughts about JavaFX.
What is the name of your product / project?
Who are your users / customers?
SkedPal is a publicly downloadable application made for busy professionals who need to schedule their work in order to better manage their time.
What is the purpose of your software? What are its benefits?
SkedPal’s key objective is to assist busy professionals to deliver their projects on time by scheduling all their work intelligently. It’s a SOA cloud-based application that includes a Narrow Artificial Intelligence scheduling engine in the cloud with a JavaFX client for the desktop and an iOS companion app.
Is the application operational? If yes, since when. If not when do you plan to go live?
We’re in public Beta since 2014. We’re into our 3rd pivot and getting closer to the sweet spot for our users.
How did you get the necessary JavaFX Know-How into your team? (Consultants, Internal / External training courses)?
The team was familiar with Swing and it didn’t take too long to get on board with JavaFX in order to deliver the first version. The training process was internal.
With which version of JavaFX did you start? 1, 2, 8?
Started with version 2.
When did you start developing the application and how long did it take?
We have released two versions so far, and we’re in the middle of our third version. We started in late 2013, and had our first version released in Oct 2014. The second version was released in Jun 2015.
How many developers worked on it? In total and on the UI.
5 Developers in total. 2 exclusively on the UI.
How big is the application? Lines of code, Number of classes.
Lines of Code: 132,000, No. of Classes: 860
How big is the JavaFX client? Lines of code, Number of classes.
Lines of Code: 76,000, No. of Classes: 548
Why did you choose JavaFX as frontend technology? And very importantly: why did you not choose HTML / Web?
Our team’s experience was primarily in Java so in order to immediately get started to deliver a front-end application, it was a natural decision to go for JavaFX. In hindsight, a stronger developer community as it exists for HTML/Web could have been a huge help.
Was it difficult to convince decision makers to agree on JavaFX?
No, decisions in startups are made faster and easier than in enterprise environments.
What were the biggest challenges / problems / issues / bugs you faced in the JavaFX part and how did you solve them?
The high memory consumption of JavaFX was particularly a trouble area for us. The only way to resolve it was to consider the performance constraints in our next iteration design and limit our design to what works.
Which 3rd-party products / frameworks / tools (open source and commercial) did you use and why did you choose them?
Initially we used the MiG Java Calendar which was based on Swing code, and then we switched to CalendarFX for its better UI design and use of JavaFX instead of Swing. We developed our own MVVM framework to support our Service Oriented Architecture. It turned out to be a huge project of its own, and we might open source it at some point to contribute to the JavaFX developer community.
Did you mix JavaFX and Swing code?
Initially yes when we used MiG Java Calendar.
Would you use JavaFX again for your next project? Please elaborate why or why not.
Which recommendations do you have related to JavaFX for other companies / projects?
We have made a significant investment in JavaFX technology both in terms of team’s experience over the years, as well as development of a complex MVVM framework. This is a strong reason to stay with JavaFX. On the other hand, we really envy the strong developer community that exists for the web apps and we can see how fast development can become once you have access to such communities with large portfolio of open source codes.
In addition, we’re facing severe issues when our users do not opt to update their client to the latest version. Distribution of JavaFX applications for Internet users is a lot more challenging than web based applications.
Which features would you like to see being added to JavaFX?
We’d like to see better performance (speed and memory.)
Do you plan to provide a mobile version of your application or a mobile addition?
We already have a native (Objective C) iOS app integrated into our SOA architecture. The mobile app and the JavaFX desktop apps work in tandem very well in our MVVM framework.