[Review request] Image loader API

[Richard Bair]

>> Since Worker doesn't define the onXXX event handlers, you can redefine them, such that you have a subclass of WorkerStateEvent that defines your image load events, and have all the onXXX event handlers on ImageLoader to be based on those event handlers. getWorker could be defined to return ImageLoader for example.
> 
> We can do that currently only if the ImageLoadingEvent types will be completely unrelated to the WorkerStateEvent types. Otherwise we won't be able to correctly define ImageLoadingEvent.ANY or ImageLoadingEvent.LOADING_FINISHED associated with ImageLoadingEvent. Such generic event types would need to be associated with WorkerStateEvent and user code will need to upcast in order to access specific information associated with ImageLoadingEvent. If we leave the event types unrelated, I don't see any benefits in subclassing WorkerStateEvent.

Agreed.

> So what if we leave these event classes unrelated and keep the ImageLoader as originally proposed (without extending Worker), but add the following two methods into it:
> 
> Worker getLoadingService();
> Worker getLoadingTask(Image image);
> 
> The first one will allow to get the Worker which allows to observe the loading process as whole and the second one to observe loading of a single image.
> 
> Examples:
> 
> 1) generic dialog with total progress
> ImageLoader imageLoader = new ImageLoader();
> image1 = imageLoader.loadAsync(...);
> image2 = imageLoader.loadAsync(...);
> image3 = imageLoader.loadAsync(...);
> image4 = imageLoader.loadAsync(...);
> totalProgressDialog.track(imageLoader.getLoadingService());
> 
> 2) generic dialog with detailed progress
> ImageLoader imageLoader = new ImageLoader();
> image1 = imageLoader.loadAsync(...);
> image2 = imageLoader.loadAsync(...);
> image3 = imageLoader.loadAsync(...);
> image4 = imageLoader.loadAsync(...);
> detailedProgressDialog.track(
>        imageLoader.getLoadingTask(image1),
>        imageLoader.getLoadingTask(image2),
>        imageLoader.getLoadingTask(image3),
>        imageLoader.getLoadingTask(image4));
> 
> The advantages of this solution is that it will keep ImageLoader simple, while it will allow generic progress tracking (total or detailed). We can also return some Worker subclass which would allow to register WorkerStateEvent handlers or support advanced user cases (for example define Executor for loading service).
> 
> What do you think?

I'm not sure I see an advantage to moving the loading service off the image loader itself, but I agree it sounds like a workable solution. I spent time last week on ScheduledService (http://javafx-jira.kenai.com/browse/RT-18702) and filed an issue for ConcurrentService (http://javafx-jira.kenai.com/browse/RT-27952) which is more like what ImageLoader could extend from (vs. the other Services). To me it is an open question as to whether it is better for ImageLoader to extend from Object but *have* a service, or whether it ought to *be* a Service (of the ConcurrentService variety, which would extend from a new ServiceBase base class rather than from Service directly the way ScheduledService does).

Richard