TwitterFX – What next?

Work begain on TwitterFX the weekend after the public release of JavaFX 1.0 and has continued, through fits and starts up until today.

Currently, it is a reasonably feature complete Twitter client based on JavaFX 1.1 and the question I have been asking myself is, where to from here?

As it stands today, the major outstanding activity is to port the application to JavaFX 1.2 and to use the native controls and new features released in the latest version.

Basic work has been undertaken to accomplish this work, there is a moderate amount of effort to get the application back to the point of running again, but further work is required to refactor code which relies on Java 1.1 features which have had their underlying API’s modified.

This is not terribly complicated, but I’m reluctant to do a straight port of the application and instead want to invest my time and effort in reassessing the goals of TwitterFX.

As it stands today there are a couple of possible thoughts which are not at all mutually exclusive. What I’d like to do is throw it open to the user base for comment and feedback.

Thought One – Split out the Twitter API code into a separate project.

I think its of value to have a separately evolving project which offers a JavaFX interface to the Twitter API, and that this library be able to be freely included in other projects which may need to communicate to Twitter.

Thought Two – Use TwitterFX as a reference JavaFX application

Consider if TwitterFX is stripped back to the functionality only available in the JavaFX Common/Desktop/Mobile profiles. Work can then be mainly on the internals and use the application as a ‘reference’ for building a medium sized app in JavaFX that targets mobile and desktop (and potentially TV).

Thought Three – Rework the internals for clarity and performance

Currently the under the covers impl of TwitterFX is in my opinion, somewhat haphazard which is making maintenance harder than it should be. There is also a significant amount of static initialization, which is why start up is relatively slow and why its initial memory footprint is higher than it could be.

Thought Four – Simple vs Complex

Much of the progression of TwitterFX was driven by attempts to become feature comparable with TweetDeck on the basis of it being the most popular and feature rich Twitter client. However, Desktop Tweetie (Mac only) was released during the development of TwitterFX and it became apparent to me that there is another, just as significant group of users – those who like something which is functionally limited, but is elegantly implemented.

To a certain extent the advanced mode/simple mode toggle did for a while cater for this, but I remain convinced as to if I am fully satisfying either audience.

For instance, Thought Two (A reference JavaFX application) would by definition result in a much simpler application, however other people have suggested it could also become a full social networking client, like a Seismic Desktop or Digsby.

Thought Five – Show me the money

Would you pay for this thing? Discuss.
(I have a Wife and Child who would quite like Daddy to have something show for all the nights and weekends he works on this thing).

Conclusion

Anyway, I wanted to throw this out there to let people know where my mind is at and have them opt in.

PS TwitterFX is now licensed under BSD (It’s no longer GPL 2)

Animated GIF’s in JavaFX, a word of warning…

I’ve learned many things over the course of putting together TwitterFX, and for the most part, I’ve failed to share them with the world!

I hope to change this over the coming weeks/months, but in the meantime, here is a tidbit.

One of neat things about JavaFX is the ease with which one can place Image and ImageView elements into your applicaton.

Not only does JavaFX support feedback on image loading and powerful effects, it will automatically render any GIF animation.

There is a however a caveat! Animated GIFs

JavaFX provides no way (that I can tell) to detect if an image is an animated GIF, or to control said GIF (for instance, to stop the animation)

Furthermore, the rendering of animated GIFs in JavaFX seems to be quite inefficient at this time and if you think you are going to add animation to your application easily by dropping in an animated GIF I wouldn’t recommend it.

In my experience, you can expect placing an animated GIF in your UI will cause your application to consume around 20% + more of CPU time on a Core 2 Duo! This may occur even if the image is hidden, but ceases after the image is removed from the scene graph.

Native JavaFX Timelines or the two Progress Indicator classes ProgressIndicator and ProgressBar l are a more efficient and powerful way of providing progress indicators or animation.

Tags: javafx, performance

TwitterFX: New dev version out (0.20b)

It can be access here:  http://herod.net/twitterfxdev/TwitterFX.jnlp

It includes

• Fix for counts on new tweets since scrolling changes
• Fix for duplicate new tweets since scrolling changes
• Now announces itself to Twitter as a proper client (Tells the world you are using TwitterFX)
• Switched to using https:// instead of http:// for all conversations with Twitter

I’m behind on a new ‘proper’ version, I just don’t want to officially release anything thats too dodgy!