27.

  

User Interfaces from Factory Objects

In Chapter 13, some discussion was given to the location of code, using user-interface components as examples. That chapter suggested that user interfaces should not be created on the server side but on the client side ”the user interface should be exported as a factory object that can create the user-interface on the client side.

More arguments can be given to support this approach:

• A service exported from a low-resource computer, such as an embedded Java engine, may not have the classes on the service side needed to create the user-interface (it may not have the Swing or even the AWT libraries).
• There may be many potential user interfaces for any particular service: Palm handhelds (many with small grayscale screens) require a different interface than a high-end workstation with a huge screen and enormous numbers of colors. It is not reasonable to expect the service to create every one of these user interfaces, but it could export factories capable of doing so.
• Localization of internationalized services cannot be done on the service side, only on the client side.

The service should export zero or more user-interface factories, with methods to create the interface, such as getJFrame() . The service and its user-interface factory will both be retrieved by the client. The client will then create the user interface. Note that the factory will not know the service object beforehand; if the factory was given one during its construction (on the service side), the factory would end up with a service-side copy of the service instead of a client-side copy. Therefore, when the factory is asked for a user-interface (on the client side), it should be passed the service. In fact, the factory should probably be passed all of the information about the service, as retrieved in the ServiceItem from a lookup service.

A typical factory is the one that returns a JFrame . This is defined by the type interface as follows :

 package net.jini.lookup.ui.factory; import javax.swing.JFrame; public interface JFrameFactory {     String TOOLKIT = "javax.swing";     String TYPE_NAME = "net.jini.lookup.ui.factory.JFrameFactory";     JFrame getJFrame(Object roleObject); } 

The factory imports the minimum number of classes needed to compile the type interface. The JFrameFactory above needs to import javax.swing.JFrame because the getJFrame() method returns a JFrame . An implementation of this type interface will probably use many more classes. The roleObject passes any necessary information to the UI constructor. This is usually the ServiceItem , as it contains all the information (including the service) that was retrieved from a lookup service. The factory can then create an object that acts as a user interface to the service, and can use any additional information in the ServiceItem , such as entries for ServiceInfo or ServiceType , which could be shown, say, in an "About" box.

A factory that returns a visual component, such as a JFrame , should not make the component visible. This will allow the client to set the JFrame 's size and placement before showing it. Similarly, a " playable " user interface, such as an audio file, should not be in a "playing" state.