[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    (was: The Next Great Thing: An Application Framework)
From:       zonski () googlemail ! com (Daniel Zwolenski)
Date:       2012-02-15 11:26:21
Message-ID: 0535A90C-81C5-46A8-9D26-358187039846 () gmail ! com
[Download RAW message or body]

+1 on this generics approach from me. 

Maybe getService or getProvider rather than getFeature? Then we can have a \
BluetoothService or BluetoothProvider, etc. 

Regarding Application class as the home for app specific stuff, I agree that makes \
more sense than my suggestion of using Platform.

I'd prefer feature based app extensions rather than OS based ones, ie I think it is \
better to have App.getSystemTray() rather than have a MacApp subclass. There will \
likely be feature overlaps between OS's, I don't care if I'm Mac, windows, linux, or \
ps3, I just care if my platform supports feature X, etc. Probably could use the same \
getService/getProvider approach suggested for Platform for this stuff too. 

On 15/02/2012, at 6:06 PM, Sven Reimers <sven.reimers at gmail.com> wrote:

> Looking at modularity and the question for a central feature query
> API, how about
> 
> public static <T extends Feature> T Platform.getFeature(Class<T> fe
> 
> This would make it still modular just ask for the feature ang get a
> feature instance to access all the necssary API.
> 
> Just my 2c
> 
> -Sven
> 
> On Tue, Feb 14, 2012 at 8:11 PM, Richard Bair <richard.bair at oracle.com> wrote:
> > 
> > > 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.
> > 
> > I agree, lets focus in on this first.
> > 
> > > > 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)
> > 
> > The idea is that these lifecycle events would actually be added to the \
> > Application class itself. Some lifecycle is already there "start" and "init" and \
> > "stop" for example. 
> > > > 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
> > 
> > I had thought about also making this the place to get other information or APIs \
> > such as Bluetooth support or Accelerometer support, etc. You could ask questions \
> > like "does this platform support a Camera?" and then you could get a reference to \
> > the camera and call API on it etc. I prefer this to having static methods on \
> > various far-flung classes. The downside is that it breaks modularity a bit, but I \
> > don't thinking having a dozen APIs here (with no implementation) is such a big \
> > loss. The implementation for these APIs (camera, bluetooth, accelerometer, GPS, \
> > etc) would all be in separate modules. 
> > > > 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!
> > 
> > I think it depends. For some things that can be done consistently across \
> > platforms (or, well enough for most uses) I'm in favor of an API that can span \
> > all platforms. However there will always be some stuff that simply isn't the same \
> > everywhere, and we want to allow people the maximum native integration they can. \
> > So for example I see nothing wrong with having a javafx.ext.macosx package which \
> > had Mac specific APIs for doing Mac specific stuff. I wouldn't want to have to \
> > resort to that for doing a menu bar. But perhaps there would be a MacApplication \
> > subclass of Application which would have extended APIs for doing mac specific \
> > menu bar stuff. I'm just making it up here as I go along, but that was the \
> > general idea. 
> > Richard
> 
> 
> 
> -- 
> Sven Reimers
> 
> * Senior System Engineer and Software Architect
> * NetBeans Dream Team Member: http://dreamteam.netbeans.org
> * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html
> * Community Leader  NetBeans: http://community.java.net/netbeans
> Desktop Java:
> http://community.java.net/javadesktop
> * Duke's Choice Award Winner 2009
> * Blog: http://nbguru.blogspot.com
> 
> * XING: https://www.xing.com/profile/Sven_Reimers8
> * LinkedIn: http://www.linkedin.com/in/svenreimers
> 
> Join the NetBeans Groups:
> * XING: http://www.xing.com/group-20148.82db20
> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home
> * LinkedIn: http://www.linkedin.com/groups?gid=1860468
> http://www.linkedin.com/groups?gid=107402
> http://www.linkedin.com/groups?gid=1684717
> * Oracle: https://mix.oracle.com/groups/18497


[prev in list] [next in list] [prev in thread] [next in thread]