Dynamics Mobile Studio introduced LAYERS concept, which is intended to ease the customization of existing mobile apps.

There are 6 layers defined in the mobile app. Each layer may contain different versions of the same piece of code.

Dynamics Mobile Studio is intended for use by one of the following types of users:

1. Developers/Consultants from Mobile Affairs
2. Developers/Consultants from Mobile Affairs Partners
3. Developers/Consultants/Administrators from the customer side

Each user type has its own specific needs regarding the customization process of the mobile functional module.

Dynamics Mobile Studio introduces a concept for LAYERS in order to address the different user roles and their customization requirements.A LAYER is a virtual concept allowing each ingredient ( piece of code, view, task, resource, etc… ) of a mobile functional module to have several versions within the same functional module.

There is a fixed number of built-in layers within the system and each ingredient can have a separate version within every of the supported layers.

The built-in layers have id, name and purposes:

0) SYSTEM1
Used by Mobile Affairs only. The standard functionality is placed here

1) SYSTEM2
Used by Mobile Affairs only. Patches and quick updates are placed here

2) LOCALIZATION 1
Used by Mobile Affairs to introduce country/region specific customization

3) LOCALIZATION 2
Used by Partners to introduce country/region specific customization

4) VENDOR
Used by Mobile Affairs Partners to introduce specific vertical customization of the mobile module
valid for all(most) of their customers

5) USER
Used by Mobile Affairs Partners and trained customers to introduce customer specific customization

Code Generation

When the mobile app is hit ( e.g. accessed ) from a web browser or downloaded on a mobile device, Dynamics Mobile performs “code generation”.
During the code generation phase in both off-line and on-line mode, the mobile functional module code base is generated from the LAYER with the highest priority. The USER layer has the highest priority and the SYSTEM1 layer has the lowest priority.

For each mobile app ingradient the system is tryig to locate the code version from the highest priority LAYER going down to the lower levels until a version is found. It means that if a specific ingradient is modified on the USER level, the system will take this version. If the ingradient does not contain USER level modifications, the system will lookup at the lower level ( VENDOR ) and so on until a version of the ingradient is found.

Layer modification

The LAYER concept allows:

Each type of user to make specific changes in the code base without affecting the rest

For example partners can create their specific vertical solutions in the VENDOR layer, without affecting the SYSTEM layers. When a new standard version of mobile app is released by Mobile Affairs the new version can be merged in existing partner’s deployments without affecting the functional areas where the partner has made changes. The partner can then test their specific changes for compatibility with the new mobile app’s version.

Partners can create country/region specific customizations using the LOCALIZATION2 layer. The vendors can further customize the localized version of the mobile app using the VENDOR layer.

The USER layer is used by the vendors ( and customer trained staff ) to make changes in the functionality specific for the current customer/deployment.

The following table shows the user types and their (typical) permissions to change the layer:

Distribution files ( exported Dynamics Mobile Studio mobile apps ) created by partner ( from application area with VENDOR license ) will include only LAYERS 3, 4, 5 – the actual LAYERS contained depends on the developer choice during the export process.

Distribution files ( exported Dynamics Mobile Studio modules ) created by end user (from a system with USER license ) will include only LAYERS 5

Distribution files ( exported Dynamics Mobile Studio module ) created by Mobile Affairs will include (typically) LAYERS 0, 1, 2.
Each distribution file created by Mobile Affairs is “escorted” with a description of the contained LAYERS.

During import of a module distribution file within applicaion area, all the LAYERS contained in the file are overriden in the target application area.
All changes made within the LAYERS of the target system will be lost after the import , if the file contains new version of the specific ingradient and LAYER.

Depending on the development license installed in particular application area, the developer is able to open and change all or some of the built-int LAYERs.

Benefits

The LAYER system allows the following:

Mobile Affairs to distribute “standard” module versions (SYSTEM1 layer) without affecting (usually) the vendor/user changes
Mobile Affairs to distribute patches for the “standard” module versions (SYSTEM2 layer) without affecting (usually) the vendor/user changes
Mobile Affairs to distribute localized versions of the standard modules using layer LOCALIZATION1 without affecting the partners changes
Partners to distribute localized versions of the standard modules using layer LOCALIZATION2
Partners to distribute vendor specific vertical cusotmizations(modules) using layer VENDOR
Partners to distribute user specific customizations using layer USER
Users to customize their specific deployments using layer USER
Each deployment can be quickly rollbacked to a layer with a lower priority
Each deployment can be quickly customized to reflect specific needs for particular user or group if users without affecting the standard version.

