| Go to |
|---|
| CL2 |
| UIx |
| HIIT |
The logger program has a lot of functionality, and it necessarily requires some site and user specific configuration. Otherwise it aims to just run and run without much interaction with the outside world, and hence here our focus is primarily on explaining how to do the configuring.
The source code for the logger program can be found in the daemon directory.
The compile time configuration management is largely handled by a custom configuration specification system, in which each build variant has a unique name, and is described in its own file. See the variants directory. Any configuration options shared across variants are given in the base.ss file, and there are a number of .var.ss files, each of which describe a particular, concrete build variant. To do a build with a given unique combination of build parameters, it is suggested that your write a variant specification file for that build (if one does not already exist), and then invoke
make config VARIANT_NAME=your_variant_name
Unless otherwise indicated, any compile-time configuration parameters are specified via this variant specification system.
The logger can—for some configurations—be built with or without a GUI. We refer to GUI-less builds as "daemon" builds and GUI-ful builds as "application" builds.
For daemon builds, define the binary-type configuration parameter as daemon. For application builds, define it as application.
For Linux, the logger is always built as a daemon, as no GUI has been implemented for Linux.
Symbian builds can be either "headless" or with a primitive GUI. The latter have an icon in the application menu, and will also appear in the task list. These facilities, along with the primitive GUI, makes it convenient to launch and exit the logger, and to see when it is running, but it can be intrusive in trials. Hence one may want to deploy a daemon build in trials in which the logger is to run on the background, with minimal intrusiveness.
The GUI variant also demonstrates how CL2 can be embedded in a native S60 application, so that logging only occurs when a particular application is running.
There are two variant implementations of the "keypress" sensor. You can choose which one to use by setting the have-anim.attr configuration parameter appropriately. The non-anim variant may cause problems, as there may be other processes running on the phone that compete for the same key events; the situation varies between different phone models, and possibly different locales with different input methods. The non-anim variant is known to cause problems with the N95 slider events, for instance, if attempting to observe for the relevant "key" events; as a result, the non-anim variant has been configured to observe only some of the most common keys (such as the number keys). The anim variant should be more robust, and should capture just about all key events, but for building and running, it requires the "keyevents" component.
If you set have-anim.attr to a true value, the logger will fail to run unless you have the Jaiku "keyevents" library installed on the target device.
The build tools required for building this component from "master" source files include GNU Make, Ruby, PLT Scheme, fastdep, Ragel, Graphviz and Doxygen, in addition to your usual (platform-specific) toolchain for building C and C++ applications.
On Debian-based systems one might install some of the prerequisites with:
aptitude install make ruby plt-scheme fastdep ragel graphviz doxygen g++ libglib-dev sqlite3-dev libev-dev
The Symbian builds depend on a number of libraries; SDK plugins for these are required, and the libraries must also be installed to the target device. These dependencies include at least PIPS and GLib, but really, you're best off installing all of Open C/C++. Note that some phones have Open C built in. Note also that older versions of Open C are quite buggy, so preferably choose a more recent version (at least v1.6). Many of the provided build configurations also depend on Qt.
The "profile" sensor requires an SDK plugin for building for S60 v3.0, and this is available from Forum Nokia. For v3.1-up no such plugin is required, as an API for getting profile change events is included in the SDKs as standard.
If you wish to enable the "gps" sensor, you must grant the Location capability to the executable. The "cellid" sensor in turn requires the ReadDeviceData capability. The anim-variant of the "keypress" sensor requires the ProtServ capability, although I guess this requirement could be lifted by editing the keyevents component code. The S60 v3.0 version of "profile" sensor implementation appears to require some capability that is not self-signable, but the documentation of the profile API does not say what.
Naturally, if you grant certain capabilities to an executable, you must also be able to certify those capabilities, unless you are using hacked phones, that is.
The log upload default configuration is specified at compile time by setting the iap-id-expr.attr, upload-url.attr, username.attr, and upload-time-expr.attr values. The iap-id-expr.attr value is a Lua expression evaluating to the numeric ID of the access point to use (a trivial Python script can list all the alternatives, see list_iaps.py); upload-url.attr is a Lua expression evaluating to the URL to post to; username.attr is used in the filename of the uploaded file to possibly identify the originator; and upload-time-expr.attr specifies how frequently to do uploads (see the file ``test_moment_parser.c` in the time-spec component for examples of the language you can use).
The compiled in upload-url.attr and username.attr can be overridden using a configuration file; see sample-config.txt (in the source code) for an example what the file should contain.
iap-id-expr.attr and upload-time-expr.attr can be overridden at runtime via the Launcher program, or more generally by making a request via the CL2 client library.