asp.net mvc generate qr code User Interfaces for Jini Services in Font

Creation ECC200 in Font User Interfaces for Jini Services

ini is designed to allow client programs to discover and interact with services. There is no user interface explicitly involved in this, although many clients will have a user interface to talk to a user. However, services may wish to offer a user interface for a client to show to a user. This could be for many reasons, such as extended functionality, or to give the service a particular look and feel. In this chapter, we look at how a service can advertise user interfaces, how a client can choose an appropriate interface, and how the client can use a service s user interface.

Interaction with a service is specified by its interface, and this is the same across all implementations of the interface. Just using the known interface doesn t allow any flexibility in using the service, because a client will only know about the methods defined in the interface. The interface is the defining level for using any service that implements the interface, but services can be implemented in many different ways, and service implementations do, in fact, differ. There is a need to allow for these differences, and the mechanism used in Jini is to put the differences in Entry objects. Typical objects supplied by vendors may include Name and ServiceInfo. Clients can make use of the interface and these additional entry items, primarily in the selection of a service. But once clients have the service, are they constrained to use it via the type interface The type interface is designed to allow a client application to use the service in a programmatic way by calling methods. However, many services could probably benefit from some sort of user interface. For example, a printer may supply a method to print a file, but it may have the capability to print multiple copies of the same file. Rather than relying on the client to be smart enough to figure this out, the printer vendor may want to call attention to the capability by supplying a user interface object with a special component for number of copies. The user interface for a service cannot expect to have all details supplied by the client at best, a client could only manage a fairly generic user interface. The user interface should come from the vendor, or maybe even a third party (when your video player becomes Jini enabled, for example, it would be a godsend for someone to supply a decent user interface for it, since the video player vendors seem generally incapable of doing so!). The Entry objects are not just restricted to providing static data; as Java objects they are perfectly capable of running as user interface objects.

15 discussed the location of code, using user interface components as examples. The chapter suggested that user interfaces should not be created on the server side but on the client side. So 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: 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 (e.g., it may not have the Swing or even the AWT libraries). There may be many potential user interfaces for any particular service. For example, the Palm Pilot, with its small grayscale screen, requires a different interface from a high-end workstation with huge screen and enormous number of colors. It is not reasonable to expect the service to create every possible interface, 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 entry 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 it was given one during its construction (on the service side), it would end up with a service-side copy of the service instead of a client-side copy. So when it is asked for a user interface (on the client side), it should be passed the service as well in a parameter to user interface creation. In fact, it should probably be passed all of the information about the service, as retrieved in the ServiceItem obtained from a lookup service. A typical factory is the one that returns a JFrame. This is defined 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 for the interface to compile and be exported. An implementation of this interface will probably use many more. The roleObject passes in any necessary information to the UI constructor. This is usually the ServiceItem, which contains all the information (including the service) that was retrieved from a lookup service. The factory can then create a UI that acts as an interface to the service, and it 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 this should not make the component visible, in order to allow the component s size and placement to be set before showing it. Similarly, a playable UI, such as an audio file, should not be in a playing state.