I am happy to announce that a new release of the Mobile Development Kit (MDK) extension for Visual Studio (VS) Code is available for download on the SAP Marketplace and the Visual Studio Marketplace. You can also view the changelog on Visual Studio Marketplace. Version 1.3 was released November 2018 and Version 1.4 is released at the end January 2019.
Mobile development kit (MDK) is a feature of SAP Cloud Platform Mobile Services. If this is your first introduction to the mobile development kit, I suggest you first review the Learning Map which provides overview topics, blogs, videos, and tutorials.
Here is a list of the new features in 1.3 and 1.4.
The MDK extension for VS Code is now also available for Windows. All the features available in Visual Studio Code for Mac OS, such as new MDK commands, MDK language features (auto-completion, validation, go to definition, etc.), bundling and debugging, are also now available on Windows. Developers will have the same experience regardless of whether they are on Mac or Windows OS.
Above is a screenshot for launching and debugging a MDK app in VS Code on Windows with an Android emulator.
Developers can now create new MDK applications from scratch in VS Code. A new option has been added to the VS Code Command Palette called MDK: New Application.
High level steps to create a new MDK application:
The following language features are supported for rules (.js files) and metadata (.json) files. For rule files, these features apply to the eight client APIs: localizeText, formatNumber, formatCurrency, formatPercentage, formatScientific, formatDate, formatDatetime, formatTime.
Auto-completion
Input a single quote, a double quote, or a comma and the appropriate suggestion list will be provided. For .js files, you can also replace the value of a parameter by putting the cursor within it and manually invoking auto-completion.
Validation
If a localization key in a metadata file does not exist, an error message will appear when the developer opens or edits the file. Example: "Cannot find the i18n key" will be shown in the PROBLEMS panel.
If a localization key in a .json metadata file exists but does not have enough parameters, an error message like "Expected xxx arguments, but got yyy." will be shown in the PROBLEMS panel.
Go to definition
Put the cursor within a valid localization key, then press the "Go to Definition" context menu item, the corresponding i18n property file will be opened and the cursor is located at the beginning of the localization key.
Code action
If the referenced localization key does not exist when you put the cursor within it, a light bulb will appear at the beginning of the line the cursor belongs to. Clicking the light bulb will pop up a context menu with only one menu item "MDK: Create i18n entry for key". The default i18n property file will be opened and the developer can directly enter the new value for the localization key.
Signature help
Input a left round bracket or a comma in an i18n indicator or the eight client APIs mentioned above, the corresponding signature will be shown.
Below is a sample screenshot for the i18n indicator "$(DT,)".
Below is a sample screenshot for the client API formatDate.
Note: An i18n indicator has the format of "$()" and corresponds to one of the eight client APIs.
Previously, when developers launched the debugger, it fails to get started when no bundle target is already available for the working MDK application. Developers then have to trigger the bundle task manually to continue with debugging.
Starting with the 1.3 release of the MDK extension for VSCode, the integration of debugger and bundle task has been improved. The bundle task is triggered automatically, if necessary, when launching the debugger. It simplifies the whole debug process by eliminating the manual bundle in most cases.
Target paths are strings which are interpreted at runtime. A target path is composed of segments which are resolved one after the other, with the result of one being used for the evaluation of the next. Each of these results (or "contexts") has two pieces of information: a data binding and, if appropriate, an associated UI element. Target paths are often used in metadata to retrieve a data binding that already exists somewhere in the app but may also be used in rules to access data bindings or UI elements.
Basically it is a flexible way of accessing state and data in your app. For example, lets you refer to things like UI elements, data bindings and action results.
The MDK extension for VS Code supports Target Paths for UI elements. Both simple target path and dynamic target path are supported.
To support target path for data bindings, we provide auto-completion and validation for them. There are 2 kinds of target path for data binding: #Property:propertyName and {propertyName}
#Property: propertyName – both simple target path and dynamic target paths are supported.
{propertyName}
For some OData-related actions, the MDK extension for VSCode can auto-complete the Properties property by parsing the content of the metadata XML file of the service specified in action. An example is the .data.xml file located under Services folder.
The 1.4 release of the MDK extension provides validation for _Name value. The validation support covers 2 kinds of _Name types in MDK – UI element names and Action Result names.
UI Element Names
Action Result Name
The MDK extension for VS Code now supports debugging on iOS devices. When you build your own MDK client using the SDK, you need to specify whether your target is a device or simulator. It cannot be built for both. The MDK extension for VS Code automatically detects whether a MDK client is built for device or simulator. The extension looks in the appRoot in launch.json or mdk.debugAppRoot in user settings.json.
The MDK extension for VS Code will start-up the code sign process if your client is built for a device.
You must sign your app to assure that you are from a known source if you want to deploy your app on a device.
There are two ways to sign it: team ID and provisioning profiles.
Both approaches require the developer has an Apple developer account. The MDK extension leverages the NativeScript command line to trigger the real NativeScript debugger.
For debugging on device, you can use 'Launch on iOS' or 'Attach on iOS' from VS Code. The extension will need a team ID or a provisioning profile file to sign the MDK client before deploying on device.
The MDK extension can get all team IDs and provisioning profile files you ever downloaded locally using XCode and your Apple ID. You can also use a new added command 'Import iOS provision profile' to import a provisioning profile file downloaded from the Apple Developer portal if you don't want to download it via XCode. The command 'Import iOS provision profile' will not only copy the provisioning profile file to a specific location, but also keep its name in user settings. The provisioning profile name will now appear in the list of provisioning profile files.
The MDK extension will provide a list all team IDs and all provisioning profile names when you try to debug a MDK client on connected device. After selecting a team ID or a provisioning profile name, you can launch and debug the MDK client on device.
As part of the 1.4 release, the MDK extension for VS Code can debug your MDK apps that have been deployed to Mobile Services from SAP Web IDE. This feature is called Live Mode (Attach) Debugging. The feature works along with new releases of the MDK Editor (3.0SP2) and MDK SDK Client (3.0.3). Each of your MDK parts will need to be on the version listed above or higher.
Note: This feature currently works for iOS devices only. Android support will be in a future release.
Note: To keep the source codes synchronized between WebIDE and VSCode more efficiently, a git repository is recommended.
Check out the latest versions of the MDK extension for Visual Studio Code. I'd love to head back how you are using the extension and feedback for other features you would like to see in the future.
Mobile development kit (MDK) is a feature of SAP Cloud Platform Mobile Services. If this is your first introduction to the mobile development kit, I suggest you first review the Learning Map which provides overview topics, blogs, videos, and tutorials.
Here is a list of the new features in 1.3 and 1.4.
- V1.3
- MDK extension for VS Code on Windows OS
- Create New MDK Applications
- i18N support in rule and metadata files
- Elimination of manual bundling
- V1.4
- Better support for target paths
- Validation of _Name type
- Debug on device
- Debug MDK apps deployed to Mobile Services
MDK extension for VS Code on Windows
The MDK extension for VS Code is now also available for Windows. All the features available in Visual Studio Code for Mac OS, such as new MDK commands, MDK language features (auto-completion, validation, go to definition, etc.), bundling and debugging, are also now available on Windows. Developers will have the same experience regardless of whether they are on Mac or Windows OS.
Above is a screenshot for launching and debugging a MDK app in VS Code on Windows with an Android emulator.
Create new MDK applications
Developers can now create new MDK applications from scratch in VS Code. A new option has been added to the VS Code Command Palette called MDK: New Application.
High level steps to create a new MDK application:
- Choose the 'MDK: New Application' command from VS Code Command Palette.
- Select the target folder for the newly created application.
- Specify the new application name. The default is 'MDKApplication'.
- A new empty MDK application will be created based on the MDK Empty Application Template.
i18n support in rule and metadata files
The following language features are supported for rules (.js files) and metadata (.json) files. For rule files, these features apply to the eight client APIs: localizeText, formatNumber, formatCurrency, formatPercentage, formatScientific, formatDate, formatDatetime, formatTime.
- Auto completion
- Validation
- Go to definition
- Code action
- Signature help
Auto-completion
Input a single quote, a double quote, or a comma and the appropriate suggestion list will be provided. For .js files, you can also replace the value of a parameter by putting the cursor within it and manually invoking auto-completion.
Validation
If a localization key in a metadata file does not exist, an error message will appear when the developer opens or edits the file. Example: "Cannot find the i18n key" will be shown in the PROBLEMS panel.
If a localization key in a .json metadata file exists but does not have enough parameters, an error message like "Expected xxx arguments, but got yyy." will be shown in the PROBLEMS panel.
Go to definition
Put the cursor within a valid localization key, then press the "Go to Definition" context menu item, the corresponding i18n property file will be opened and the cursor is located at the beginning of the localization key.
Code action
If the referenced localization key does not exist when you put the cursor within it, a light bulb will appear at the beginning of the line the cursor belongs to. Clicking the light bulb will pop up a context menu with only one menu item "MDK: Create i18n entry for key". The default i18n property file will be opened and the developer can directly enter the new value for the localization key.
Signature help
Input a left round bracket or a comma in an i18n indicator or the eight client APIs mentioned above, the corresponding signature will be shown.
Below is a sample screenshot for the i18n indicator "$(DT,)".
Below is a sample screenshot for the client API formatDate.
Note: An i18n indicator has the format of "$()" and corresponds to one of the eight client APIs.
Trigger bundle directly if bundle.js is missing or expired
Previously, when developers launched the debugger, it fails to get started when no bundle target is already available for the working MDK application. Developers then have to trigger the bundle task manually to continue with debugging.
Starting with the 1.3 release of the MDK extension for VSCode, the integration of debugger and bundle task has been improved. The bundle task is triggered automatically, if necessary, when launching the debugger. It simplifies the whole debug process by eliminating the manual bundle in most cases.
Better support for target paths
Target paths are strings which are interpreted at runtime. A target path is composed of segments which are resolved one after the other, with the result of one being used for the evaluation of the next. Each of these results (or "contexts") has two pieces of information: a data binding and, if appropriate, an associated UI element. Target paths are often used in metadata to retrieve a data binding that already exists somewhere in the app but may also be used in rules to access data bindings or UI elements.
Basically it is a flexible way of accessing state and data in your app. For example, lets you refer to things like UI elements, data bindings and action results.
Target paths: UI Elements
The MDK extension for VS Code supports Target Paths for UI elements. Both simple target path and dynamic target path are supported.
- auto-completion is supported for both json metadata files and js rule files.
- validation
- This feature applies only to json metadata files.
- An error message will be shown in the PROBLEMS panel if a target path is invalid. This may happen due to a wrong segment name, a missing parameter, an invalid parameter, or wrong combination of segments and so on.
Target paths: data bindings
To support target path for data bindings, we provide auto-completion and validation for them. There are 2 kinds of target path for data binding: #Property:propertyName and {propertyName}
#Property: propertyName – both simple target path and dynamic target paths are supported.
{propertyName}
For some OData-related actions, the MDK extension for VSCode can auto-complete the Properties property by parsing the content of the metadata XML file of the service specified in action. An example is the .data.xml file located under Services folder.
Validation of the _Name type in MDK objects
The 1.4 release of the MDK extension provides validation for _Name value. The validation support covers 2 kinds of _Name types in MDK – UI element names and Action Result names.
UI Element Names
- Page Name checking:
- Empty value: mark as error
- Invalid syntax check: mark as error (example: Name has a space in it)
- Unique check in one application scope: mark as warning, instead of error. Some duplicated are okay, but the tool will make the developer aware of a duplicate name.
- Control Name checking:
- Empty check: mark as error
- Invalid syntax check: mark as error (example: Name has a space in it)
- Unique check in one-page scope: mark as error
Action Result Name
- Empty check: mark as error
- Invalid syntax check: mark as error (example: Name has a space in it)
Support for debugging on device
The MDK extension for VS Code now supports debugging on iOS devices. When you build your own MDK client using the SDK, you need to specify whether your target is a device or simulator. It cannot be built for both. The MDK extension for VS Code automatically detects whether a MDK client is built for device or simulator. The extension looks in the appRoot in launch.json or mdk.debugAppRoot in user settings.json.
The MDK extension for VS Code will start-up the code sign process if your client is built for a device.
You must sign your app to assure that you are from a known source if you want to deploy your app on a device.
There are two ways to sign it: team ID and provisioning profiles.
- iOS Team id: MDK extension collects all the existing iOS team ids dynamically based on the local environment.
- iOS provisioning profile: developers use their own profiles to sign the app and do the debugging.
Both approaches require the developer has an Apple developer account. The MDK extension leverages the NativeScript command line to trigger the real NativeScript debugger.
For debugging on device, you can use 'Launch on iOS' or 'Attach on iOS' from VS Code. The extension will need a team ID or a provisioning profile file to sign the MDK client before deploying on device.
The MDK extension can get all team IDs and provisioning profile files you ever downloaded locally using XCode and your Apple ID. You can also use a new added command 'Import iOS provision profile' to import a provisioning profile file downloaded from the Apple Developer portal if you don't want to download it via XCode. The command 'Import iOS provision profile' will not only copy the provisioning profile file to a specific location, but also keep its name in user settings. The provisioning profile name will now appear in the list of provisioning profile files.
The MDK extension will provide a list all team IDs and all provisioning profile names when you try to debug a MDK client on connected device. After selecting a team ID or a provisioning profile name, you can launch and debug the MDK client on device.
Debugging MDK apps deployed via Mobile Services
As part of the 1.4 release, the MDK extension for VS Code can debug your MDK apps that have been deployed to Mobile Services from SAP Web IDE. This feature is called Live Mode (Attach) Debugging. The feature works along with new releases of the MDK Editor (3.0SP2) and MDK SDK Client (3.0.3). Each of your MDK parts will need to be on the version listed above or higher.
Note: This feature currently works for iOS devices only. Android support will be in a future release.
- Web IDE deploys the MDK application with new option 'Include source map file for debugging' enabled to CPms. This is a new deployment option available in the MDK Editor 3.0SP2.
- MDK SDK Client: launch it and update the latest MDK app from Mobile Services.
- VSCode: open the same MDK application that was deployed to Mobile Services from SAP Web IDE. Trigger debugger with 'Attach' config, instead of the 'Launch' config, as the bundle files in live mode are not managed locally. Developers can then set breakpoints in rule files and do the debugging operations as usual.
Note: To keep the source codes synchronized between WebIDE and VSCode more efficiently, a git repository is recommended.
Check out the latest versions of the MDK extension for Visual Studio Code. I'd love to head back how you are using the extension and feedback for other features you would like to see in the future.
- SAP Managed Tags:
1 Comment
