Storage of Application Preferences
Users of your applications will usually expect that their preferences and customizations are saved, and later restored when the application starts again. First, we cover the simple approach for storing configuration information in property files that Java applications have traditionally taken. We then turn to the powerful preferences mechanism that was introduced in Java SE 1.4.
A property map is a data structure that stores key /value pairs. Property maps are often used for storing configuration information. Property maps have three particular characteristics:
Property maps are useful in specifying configuration options for programs. For example:
Use the store method to save this list of properties to a file. Here, we just save the property map in the file program.properties. The second argument is a comment that is included in the file.
It is customary to store program properties in a subdirectory of the user’s home directory. The directory name is often chosen to start with a dot—on a UNIX system, this convention indicates a system directory that is hidden from the user. Our sample program follows this convention.
To find the user’s home directory, you can call the System .get Properties method, which, as it happens, also uses a Properties object to describe the system information. The home directory has the key "user.home". There is also a convenience method to read a single key:
It is a good idea to provide defaults for our program properties, in case a user edits the file by hand. The Properties class has two mechanisms for providing defaults. First, whenever you look up the value of a string, you can specify a default that should be used automatically when the key is not present.
If there is a "title" property in the property map, title is set to that string. Otherwise,title is set to "Default title".
If you find it too tedious to specify the default in every call to get Property, then you can pack all the defaults into a secondary property map and supply that map in the constructor of your primary property map.
Yes, you can even specify defaults to defaults if you give another property map parameter to the defaultSettingsconstructor, but it is not something one would normally do.
The program remembers the frame position, size, and title. You can also manually edit the file .core java /program .properties in your home directory to change the program’s appearance to the way you want
NOTE: Properties are simple tables without a hierarchical structure. It is common to introduce a fake hierarchy with key names such as window .main .color, window .main .title, and so on. But the Properties class has no methods that help organize such a hierarchy. If you store complex configuration information, you should use the Preferences class instead —see the next section.
NOTE: You can find the names of the freely accessible system properties in the file security/ java.policyin the directory of the Java runtime.
The Preferences API
As you have seen, the Properties class makes it simple to load and save configuration information. However, using property files has these disadvantages:
Some operating systems have a central repository for configuration information. The best -known example is the registry in Microsoft Windows. The Preferences class of Java SE 1.4 provides such a central repository in a platform -independent manner. In Windows, the Preferences class uses the registry for storage; on Linux, the information is stored in the local file system instead. Of course, the repository implementation is transparent to the programmer using the Preferences class.
The Preferences repository has a tree structure, with node path names such as /com /mycompany /myapp. As with package names, name clashes are avoided as long as programmers start the paths with reversed domain names. In fact, the designers of the API suggestthat the configuration node paths match the package names in your program.
Each node in the repository has a separate table of key /value pairs that you can use to store numbers, strings, or byte arrays. No provision is made for storing serializableobjects. The API designers felt that the serialization format is too fragile for long-term storage. Of course, if you disagree, you can save serialized objects in byte arrays.
For additional flexibility, there are multiple parallel trees. Each program user has one tree, and an additional tree, called the system tree, is available for settings that are common to all users. The Preferences class uses the operating system notion of the “current user” for accessing the appropriate user tree.
To access a node in the tree, start with the user or system root:
Then access the node. You can simply provide a node path name:
A convenient shortcut gets a node whose path name equals the package name of a class.Simply take an object of that class and call
Note that you must specify a default value when reading the information, in case the repository data is not available. Defaults are required for several reasons. The data might be missing because the user never specified a preference. Certain resource-constrained platforms might not have a repository, and mobile devices might be temporarily disconnected from the repository.
Conversely, you can write data to the repository with put methods such as put(String key, String value)putInt(String key, int value) and so on. You can enumerate all keys stored in a node with the method String keys
But there is currently no way to find out the type of the value of a particular key. Central repositories such as the Windows registry traditionally suffer from two problems:
The Preferences class has a solution for the second problem. You can export the preferences of a subtree (or, less commonly, a single node) by calling the methods
The data are saved in XML format. You can import them into another repository byCalling void importPreferences(InputStream in) Here is a sample file:
If your program uses preferences, you should give your users the opportunity of exporting and importing them, so they can easily migrate their settings from one computer to another. The program simply saves the position, size, and title of the main window. Try resizing the window, then exit and restart the application. The window will be just like you left it when you exited.
This concludes our discussion of Java software deployment. In the next chapter, you learn how to use exceptions to tell your programs what to do when problems arise at runtime. We also give you tips and techniques for testing and debugging so that not too many things will go wrong when your programs run.
Core Java Related Interview Questions
|J2EE Interview Questions||Core Java Interview Questions|
|JDBC Interview Questions||JSP Interview Questions|
|Android Interview Questions||JavaServer Faces (JSF) Interview Questions|
|Java collections framework Interview Questions||Java 8 Interview Questions|
|Java Collections Interview Questions||Java Exception Handling Interview Questions|
|Java Concurrency Interview Questions||Java Serialization Interview Questions|
|Java Programmer Interview Questions||Java Inheritance Interview Questions|
|Java IO Interview Questions||Object Oriented Programming in PHP Interview Questions|
Core Java Tutorial
An Introduction To Java
The Java Programming Environment
Fundamental Programming Structures In Java
Objects And Classes
Interfaces And Inner Classes
User Interface Components With Swing
Deploying Applications And Applets
Exceptions, Logging, Assertions, And Debugging
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.