Notice the parameters -composite:, -interval:, and -pattern:.
Same for the System variable -Dheadless=true.
This means that the pattern mentioned in -composite: will be reloaded every 360 minutes, and stored as stated in the -pattern: parameter.

Monday, December 16, 2013

There are many things to do with the NMEA Data available in the cache, and the console
is just doing a little - obvious - part of them.
In order for the users to implement their own features and ideas, we now provide a "user-exit" mechanism.
The user-exits are to be written in Java, and implement a specific interface named olivsoftdesktop.DesktopUserExitInterface,
and defined as foillow:

A Simple User-exit implementation

To develop your own features, you would need to put - at least - into your classpath:

desktop.jar

And probably, to access the NMEA Data Cache:

nmeaparser.jar

nmeareader.jar

coreutilities

geomutil.jar

Then, write your code, and archive it into a jar-file.
Here is a simple implementation of this interface. This one evaluates the True Wind Speed
every time a sentence is received from the NMEA station, and displays a message if the
TWS is above 10 knots.
See how the NMEAReaderListener is registered.

User-exit runtime

Archive it in a jar-file, and put the jar (along with the ones it may depend on) in one of the following directories

all-user-exits (recommended)

all-libs

all-3rd-party

Mention the name of the user-exit in the command-line parameters, like -ue:myspecial.feature.SuperUserExit.
For the example above, the parameter would be -ue:olivsoftdesktop.sampleue.UserExitSample.

And that's it. This works from the console, as well as from the headless one.

A more complex sample

Here is the scenario:
You have an internet connection on the boat, it is docked or anchored in the harbor.
From wherever you are, you want to know what the wind is like where the boat is.
This user-exit monitors the True Wind Speed (TWS), and send an email when it is above a given threshold.
It looks at the wind speed every X minutes, the X comes from a configuration file (email.properties) that can be edited.

Possibilities are endless. The limit is your imagination.
Combining the two examples above, you can as well gather all the data into a single document (XML, json, etc), and send it through email on
a regular base, so it can be rendered by the receipient.
Etc, etc...