SAP Mobile Platform 3 Software Development Kit version management

Scenario

SAP releases a software development kit (SDK) for its SAP Mobile Platform 3 (SMP3) to enable developers to efficiently create apps. The SDK is not a static product but is actively developed and supported by SAP. This means that a SDK receives constant updates and patches.

Problem

The above screenshot shows that only for SDK SP10 7 patch levels were released, in a little more than 1 month. The installation of a SDK is always done in the same location. Therefore, only one SDK version can be used at a time be a developer. While this assures that only the latest version is going to be used, it creates a problem in regards to maintainability and ongoing development. A new development project may use SP10, while a current one may still depend on SP9. To overcome this, a developer may create local copies of the SDK and manually switch between the different versions, an approach is going to be presented in this document that allows the developer to have different versions of the SDK available.

Solution

The approach consists of using git to manage the individual versions of the SDK. Of course, a different revision control system may be used, but git offers normally a superior handling and speed. The overall process is as followed:

  1. Create an initial version of the SDK.
  2. Add this version to git and tag it correspondently
  3. Install a newer version of the SDK to the same location
  4. Use git to add this version and tag it correspondently
  5. The work with a specific SDK version, the developer checks out the needed version
  6. If necessary, remove/add the Kapsel plugins / libraries to a project
  7. Repeat step 2 to 4 for future versions

Process

Download initial version of the SDK from SAP Market Place: https://support.sap.com/swdc

Path: Sybase products -> SAP Mobile Platform SDK -> SAP MOBILE PLATFORM SDK 3.0 -> Support Packages -> SAP MOBILE PLATFORM SDK 3.0 -> [OS]

Install the initial version of the SDK

Go the the installation folder. Either opt to version the whole installation folder or just a part of the SDK, like Kapsel. The following example will only version Kapsel.

Note: by default, Fiori Mobile Client apps are stored inside the Kapsel SDK folder. As each FMC app adds a few thousands files, it is a good idea to not have these included into the git versioning. Consider using .gitignore for those folders.

Initial commit and tag

  • Initialize the folder: git init


  • Add all content: git add –A –v


  • Commit files: git commit



  • Tag commit: git tag –a SPnPLm –m “SDK SPnPLm”

Updating the SDK

Download a newer version of the SDK and install it. Ensure that KapseSDK is going to be upgrade (which should be the default).

Go the installation folder to add the new files to git.

Note: it is important to know that with git a folder .git is created which stores all the git relevant information. In case this folder is deleted, so will also the files and versions added to git. Normally the SDK installer is only overwriting and adding files and not removing. The .git folder should therefore not be impacted by the SDK installation / upgrade process.

Subsequent commit and tag

  • Add all content: git add –A –v
  • Commit files: git commit
  • Tag commit: git tag –a SPn+1PLm+1 –m “SDK SPn+1PLm+1

Add files

Files that were part of the previous SDK version but not of the current one will be shown as remove.

Commit

Tag version

See available SDK versions

Use a specific version of the SDK

To use a specific version of the SDK, it must first be stored in git and tagged. To use the version, a simple checkout is sufficient to update the whole KapselSDK folder to the specified version. To make use of this version, the Kapsel plugins must be updated in an already used project. For a new project, the usual process of adding a plugin is to be used.

  • List available versions: git tag
  • Checkout version: git checkout

To complete the installation, install the Kapsel dependencies as described in README.md.

Let the world know

Use a specific Cordova version for hybrid app development

Scenario

Cordova is used as the de-facto standard software for creating hybrid mobile apps. To keep up with mobile platforms, a new version of Cordova is released constantly. This creates a certain challenge for mobile app developers that have to not only create new apps, but also have to maintain older versions. Specifically in enterprise environments, it is not always possible to simply update to a new Cordova version. One reason can be an upcoming go-live. You do not want to change your SDK days before a go-live as this increases drastically your testing efforts. For instance, SAP releases a software development kit (SDK) for its SAP Mobile Platform 3 (SMP3) to enable developers to efficiently create apps. The SDK is not a static product but is actively developed and supported by SAP. This means that a SDK receives constant updates and patches. Each SDK SP version comes with a minimum and recommended Cordova version. A developer that has to create new apps and at the same time maintain older versions may come into the situation where it is necessary to have not only different version of a SDK SP installed, but also of the Cordova tool. Given a normal workload, the developer may have to change between the new project and the maintenance several time per day.

