You can use the Device Repository editor to edit identification patterns and policy values for any repositories imported into your project. You can edit policy values, and add custom policies to the repository. You can also add custom devices to the repository. The editor contains four pages.
You can use the Device Repository editor to edit identification patterns and policy values for any repositories imported into your project. You can edit policy values, and add custom policies to the repository. You can also add custom devices to the repository. The editor contains four pages.
The Devices section on the Overview page contains a tree view of the devices available in the repository. The structure of the tree reflects the fallback hierarchy of the devices. You can expand the tree to make a single device selection. You can also open an Outline view on the device tree and use it to make selections on any of the pages.
The Delete button is disabled unless a custom device is selected.
If any errors are associated with a device, MCS displays an error decoration on the icon and a validation issue decoration on the icon of any fallback devices.
At runtime, MCS uses identification patterns to identify an unknown device. The patterns are regular expressions that are matched against the device headers. These patterns are contained in an XML file. The Primary and secondary patterns sections provide an interface to add, change the order, or remove patterns, or to restore the default patterns added in the latest repository update.
If you have access to the GSM Association Type Allocation Codes (TAC), formerly known as Type Approval Codes, you can add one or more codes for individual devices on the Overview page.
The TAC forms the initial characters of the International Mobile Equipment Identity (IMEI) number. Because the codes can only match a limited number of IMEIs, popular handset models can often have many codes assigned to them.
The codes can be used in the MCS Device Repository API to retrieve device information.
You can use the Structure page to view the attributes of policies in standard repository categories. You can also add, edit, or remove policies in the Custom category.
The New Policy wizard and the Policy Definition section provide the controls to define a policy; the name, type, available values, and associated meta-information that combine to make a device repository policy.
The Master Value section provides a shortcut to define the value of the policy for the Master device. The available controls are dependent upon the composition and type of the policy.
The CC/PP section provides the means to define the CC/PP vocabulary to which the policy belongs. UAProf is currently the only supported vocabulary.
The Policies page provides the means to define the policy values for the currently selected device. Each page represents a category of policies. The behavior of each of the pages is identical; they just contain different policies.
MCS displays the policies in alphabetical order of the label in the policy definition. For each policy you can determine whether the current device provides its own value for the policy or if it inherits the value from the nearest ancestor in the fallback hierarchy that provides a value. You can also restore the default value.
MCS may choose to ignore inherited values in some cases, i.e. the value of a policy displayed by the Mobile Portal Toolkit Device Editor may be different than the value used by MCS in runtime. For example, some x-css.* policies are effectively inherited only if the child and the parent/ancestor devices have the same CSS versions set.
The Information page contains version and revision information.