Skip to main content

Posts

Showing posts from 2012

JavaFX - some later thoughts

I've been using JavaFX for a while now, in a couple of projects - for my PhD work, and on the side for Quelea (whose interface has been migrated entirely from Swing over to JavaFX.) As promised, I thought I'd post a few follow up thoughts - good points / bad points now that I've been using it a while. So, without further ado, the positives! The API is nice and clean - and not just because it's not stuffed with deprecated methods like Swing is, it's just designed in a fundamentally much more sensible way which makes it easier to follow. The concept of properties on elements, with these properties having a common interface, means I can jump right in with a component and see what properties are available to me without having to dig in the documentation to find out exactly how to add a listener for the width of the bottom half of my split pane (for instance.) Layout is vastly improved - a lot of the swing inconsistencies have gone, and the model is now a specific

Dropbox Java API

This code will no longer work! It uses the old v1 API, which has been turned off. See here for working code with the latest v2 API. As well as being useful as general cloud storage, dropbox also has an API that lets you access its contents programmatically. It's a straightforward REST API with a number of language specific libraries to make the going a bit easier. Java is included on the list of SDKs, but at present only Android is included on the list of tutorials. This can be somewhat frustrating because simple examples using Java are lacking. Fortunately, the process was described by Josh here . So I've taken it and implemented it in Java, and it seems to work. It's a very basic example that authenticates with dropbox then uploads a file called "testing.txt" containing "hello world." Of course, more functionality is available than this, but this is the hard part (at least I found working this bit out the hard part.) Once you've got your Dro

Sometimes, older is better...

When I first started Quelea, I wanted to use it as a kind of testing ground for features and ideas that hadn't already been incorporated into church presentation software. Both in terms of the UI, features and functionality. A lot of these features have worked really well - the ability to import from survivor songbooks for instance, and the instant search that's further improved in the next release. On the UI side of things I tried to have a go with the ribbon - it's still got a love/hate relationship with people, but I wondered if it could do any good in Quelea. So I had a go, implemented it and left it as such for a few releases. Thing is, it just didn't work - and I think this was a 50:50 split between it not being suitable for Quelea and the flamingo implementation. On the suitable for Quelea side: For something that's often run on laptops with small screens, it took up a huge amount of space it didn't need to. There weren't enough controls to make it vi

Java puzzler

You'll need an understanding of weak references to have a meaningful stab at this one. public class Test { public static void main(String[] args) { List<byte[]> list = new ArrayList<byte[]>(); Object thing = new Object(); WeakReference<Object> ref = new WeakReference<Object>(thing); while(ref.get()!=null) { list.add(new byte[10000]); } System.out.println("bam"); } } Before reading any further give it a stab, see what you come up with. Then run it and see. Oh and yes, it compiles and runs. ... Well, there's two possible options that you could have sensibly come up with. The first is what most people assume will always happen - the byte array will fill up to cause an OutOfMemoryError and the weak reference will never be garbage collected because there also exists a strong reference (thing) that remains in scope throughout the application and thus doesn't "