The developer story

The layer management is done via the Dynamics Mobile Studio and it is a vital part of the Dynamics Mobile Studio Development experience.

The following scenarios regarding the layers are of the developer’s concern:

• Opening a module for design
• Selecting a specific LAYER to work into
• Opening and changing a component – view
• Opening and changing a component – code
• Opening and changing a component – resource
• Opening and changing a component – translation
• Opening and changing a component – task
• Exporting module distribution file
• Importing module distribution file

Opening a module for design

The developer can open a module for design by naigating to the Control Panel/Modules and clicking the DESIGN link next to the module title. The link will open the module in Dynamics Mobile Studio

Selecting a specific LAYER to work into

Dynamics Mobile Studio will always work into specific LAYER. All changes done over the module’s ingradients are done at the currently active LAYER level. It means that the developer must specify the currently active LAYER before making changes to it. All changes will be done within the current LAYER until the LAYER is changed.

When Dynamics Mobile Studio is opened , it automatically opens the highest priority LAYER , where changes has been made within the module. It means that if the developer has changed something in the VENDORs layer in this module, the default LAYER upon module open will be the VENDOR layer. Note that the license in the current applicaion area must allow VENDOR layer changes. Otherwise Dynamics Mobile Studio will fall back and will open the next layer allowed by the license.

The currently active LAYER can be changed from toolbar at the top of the Dynamics Mobile Studio.

When the developer selects a new layer from the toolbar, nothing special is done, until specific component has been changed.
When the developer clicks over a component from the Solution Explorer, the the system will try to load the version of the component from the currenty active LAYER. However if there are no changes for the component in the current layer , the user will see the component content displayed read-only. The developer will be able to click the CHANGE LAYER button at the top of the component editor to begin making changes in the current layer. At this point, the content of the component will copied from the LAYER with the highest priority ( however, lower than the currently active LAYER) and will be placed as a content for the currently active layer.

Example:

The develper is doing changes at the VENDOR layer. He is opening a view from the solution explorer and it turns out that this view does not have changes at the VENDOR layer. The developer will see that the view is dimmed and that there is a button CHANGE LAYER at the top. He will click the button, and the system will go down the LAYER hierarchy to find out the most recent version of the component. Let’s imagane that there is a version for the view a the LOCALIZATION1 layer ( e.g. LOCALIZATION2 does not contain anything for this view) . Then the content from the LOZALIZATION1 layer will be copied at the VENDOR layer and the developer can start modifying the view at the VENDORS layer.

The developer can also use the LAYERs dropdown next to the CHNGE LAYER button to select, which LAYER must be use as a code base , instead of the automatic LAYER content discovery process.

Exporting a module

During the module export process, the developer can select, which LAYERS must be exported. The allowed LAYERS for export depends on the actual license installed.

Systems with VENDOR licenses can export every layer , but can modifiy only layers 3, 4, 5
Systems with USER licenses can export only the USER layer and can modifiy only layer 5

Importing a module

The developer can deploy a mobile module in other Dynamics Mobile application area using the IMPORT function of Dynamics Mboile Studio , after a module is opened. The import process will import all components contained into the module’s distribution file overriding all existing components and their versions at every contained LAYER level.

Versioning

Each component maintains internal version number ( integer value) increased on every change. This internal version number is specific for the LAYER where the change is done. This version can be used by the develers to track changes within specific components during developenet and code merging.

Each module must be associated with a single “complex” version number containing the following:

MAJOR_VERSION.MINOR_VERSION.REVISION

The MAJOR_VERSION is maintaned by the module system vendor ( e.g. Mobile Affairs for the standard modules )
The MINOR_VERSION is maintaned by the module system vendor ( e.g. Mobile Affairs for the standard modules )
The REVISION is maintaned by the vendors/partners ( e.g. partners of Mobile Affairs )

Before uploading a module to production environment, the developer must promote the REVISION up in order to signal the system that there are changes in the functionality regarding the specific module.

Note that Mobile Affairs modules contains the symbol *, instead of specific revision number. This means that the actual revision number assigned by the vendor will be preserved if a Mobile Affairs’ changes are imported over a deployment.