Configuration Add-Ons

 

Configuration and Customizing

This chapter explains how to use the Configuration API to read and save framework and application properties.

Introduction

MI offers a so-called Configuration API that allows for generic handling of properties that applications would otherwise store in property files. Central goals of this approach are:

The Configuration API should be the central point of customizing and personalization for all MI client applications.

The configuration of a mobile device can be changed remotely by an administrator using Configuration Add-Ons.

 

Overview on the Configuration API

All framework properties documented in the interface PropertyKeys.

Properties are organized in three different levels with different priority when a property is read:

We differentiate system properties (as installation folder for MI or the runtime (AWT or JSP)) and user-specific properties. User-specific properties can be owned by the framework (as are the user's synchronization settings) or be application-specific.

The Configuration API is represented by the classes and interfaces in package com.sap.ip.me.api.conf. Its central classes and interfaces are:

Class / Interface

Description
Configuration

The Configuration class is the central point of access for reading and writing all properties. It furnishes getter and setter methods with various signatures to allow for reading and writing temporary, custom and default properties.

PropertyKeys The interface PropertyKeys contains all MI configuration parameters as constants. All parameters can be read and written, but some should only be used by the MI framework.

 

The other classes and interfaces contained in this package are not required for accessing properties.

Technically, all properties are stored as plain text files in folder <MI root>/settings/ under the file name <username>.uconfig. Framework properties are stored in <MI root>/settings/MobileEngine.config.

No application-specific properties exist. To differentiate properties for different applications, name spaces (separated by dots) should be used.
MI, for examples, uses the property key MobileEngine.Sync.Language to store the default language.

Reading properties

All properties (independent of their type like temporary, custom or default) are accessed via the property key. With a given property key, the respective get-methods for retrieving string, integers and long property values need to be called.
The property key for system properties are defined in the interface PropertyKeys.

Implemented as a singleton, you first need to get a reference to the instance via Configuration.getInstance() and then call its getter/setter methods.

The following code snippet outlines the complete call cycle for two application properties and one framework property:

Configuration conf  = Configuration.getInstance();

String companyHome  = conf.getProperty('MyApplication.HomePage');
int    maxTempFiles = conf.getInt('MyApplication.MaxTemporaryFiles',10);
String userName     = conf.getProperty(PropertyKeys.SYNCSETTINGS_LONGUSERNAME);

Saving properties

Properties are stored via the respective set-methods for their lifetime (temporary or custom property) and value type (string, integer or long). In any case, the property key and the property value need to be furnished. Custom properties are saved to the property file directly, that means that no 'save'-method needs to be called for their persistence.

As for reading properties, an instance to the singleton Configuration needs to be obtained first before saving the properties.

The following code snippet shows the full call cycle:

Configuration conf  = Configuration.getInstance();

conf.setProperty('MyApplication.HomePage','http://www.sap.com/');
conf.setInt('MyApplication.MaxTemporaryFiles',100);
conf.setTemporary('MyApplication.menuDisabled', 'X');
conf.setProperty('MyApplication.OrderEntrySave.Enhancement','com.myCompany.app.orderSave')
The framework parameters described in interface PropertyKeys cannot be changed by applications.

 

Technical notes