Problem

The above scenario creates the following problem for the developer: by default, Cordova is installed via npm globally. With this, only one version of Cordova is available at a given time. For the developer this means that he cannot simply have several versions for each SDK SP and project available. A manual remove of the current version of Cordova and install of the needed version is necessary. As the npm install is globally done, one version of Cordova is activated for all users of the computer.

Solution

The root cause of the problem is how Cordova is installed. Cordova is delivered and maintained via npm. The default way of installing Cordova is to issue the command:

npm –g install cordova[@{version}]

Install locally

npm offers alternatives to the above shown installation option. Without the –g flag, a npm module will be installed into the nodes_module folder of the current path. To install Cordova locally to the project folder, the command is:

npm install cordova[@{version}]

With this, Cordova executable is available at node_modules/cordova/bin/cordova

A cordova –v run against the newly installed version shows that the right version is installed.

To create a Cordova project with that version, this newly installed version must be used and not the globally available version. The command line parameters are not affected by this.

node_modules/cordova/bin/cordova create hello com.sap.hello HelloWorld

To add Cordova platforms or plugins, the Cordova version inside the local nodes_modules folder must be invoked.

node_modules/cordova/bin/cordova platform add android

node_modules/cordova/bin/cordova plugins add cordova-plugin-console

The same rule applies for compilation, build or run of a Cordova app.

node_modules/cordova/bin/cordova compile

Install locally (advanced)

Installing Cordova locally as shown above still means that the Cordova package must be installed before a Cordova/Kapsel project is created. To have several version of Cordova available in that way, several folders must be created, preferably containing a version tag of the installed Cordova. This implies that inside the actual hybrid project, no reference to the needed Cordova version is maintained, despite the SDK SP dependency.

To have the Cordova version tight into the project, any Cordova version can be used to create the project folder structure. Inside the folder the needed Cordova version can be installed locally. That way, the Cordova version is made available inside the project, making it easier to share the project or to onboard new team members. On the contrary, instead of having one single repository for each Cordova version, the executable must be provided for each project.

NPM link

NPM comes with a link tool. This tool links a package globally. This makes a local package globally available. The local package will appear as it was installed using npm install –g <package>. The link tool is handy when the npm package is available via its source code (like GitHub) and is therefore not needed to be installed from the npm repository.

In combination with Cordova, npm link allows to make a checked out version of Cordova globally available. A local available versoin of Cordova downloaded via git can be checked out and activated by npm link. To activate a specific version, this version is checked out via git and then activated by npm link.

The installation procedure is as given by Cordova.

git clone https://git-wip-us.apache.org/repos/asf/cordova-cli.git
cd cordova-cli
npm install
sudo npm link
npm link plugman

To go through each step:

git clone https://git-wip-us.apache.org/repos/asf/cordova-cli.git

npm install

npm link

To check the currently activated version of Cordova: cordova –v


To switch to another version of Crodova, git is to be used. The following example shows how to switch to Cordova 4.0.0 globally. First, get a list of tags from git: git tag

Checkout version 4.0.0.

git checkout 4.0.0

npm install

npm link

The check that version 4.0.0 is now available globally, issue cordova –v from the command line.

To test that Cordova 4.0.0 is now being used, create a new project: cordova create TestSAP com.sap.hello TestSAP

Add android as a platform: cordova platforms add android

Please note that android platform version 3.6.4 is used, and not 4.1.1 as it was with Cordova 5.4.1

Let the world know

Fiori client compile error

Lately I was installing the latest version of the SMP3 SDK SP10 PL3 and with it the Fiori client. While trying to create a new custom Fiori client app, I got an error. Gradle wasn`t able to download a dependency from maven.

Now, you never know for sure if this may now happening because of the new SDK version or because of another error. I checked the maven site and the POM was there, I could even download it via the browser. I use from time to time my own repository manager (artifactory). First I checked if my settings.xml can be blamed. Settings.xml was empty, so all requests done by maven will go directly. But this triggered something in my head. The connection I was using to connect to the internet was not without a proxy. Not a proxy you had to insert into your computer configuration, but it was there. So I switched to LTE via my smartphone and … it worked. Cordova compiled now ran without an error.

Lesson learned: be prepared for strange errors when a proxy is between you and the internet.

Let the world know