Wiki: XSystemTrayManager

XSystemTrayManager

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 XUI application.

To use this support the application must add an instance of the net.xoetrope.swing.XSystemTrayManager class. A good place to do this is in a XLifeCycleListener implementation

public class ProjectListener implements XLifeCycleListener
{  
  private static XSystemTrayManager sysTray;
  
  /**
   * Called when the application/applet has been created and initialized.
   * @param project the owner project
   */
  public void initialize( XProject proj )
  {
    final XProject project = proj;
    if ( sysTray == null ) {
      sysTray = XSystemTrayManager.getInstance( project );
      try {
        httpServer = new XHttpServer( 12190, new XHttpResponseHandler() {
          public XHttpResponse getResponse( String uri, String method, Properties headers, Properties params )
          {
            if ( params.get( "action" ) != null ) {
              sysTray.actionPerformed( null );
    
                  // If the startup properties/event has changed invoke the activation object
                  // sysTray.showActivationEvent();
            }
            return new XHttpResponse();
          }
        });
      } 
      catch ( IOException ex ) {
        DebugLogger.logError( "Unable to start the internal http server" );
        ex.printStackTrace();
      }
 
  }
  
  /**
   * Called when the application/applet has been shutdown and is about to exit
   */
  public void shutdown()
  {
  }
}

In the example above the application expects a request to the built-in server with a parameter 'action', but it does only checks that such a parameter is present. A more complex application could check for various paramters and take a range of actions, not just restart of the application.

Java Web Start Integration
When the net.xoetrope.swing.deploy.XSystemTrayManager class is installed it registers itself as a Singleton with JavaWebStart, so if the user relaunches the application by loading the JNLP file again then the tray manager is notifies and restarts the application with the new startup parameters. An additional interface, the XActivation interface is invoked if an instance of that interface has been set for the project (via XProject.setObject( "ActivationObject", inst );). The interface affords an application a changes to perform an appropriate action for the new startup parameters.

Further Web Integration and Scripting the relaunch
If the application launch integrates with a web page that page could include a link that makes a request to the client XUI application to see if it is still alive and if so fire wake it, if that request fails the link (via some AJAX JavaScript) could invoke the startup JNLP. While this strategy works on Internet Explorer browsers it faces some problems on Firefox where cross site scripting restrictions mean that the broswer cannot make the call to the localhost or client IP address (as the page probably did not originate there) unless the privilidges are raised, and that results in an ugly warning message being issued by the browser.

Of course, if the action can assume the application is running it just needs a simple external link to relaunch the application. Alternatively the script could make a request to the server to launch/relaunch the application, just as might be done on the client, but without the different security issues. The server can make the restart request to the client-ip address, or simply return the JNLP file.

Wiki : XSystemTrayManager

XSystemTrayManager