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

[Daniel Zwolenski]

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:

   - System is exiting
   - System is suspended/resumed
   - Screen orientation has changed
   - System has signalled that a document is to be opened (for which this
   app is registered as the handler for the extension type)

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<SystemStatus>
listener) // where SystemStatus is an enum of active, suspended, etc
Platform.screenOrientationProperty().addListener(ChangeListener<ScreenOrientation>
listener)
Platform.setOnOpenDocumentRequested(EventHandler<OpenDocumentRequestEvent>
listener)
Platform.setOnSystemExitRequested(EventHandler<SystemExitRequestEvent>
listener)

Or

Platform.getSystemEventChannel().addListener(SystemEventType type,
EventHandler<SystemEvent> 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.

4. 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
- one man's design pattern is another man's bloat.



>  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