(was: The Next Great Thing: An Application Framework) (original) (raw)

Daniel Zwolenski zonski at googlemail.com
Tue Feb 14 03:50:29 PST 2012

I agree that it is vague as to what an "Application Framework" is. We're all building "applications" so anything that helps us do that could be considered an "application framework" - including the JDK. Based on some of Richard's previous posts/emails I think he does (or did) have his sights set on a true high-level app framework, something that would allow people to quickly and easily implement 'modules' using a design pattern (such as MVP) and provide ways to navigate/communicate between these (possibly with some RAD tool for churning these modules out). In my emails I was using the term "application framework" in this sense, and it's this sort of thing I have my reservations about being part of the core JFX platform (though I would still very much like to see Richard/Oracle driving efforts on this front as a project on top of the core JFX platform).

Putting that topic aside, I agree that your "app kernal" concept is what JFX should include and focus on, i.e. the low level plumbing that a higher-level application framework can build upon. In fact that's really what JFX already is, a toolkit that provides low-level application plumbing for building graphical applications in Java (e.g. controls, observables, layouts, media, animations, styling - these are all part of the JFX "app kernal" in my view of it). Exploring what features we need at this level is something I see of importance and has been and continues to be a major focus of everything - i.e. what does JFX need in it? I do still think JIRA has been the medium for this conversation to date and has many hot topics in it that should be explored further.

It sounds like you and Richard have been brainstorming a couple of specific plumbing pieces, and I think exploring these further is definitely something we can/should do. A few questions and comments from me on each of the key areas you mentioned are inline below:

1. Provide a single point of abstraction for window to window interactions

Can you elaborate on what you mean by "interactions"? For me, typically a window will open another window and have a handle/reference to it. I'm not sure what JFX could give me to make this cleaner? If I need one window needs to communicate with another window, I just have it make regular Java calls onto the other via some custom API (e.g. I might have MyCustomWindow, which exposes methods like showSomeCustomContent()). Although, often in my architecture it is actually the controllers that do the communicating (and the controllers then update their views), and usually the controllers interact via some shared resource (like an event bus, or similar), and I simply inject this shared resource into each of the controllers as needed.

Is this what you are talking about when you say "interactions" and if so, what is it you see JFX providing for us on this front? For me this is possibly getting into design-pattern land, where no one-size-fits-all solution exists. In a pure desktop app for example, I often use a shared 'Application Model', which the controllers/windows can all watch and edit (like little bees all servicing the same hive). There's no need for an event bus in this design as the model is basically a 'stateful' event bus. In a distributed app however, with huge data sets all stored on the server, I tend to have my controllers work much more like a web page, where data is collected for the current view, shown, and then discarded. In this case I need a way to tell other components (which may be running in a secondary window, or may just be embedded in the same scene as the current component) that something has changed/been edited, etc. For this I do tend to use an EventBus, so the tools/patterns I use depend on the application I am building.

Maybe however, you have a different meaning of "interactions". If for example, you are talking about an API for just changing/managing window focus such as to-front, to-back, and maybe stuff like window modality, then that is definitely something I think that needs to be beefed up in JFX. That would be about providing some low-level plumbing with no impact or restrictions on which pattern is being used in that specific application.

2. Handling application targeted events.Receive and send OS to application

events / messages

This does sound like something useful but I'm not too clued up on what sort of OS events we might be able to send/receive? You list a few in your "random comments" below. I'll relist them here:

Is that what you mean here, and is that pretty close to the full list, or are there a whole lot more (working in Java land has left me a little vague in knowing what signals the OS can send an app)?

If it is just this sort of list then I'd like the idea of just having a way to register listeners for these via the Platform class. Either a 'system' event bus with event types, or individual listener lists for each event type.

So something like:

Platform.systemStatusProperty().addListener(ChangeListener listener) // where SystemStatus is an enum of active, suspended, etc Platform.screenOrientationProperty().addListener(ChangeListener listener) Platform.setOnOpenDocumentRequested(EventHandler listener) Platform.setOnSystemExitRequested(EventHandler listener)

Or

Platform.getSystemEventChannel().addListener(SystemEventType type, EventHandler listener)

3. Provide application context information. A single point of access to

query and interact with settings and environment information. Some of the information would be architecture specific, but not limited to such information. For instance, calling getRenderingPipleline() would return the rendering engine that JavaFX is using. That choice is made at runtime and based on other native and non-native conditions.

Being able to find out anything and everything about our JFX runtime environment would be extremely useful. I would have thought the 'Platform' class would be the logical place for these sorts of things too. So I could call Platform.getRenderingPipeline(), Platform.getJavaFxVersion(), etc.

  1. Provide commonly used functionality to simplify application development

    and promote basic greater consistency for standard application functionality.

    This one is a little general. Can you give some details on what you mean? We flirt with the danger again of what "commonly used functionality" means

2. How does a developer "quit" and application? Is it when you close a

window? In a single window environment on the Windows platform it (typically) means quit. On the Mac it means dismiss the window, but the app is still alive (oops ... no calls to System.exit() on WindowClosed event if you want to be Mac friendly). In a multi-window environment it could mean many things. On a mobile platform moving to a new window (or rather a page) means just changing context. On a mobile device the "quit" action or event comes from pressing a physical button on the device. Where is the support for "quit" in JavaFX?

There are definitely cross platform challenges here with things like multi-window support, OS-level toolbars, system trays, task bars, etc. Java will always suffer somewhat on this front because it is trying to work on every platform. Within a window the OS is generally "hands-off" and we can do what we like but when were dealing "outside" the window, we're in OS-controlled land, the OS gets very involved and wants things done a certain way.

For a cross platform application, the choices really are:

  1. Support least-common-denominator functionality. i.e. just handle one basic solution that works on all platforms and does nothing fancy. If the OS does something funky (like Mac does) just not support it - this is the AWT model, simple and safe but obviously not ideal usability.

  2. Try and do some magic stuff (like with the useSystemToolbar() thing in 2.1), where the developer in theory can just write code once and the JFX platform will do the stuff needed to map that code to what's needed on that platform. This is a noble goal, but somewhat dangerous as the little idiosyncrasies of each platform generally require more than just moving a toolbar from the left to the right, etc. Getting it right is very hard (which is why AWT was ditched and Swing went for "lightweight" components). They often introduce whole new situations that need to be handled by the developer specifically for that app (e.g. a toolbar that is still showing after all the active windows are closed). The difference between platforms like mobile and desktop are significant.

  3. Provide platform specific APIs that expose certain features (e.g. system toolbar manipulation and control) and throw exceptions if those features are not supported on that platform. This requires the developer to do a lot more work, and write custom if-then-else code to support each type of platform (if they want to take advantage of that platform's special features). It is a fairly safe/honest approach however, unlike the magic solution, which does stuff without you really getting involved in the process. The specific API approach keeps the control of the application/features in the hands of the application developer who is really the only person who knows exactly what their app should do on a Mac vs Windows vs mobile.

For me I prefer option 3 as I'd rather do a little more work and make sure things work properly and consistently. I'm pretty sure I might be an odd one out in this case (I also dislike CSS selectore for the same general problems with consistency and predictability - and most people love this stuff), so the leaning will most likely be towards option 2. In that case, I think it's just important in these cases to make sure the magic really does work and work well.

Looking forward to hearing other points of view on all these topics!

Dan

More information about the openjfx-dev mailing list