The Flavors of Drag-and-Drop Java Systems

Last week I introduced Drag and Drop by way of warning you about its complexity.

Now we'll look at why. The goal of the system is to move, or copy, some information, which is represented on the screen by a GUI component, to some receiving object, which is represented by another such component.

In the context of the Java language, this is accomplished handily by dealing with this act in terms of the objects involved: the sending and receiving GUI objects, and the actual source and destination objects. The "data source" is usually just a commonplace data object of some kind, while the destination could be another place for it to reside, for example, or a set of routines for doing something with it.

Simple, right?

This is more complicated than it sounds. In order to make a truly general and powerful drag-and-drop system, you must have the ability to drag any number of different kinds of information, and have each be handled appropriately by its destination. To orchestrate this (a process called data negotiation), it's necessary for the data source and the data destination to keep lists of the kinds of data they can handle (Sun calls these "data flavors"), and their relative "preferences" for each, and so forth. For example, a word processor object would prefer to receive data in its own data format rather than as plain ASCII, if it's available that way, but it can accept either.

Furthermore, objects must engage in a kind of negotiation every time they come into contact with each other, to determine whether or not the source can produce its data in a format the destination can understand, and if so, which format would be best. For those familiar with the concept, you can think of the various "flavors" of data in terms of MIME types--MIME being the venerable, universal data typing warhorse of the Internet industry.

But Sun couldn't stop there. For the scheme to be really powerful, it would need not to just be internal to Java. It would have to work transparently with the rest of its host environment. There must be carefully planned and meticulously constructed interfaces between Java's own Drag and Drop system and each platform's own windowing and drag and drop system--and given the disparity between the various systems currently in play today, that's a monumental task in itself.

Finally, there needs to be management of the graphical frills that provide feedback to the user, so that they can actually "see" an object being dragged from one location to another on the screen, and accepted or rejected over various "destinations."

Generally, this means that the system must make it convenient for the mouse cursor to be changed and/or animated differently depending on the different situations that could possibly arise while "picking up," "dragging," & "dropping" a given interface object--so that it can appear as an "X" over regions where a given object can't be dropped, for instance.

All of this requires a thorny tangle of specifications and APIs, with each piece tending to different aspects of the problem. Your bottom line, if you're a developer, is that there will be no free rides. If you want to make draggable and droppable objects, you'll have to write a lot of code to support it, and that may or may not be worth it, depending on your design goals.
 
Yet the ride may be cheaper than you think--the wonders of object-oriented programming make it quite possible for class designers to do the work for you just once so that you may be able to inherit simple good behaviors for ever thereafter. At the very least, one can imagine that a Swing "text box" GUI component will "automatically" represent its contents properly as text/plain, and will be able to accept that format should an object be dragged over it which can express its information that way.

The ideal, of course, would be that you get this extravagant functionality for free; in fact, as a user, you'll probably at least get something good enough that you'll forget where Java ends and your operating system begins, although that is perhaps something your OS vendor wants anyway.

More to come next week. Stay with us . . .