Normally I try to keep my blog posts on the technical or showcase side but for a change I want to share some general thoughts I have about the state of LWUIT and the recent enlightening poll on this blog and the javalobby.
While there is still a day to go with our poll as I write this, the results are quite interesting and not what I expected. Although in retrospect they make sense, after all this is a blog for an open source project so it makes sense that most of you would vote to open source FX. However, the blog poll otherwise is almost identical to the JavaLobby poll in the sense that 70% of the votes voted for either open sourcing FX or giving up on it altogether (visitors to the JavaLobby preferred giving up on FX while visitors to this blog preferred open sourcing).
This got me thinking a bit, is this the typical knee jerk reaction of "open sourcing will solve everything" or is there something specific in JavaFX that you saw and would want it to be open source?
Please be specific in the comments and if possible try to describe the experience you have with FX.
On to a completely different subject... I was talking to a friend in the states a while back about LWUIT's portability to various platforms. He claimed that portability is problematic since the native platform will come out with new features which the application will need to assimilate meaning a constant race against the native OS and constantly providing an inferior experience.
I attacked that notion with the "Highest Common Denominator" approach we are trying to instill using LWUIT. Most native OS's (even the shiny new ones) are ridiculously huge beasts with heavy dependencies that tend to stagnate immediately. Even a small change to the underlying GUI core will break at least 20% of the 3rd party applications and cause the applications shipping with the OS heavy maintainability costs...
Since LWUIT is statically linked changes to LWUIT don't break everything so we are bold in our changes where OS manufacturers are timid and fragmented...
This means that OS's don't activate big changes by default since these changes cause huge regressions. A great example is touch scrolling on Symbian phones that took quite a while to provide the proper kinetic/tensile drag feel you get from comparable devices or even Nokia's own N900.
However, LWUIT on Nokia devices provided kinetic and later on tensile drag on all Symbian touch phones including those that don't "officially" support this functionality. Essentially LWUIT provided features that are "superior" to the native platform thus escaping the original "lowest common denominator" issue of portable code and striking back with a higher baseline of functionality. This isn't limited to Symbian, I recently demonstrated "Android like" thumb scrolling in LWUIT which is in some ways superior to the native Android scrolling. It allows device rotation while scrolling, is fully customizable and still allows tensile lists...
A highest common denominator strategy is harder to maintain since it requires a developer keeps his vigil over new platform features to introduce them immediately. A developer must also work against the LWUIT trunk where the new features are introduced constantly to support such development. The benefit however is in the ability to carry these features to the platforms that are behind which puts the developer at a vantage point in those platforms.
We believe that LWUIT enables this strategy and we are working hard to make this strategy practically seamless to anyone using LWUIT, most of our work and improvements (e.g. the major style change in 1.2) is designed around this premise.
What is so great about opening JavaFX. I am interested in JavaFX for mobile and in that segment I can't see any advantage of being open. JavaFX is not available for BlackBerry nor Android -Until now-, nor Symbian. And when it is available we will lose the whole market we are now have and we will start over again. I think there is no point to continue in JavaFX for mobile phones at least if we are not going to take a big advantage of using it.
ReplyDelete