Application Styles

Setting the layout configuration

The basic frameset is specified using the frames file that was used for the basic frames setup earlier (see Framesets.), but for docking layouts we must add some extra information detailing how the screen is to be divided up. For example the following:

Setting up a docking layout

 <FrameSet layout="(COLUMN (ROW weight=1.0 left 
 (COLUMN middleTop content middleBottom) right) bottom)">
   <Frame name="left" constraint="left" content="p1" 
      icon="aria_icon.png" sidebar="west" title="Dock to the left"/>
   <Frame name="right" constraint="right" content="p2" icon="aria_icon.png" sidebar="east"/>
   <Frame name="middleTop" constraint="middleTop" content="p3" icon="aria_icon.png" sidebar="west"/>
   <Frame name="middleBottom" constraint="middleBottom" content="p4" icon="aria_icon.png" sidebar="south"/>
   <Frame name="content" constraint="content" content="Welcome" icon="aria_icon.png" sidebar="west"/>
   <Frame name="bottom" constraint="bottom" content="p6" icon="aria_icon.png" sidebar="south"/>
 </FrameSet>

The docking layout is specified as an attribute of the FrameSet element, and follows the format specified by the SwingLabs MultiSplitLayout layout manager (see http://today.java.net/pub/a/today/2006/03/23/multi-split-pane.html ).

Docking options

Each of the docked frames has a number of properties that yo can use to customize the appearance of the docked frame, and these are:

Embedded applications

Not all applications are standalone and in some cases an application needs to coexist with legacy functionality or functionality obtained from a third party. Therefore there are situations where an application does not have direct control of its startup or of its frame. For this purpose Aria and Aria applications can be embedded in a standard Swing application as though the Aria application was just a Panel or just another component being used by the application.

The key to embedding a Aria application is the XContentHolder interface which describes the content displayed to the user. The interface is used by the page manager to display the pages that makeup the Aria application.

Modular application

Just as a Aria application can be embedded in a legacy application, one Aria application can be embedded in another. In fact multiple Aria applications can coexist within the one JVM. Applications used in this way can also exist as standalone entities in their own right. Turning this about, applications can therefore be built in a modular way, such that a component or module can also exist and operate as a complete application.

Building applications in a modular way allows you to deliver functionality in a targeted way, depending on things like user roles/needs, security/access rights, connectivity levels, development schedules or even for commercial reasons (e.g. advanced features for power users). With a modular architecture you can be more targeted with your delivery of functionality.

Aria's support for modular applications extends throughout the platform and apart from the loading of the modules you can largely regard the separate modules as being part of the complete application from a development standpoint.

Set startup objects

Multple startup objects can be added simply by adding startup property entries in the form:

Listing the startup objects

 StartupObject<N>=Name;className
 StartupObject<N>=Name;className;Project

where is a counter starting from 0. In the second example the object is constructed via a constructor that takes an instance of the project as an argument

While this may seem like an insignificant change it opens up the possiblity of having multiple applications running within the same JVM and it means that an application can be built from modular elements, elements that can exist as standalone applications or as integrated modules.

Relaunching applications

Support for the system tray or launch area has been added. When a system tray icon is added the application can choose to stay resident in memory after the main window has been closed by setting the " ExitOnClose " startup property to false. The advantage of doing this is that the data model does not need to be reinitialized if the main window is just being redisplayed. This initialization can be significantly quicker than normal startup as all the classes needed by the JVM are already loaded. If remote data is used the startup gain may be even greater as network access may not be required.

The tray icon provides two menu items, one to open the window and the second to close the window and exit the JVM.

This version of the class uses the SwingLabs version of the tray support and is therefore limited to Swing. If JDK 6 or later is being used then the JVM's tray support could be used for non Swing applications.

The system tray/stay resident option may be particularly valuable when used in conjunction with an embedded webserver, as a remote server could thereby signal the application to wake up and display new data or alerts as when such data becomes available by simply making a request to the client application's server. The same process could also be used to provide a tighter integration between a web page/web application and a Aria application.

To use this support the application must add an instance of the org.formaria.swing.deploy.SystemTrayManager class. A good place to do this is in a LifeCycleListener implementation

Setting up the system tray

 public class ProjectListener implements LifeCycleListener
 { 
   private static SystemTrayManager sysTray;
   /**
     * Called when the application/applet has been created and initialized.
     * @param project the owner project
     */
   public void initialize( Project proj )
   {
     final Project project = proj;
     if ( sysTray == null ) {
       sysTray = SystemTrayManager.getInstance( project );
 
     // Do remaining initialization and network access
     }
   } 
 
  /**
    * Called when the application/applet has been shutdown and is about to exit
    */
   public void shutdown()
   {
   }
 }

Embedded webserver

A minimal http server is now embedded at org.formaria.http.HttpServer . When customized this server will allow a server appplication to signal a client via a http request. By customizing the server with a response handler the application can then respond with special actions, such as a wake-up or by requesting updates/new data from the server.

JNLP support

As an alternative to using the embedded webserver an application can use the JNLP API to request that it is a singleton, that is that only one instance of the application should run at a time. The SystemTrayManager takes care of most of the work and it will invoked the Activation interface specified by a project if one is present if an attempt is made to relaunch the JWS application while the instance is still in memory . The activation object is specified as follows sometime following startup:

Setting the activation object

 project.setObject( "ActivationObject", this );

Typically the application will restart its user interface once reactivated. Of course care should be taken to do this on the EventDispatchThread.

A typical restart handler2

   public void activate()
   {
     String[] args = (String[])project.getObject( "StartupArgs" );
     final String eventType = args.length > ProjectListener.EVENT_TYPE_ARG ? 
                 args[ ProjectListener.EVENT_TYPE_ARG ] : null;    
     final String eventID = args.length > ProjectListener.EVENT_TYPE_ID ? 
                 args[ ProjectListener.EVENT_TYPE_ID ] : null;    
 
     // Query the startup event in the background
     if (( eventID != null ) && ( eventID.length() > 0 )) {
       SwingWorker worker = new SwingWorker() 
       {
         public Object construct() 
         {
           // Do the work off the EDT
           String url = "workspaces/myevent/" + eventID;
 
           ProjectListener.queryEvents( project, eventType, url );
           return null;
         }
 
         public void finished() 
         {
           // Now, on the EDT update the tree and show the event.
           getBinding( taskList ).get();
           showEvent( eventID, eventType );
           setSelectedNode( eventID );
         }
       };
       worker.start();    
     }
   }
 

To use this type of functionality the application must make sure that the application does not exit the JVM when the main frame is closed, and this is done with by overloading the XLifeCycleListener's shutdown method - the tray manager takes care of the rest

Prevent JVM Exit

 /**
  * Initialize the project's connection
  */
 public class ProjectListener implements LifeCycleListener
 {
   ...
 
 	  /**
    * Called when the application/applet has been shutdown and is about to exit
    */
   public void shutdown()
   {
   }

‹ Navigation and Page Management up Input Validation ›