|
|
|
|
Sponsored Link •
|
|
Advertisement
|
UI objects should be user adapters, as shown in Figure 2. Two temptations that service and UI providers may have are:
Both temptations should be avoided. The Jini service proxy should contain the service functionality, the whole service functionality, and nothing but the service functionality. No user-interface code should appear in the service proxy, and no service functionality should appear in the UI object unless it also appears in the service proxy. In short, Jini Service UIs should merely offer users all or part of the functionality available to direct-use clients via the Jini service proxy's methods.
Note that even though the service item may be passed as the role object for
some roles -- as it is to factories that produce MainUIs, AdminUIs, and AboutUIs --
the full service functionality should nevertheless be available
exclusively through the service proxy. The service item may be passed as the
role object to UI factories because extra information (but not extra
functionality) could exist elsewhere in the service item, in the service ID
or attribute sets, and the UI may wish to display that extra information to
the user.
It is strongly encouraged that service and UI providers decouple the class files required by a particular service item from the class files required by any UIs associated with that service via UI descriptors in the service item. If the class files for the service item and those of all service-associated UIs via UI descriptors are placed into the same JAR file, then a client must download all class files for all UIs just to download the service item, even if the client never uses a single UI.
This specification does not mandate any UI types to be associated with services. Service providers are free to provide any types of UI, or no UIs, with their services. Nevertheless, some discussion of client expectations may help service providers decide what UI types to supply.
First, if a service provider only supplies one UI, it should likely be an
embeddable component, such as an AWT Panel or Swing JComponent.
Although Swing UIs can be more attractive than AWT UIs, an AWT Panel may
allow the greatest reach with one UI type.
A Panel
allows clients to show a UI without another pop-up window, whether they support
AWT or Swing. If a client wants to pop up a UI, it can embed a Panel UI in a
new Frame
and pop that up. If a client wants to display a Panel title and icon, it can use the
localized name and icon provided by a ServiceType.
A Panel
doesn't usually provide an exit for the client, and a menu bar at the top of a Panel
is uncommon.
So as a UI provider, you may also want to provide either a Frame or a Window in
which Panel is placed
and add other UI elements, such as menu bar, status bar, and title. If you take
this approach, one factory object could implement both the PanelFactory
and the FrameFactory
interfaces, because their toolkit is the same. This might make sense if the Panel is used
in the Frame,
and the Frame
doesn't require many classes not already used by the panel. Alternatively, you could produce the Panel and Frame by two
different UI factories sitting in two different UI descriptors.
You may also wish to support Swing in addition to, or instead of,
AWT. If so, at a minimum a Swing JComponent UI, or a JComponent
with either a JFrame
or a JWindow, may
be more suitable. If you take the second approach, one factory object could
implement both the JComponentFactory
and the JFrameFactory
interfaces, because their toolkit is the same. Alternatively, two different UI
factories sitting in two different UI descriptors could produce the JComponent and
JFrame.
On the other hand, for those UI roles that represent user dialogs, an AWT Dialog or
Swing JDialog
may be more appropriate.
Currently no direct support exists in the Jini Service UI API for
speech-only interfaces, but an AWT or Swing UI could be enhanced with speech
capabilities, produced by an appropriate AWT or Swing UI factory type, and
identified as speech-enabled with the appropriate required package names (such
as javax.speech)
in the RequiredPackages
attribute. If a speech-enhanced GUI is provided, a GUI-only version should also
be provided, as many clients won't have speech capabilities.
Service-level data and client-context data are two data types you may be tempted to pass to UI objects, either directly or via factory methods (which may then tempt you to define new factories). It is strongly recommended that you avoid both temptations.
For example, imagine a service provider requires a user name and password for its service. The service provider wants clients to be able to save a user's name and password locally and enter them automatically the next time the user uses the service. If no user name and password were previously saved, the service UI would prompt the user to type them into a logon dialog box. But if the user name and password were saved, the user would never see the logon dialog box. Rather, the client program would log on automatically with the saved user name and password, and display to the user only the service UI that appears after a successful logon.
To implement this functionality, a service provider might be tempted to define interfaces that allow the client to pass a saved user name and password to the UI. Alternatively, a service provider might be tempted to define new factory methods that enable clients to pass a user name and password to the factory, which could then send them to the UI.
The trouble with either of these approaches is that functionality is being put into the UI that isn't in the service. As mentioned previously, a Jini service's functionality should be modeled in the service proxy, so direct-use client code can just use the service directly. If a service requires a user name and password, the service proxy's interface should allow the client to provide the user name and password. Thus, a client with a user could give the user name and password to the service proxy first, then create the UI. The UI could ask the service proxy if it has a user name and password yet. If not, the UI would show the logon dialog box prompting for the user name and password. Otherwise, the UI wouldn't show the logon dialog box.
The recommended way to design a Jini service and its UIs is to make sure the full functionality is available via the service proxy interface, and keep the UIs focused on being user adapters -- adapting some or all functionality available via the service proxy interface, but offering no more functionality available via the service proxy interface.
Service providers are not the only Jini Community members who will face UI-related temptations in the years ahead; client providers may also be tempted to pass client context data to UI objects.
For example, a client provider wishing to differentiate his or her product from the competition might add a toolbar and status bar to the client program. The client provider might be tempted to define interfaces that allow the client to pass references to the toolbar and status bar to the UI. Alternatively, the client might be tempted to define new factory interfaces whose factory methods include parameters that allow the client to pass references to the toolbar and status bar to the factory, which could then pass it along to the UI. UIs that obtain references to the toolbar and status bar in either of these two ways could then put buttons on the toolbar and write messages to the status bar.
The trouble lurking behind this seemingly innocuous value-add is that the toolbar and status bar references represent client context data, which complicates the UI providers' jobs. If other clients devise their own toolbar and status bar interfaces, and perhaps even up the ante by also defining other client context innovations, UI providers will have to worry about which kinds of client context to support. To the extent a UI provider supports various kinds of client context, that UI provider's test matrix will expand. To the extent that client context becomes complicated, such as the invention of a general compound document model for Jini Service UIs, everyone's job, and the user's experience, become more complicated.
Client providers, therefore, should avoid the temptation to invent client
context for Jini Service UIs. The only context data that should be passed to UI
factory methods is context a UI toolkit requires, such as the Frame or Window
reference required by an AWT Dialog. Similarly, the only context in which Jini
Service UIs should be embedded is context the toolkit provides. For example, a
client could embed a Jini Service UI JComponent in a JFrame, and
then pop up the JFrame.
The JComponent's ability to embed
is provided by its toolkit, Swing.
UI providers can do their part by ensuring that their UIs don't depend on any context other than that provided by the UI toolkit. Jini Service UIs should be self-contained and care only about the context of their toolkit. If a UI provider wants its UI to write messages to a status bar, the UI should not look for a status bar provided by the client, the UI should itself include a status bar.
|
Sponsored Links
|