Wednesday, 3 November 2010

OS X and Java Support

Apple have announced that Java will be deprecated on the next major OS X release, I think we can safely read that as basically broken. Will they give out their JVM source code for the community to continue with? Of course they won't. The reason they don't want Java applications on the Mac is they perceive the average Java application as having a poor/inconsistent UI compared to the Cocoa/Quartz standard. Java applications are also slower and more memory intensive than native applications. The community JVM will only be of worse quality than the Apple offering (unless some companies with heavy Mac/Java application investment step in). Java zealots can argue the difference can be reduced to a reasonably small amount, but the simple fact is that the average developer isn't skilled enough/lacks the time to achieve this. In essence, yes, I agree with Apple. Why should they have to maintain a technology that dilutes their  application quality, when overall quality in one of their unique selling points.

Are we going to rush off and create an objective C library component with exactly the same API as JGraphX so you can quickly recreate your application in Objective C? No. For one, we're not going to panic every time a company changes its mind and there's quite a lot that going on at the moment. We share Microsoft's view that HTML 5 canvas is going to be the lowest common denominator as a graphical platform and intend to build enough custom functionality on top of it, that for a hardware accelerated canvas you feel you could be working on a native application.

Is that not helpful to the Java developers (and only 3 people follow this blog to date, and I believe they are all Java developers)? Not really, we're continuing to support Java fully. We provide a very widely supported platform in the JavaScript mxGraph client. It's not free, like the Java client is, but the application written using JGraphX is only free if your time is worth nothing. The Java platform will remain a good way to prototype for the JavaScript client, having the same API. For academic and FOSS projects, we will be looking at some way to allow mxGraph to be freely used (free as in beer).

Ultimately, we feel that diagramming should be thin client with the server sitting virtualized in a cloud, be that public or private. I know these buzz words have been around for many years and never quite materialized, but it will arrive, one day.

Mobile Device Support, Native or HTML 5 Canvas?

All the rage now currently is support for mobile device, phones and tablets specifically. Is it the next big thing that we should all develop for? Do you need your workflow editor to work on a 4 inch touchscreen? I doubt it. Sure there are plenty of applications that make sense on smartphones, interactive diagramming most likely isn't one of them. Viewing diagrams, panning through them, maybe selecting cells, possibly. But this is possible using an image map and the processing on the server side.

Tablets are another matter. 7-10 inch screens make interaction possible, in fact, the whole process of diagram creation should be fundamentally different. But you'll see what I mean by that in the touchscreen examples we'll be releasing next year.

The question we're hearing a lot at the moment is are we going to support mobile platforms natively (iOS, Andriod, Symbian, Blackberry OS and Windows Mobile), or are we going to aim at getting mxGraph running on HTML 5 canvas and just have one implementation?

The second option would seem to be the obvious one, however, browsers implement things very differently. What looks like one JavaScript implementation in mxGraph is actually a heavyweight effort to smooth over the differences between browser under the hood of the mxGraph API. HTML 5 canvas is no different in this regard, the implementations vary wildly and the functionality available in HTML 5 canvas is really quite limited, especially when it comes to font rendering. 

On the iPad, for example, there isn't really any concept of a view port, from our initial investigations. This means having the graph extend beyond the visible region isn't possible with our current canvas prototype, and that will be some considerable effort to implement.

Ultimately, the question is do we focus on one thing that we consider to be our core work, or spread our bets amongst all the possible platforms? Our commercial strategy has always been to focus, even if the technology has started as being very niche. Why support the Java visualization client in addition? Because we always have and it serves as a very useful prototyping platform for us. Will Flash make it to production, no.

Production-wise the focus is do one thing and do it well. Doing one thing is the easy bit, just be too lazy to do a second...