standard practices for storing user settings

Thread view:

Brandon McCombs - 27 Dec 2006 23:48 GMT

I have built an application that currently stores user connection
settings in a binary file. Of course it takes a lot of work to add in an
extra parameter to be saved because I have to modify how the data is
written to and read from the binary file. I wanted to know what the
standard practice is for storing user settings. Should I be creating a
properties file when a user chooses to save his settings? Are they meant
to be used at the user level or the application level? Are there other
ways to do this same thing (besides using the windows registry)?

thanks
Brandon

Reply to this Message

Daniel Dyer - 27 Dec 2006 23:56 GMT

> I have built an application that currently stores user connection
> settings in a binary file. Of course it takes a lot of work to add in an
[quoted text clipped - 4 lines]
> to be used at the user level or the application level? Are there other
> ways to do this same thing (besides using the windows registry)?

Use the Preferences API
(http://java.sun.com/j2se/1.5.0/docs/guide/preferences/index.html).

If I remember correctly, it stores values in the registry on Windows and
in an XML file in the user's home directory on Linux/Solaris.

Dan.

Signature

Daniel Dyer
https://watchmaker.dev.java.net - Evolutionary Algorithm Framework for Java

Reply to this Message

Stefan Ram - 28 Dec 2006 00:07 GMT

>I wanted to know what the standard practice is for storing user
>settings.

One needs a per-user storage place as a starting point.
I believe, this is:

http://download.java.net/jdk7/docs/api/java/util/prefs/Preferences.html

However, you do not have to store all data there, just
- for example - the name of the file oder database with the
actual user data. See also:

»user.home User's home directory«

http://download.java.net/jdk7/docs/api/java/lang/System.html#getProperties()

>Should I be creating a properties file when a user chooses to
>save his settings?

Simple name-value pairs are sufficient for a surprisingly
large area of applications. Actually, every information can
be stored this way.

Other means include databases, XML-files or RDF-files. I am
using my custom format »Unotal«, which is like enriched
S-expressions.

>Are there other ways to do this same thing (besides using the
>windows registry)?

In Java, there does not have to be a »Windows registry«
within the runtime environment at all.

Reply to this Message

Brandon McCombs - 28 Dec 2006 21:51 GMT

>> I wanted to know what the standard practice is for storing user
>> settings.
[quoted text clipped - 28 lines]
> In Java, there does not have to be a »Windows registry«
> within the runtime environment at all.

thanks guys. I'm already looking into the PReferences API and I like it
(haven't implemented any code yet though). thanks again

Reply to this Message

John Ersatznom - 29 Dec 2006 16:41 GMT

> Other means include databases, XML-files or RDF-files. I am
> using my custom format »Unotal«, which is like enriched
> S-expressions.

Tangential: what are S-expressions?

Reply to this Message

Alan Krueger - 30 Dec 2006 02:11 GMT

>> Other means include databases, XML-files or RDF-files. I am
>> using my custom format »Unotal«, which is like enriched
>> S-expressions.
>
> Tangential: what are S-expressions?

http://theory.lcs.mit.edu/~rivest/sexp.txt

Reply to this Message

Ed - 28 Dec 2006 21:41 GMT

Brandon McCombs skrev:

> Of course it takes a lot of work to add in an
> extra parameter to be saved because I have to modify how the data is
> written to and read from the binary file.

Preferences, as already mentioned, are the way to go.

But even if you weren't using Preferences, even if you were writing the
name/value pairs to the File yourself, it's difficult to see why it
should take, "A lot of work," to add a parameter. Are you sure you're
handling your configuration parameters within your program efficiently?
When you add a parameter, you should make three changes to the code
(the details of saving the parameter shouldn't change whether you're
using Preferences or not):

i) The new parameter itself (usually a new class).
ii) The class the instanciates the parameter (even this can be avoided
if the paramter registers itself with a central parameter group).
iii) The user(s) of the parameter.

Specifically, there should be no new code for presenting this new
paramter to the user and allowing him/her to change it. If you're
introducing new presentation code for each new parameter, then
something's wrong. Possibly.

For example, see:
http://www.edmundkirwan.com/servlet/fractal/cs1/frac-cs110.html

.ed

--

www.EdmundKirwan.com - Home of The Fractal Class Composition

Reply to this Message

standard practices for storing user settings

Free Magazines