Migrate from 1.3

This page lists the key points to pay attention to when migrating existing code from iink SDK 1.3 to the new iink SDK 1.4.

Android evolutions

The iink 1.4 Android libraries and examples depend on AndroidX. If your application is based on previous Android compatibility libraries, you must migrate to AndroidX.

Rendering evolutions

The rendering evolutions increase the renderer speed. The legacy implementation is still compatible with the new rendering APIs and image rendering. But to benefit from the latest rendering improvements, here is how to proceed.

Image rendering within Text Document

In previous iink versions, rendering an image within a “Text Document” part required to extract that object to a temporary directory before calling the ICanvas drawObject method. In iink 1.4, it is no more required to extract the image. The url provided to the ICanvas drawObject directly points to the image file that needs to be rendered.

  • If you migrate to iink 1.4 and have been using our reference implementation, we have made the ImageLoader and Canvas corresponding changes. So, you should update your application with our new reference implementation.

  • If you have implemented your own rendering, you might refresh your code according to the ImageLoader and Canvas reference implementation.

New rendering APIs ICanvas2 and IRenderTarget2

Check the rendering page to learn why you should use them and how to do so.

Javascript library change

The iink 1.4 Web brings some refactoring into its Javascript library. First, for improved SDK naming and version alignments, myScriptJS has been renamed to iinkJS. Your legacy MyScriptJS client will still work with the 1.4 MyScript iink Cloud without any changes from your side. But if you want your client to benefit from the latest iinkJS, here are the steps that you should go through when performing iinkJS migration:

Property prefix renaming

For product coherency, the configuration prefix of the general iink parameters has moved from recognitionParams.v4 to recognitionParams.iink. So, when upgrading your client application to iinkJS 1.4, you should update the prefix name of the relevant properties. For details on impacted properties, check the related iinkJS configuration section

Callbacks conversion to Promises

In iinkJS callbacks have been converted to Promises: some methods now return a Promise instead of having a callback argument. An important point to note, is that when the status of the Promise changes, the result from the successful path shows up in the .then() method. The error scenario goes into the .catch() one.

So, when upgrading your client application to iinkJS 1.4, depending on your use of the library, you might need to perform some code update. If you are using the ready to use examples, we did the job. If you wrote your own code, you should change the corresponding method calls into your application.

For instance, a legacy call to the _export method on the Recognizer:

// Triggering the recognition
      iinkRecognizer.export_(recognizerContext, model, recognitionCallback);

might become:

// Triggering the recognition
      iinkRecognizer.export_(recognizerContext, model)
        .then((values) => {
          values.forEach((value) => {
            recognitionCallback(undefined, value);
          });
        })
        .catch(err => recognitionCallback(err, undefined));

Web components

iinkJS grants you high integration flexibility by letting you choose your favorite framework or components. For this reason, we have decided to focus on iinkJS and to discontinue our ready-to-use Web components.

Like for MyScriptJS, your legacy client based on Web components will keep on running with the 1.4 MyScript iink Cloud. But if you want to migrate your client to iink 1.4, you will have to write your own Web component. We have built an example you can draw on. It relies on iinkJS and this page illustrates it.

We use cookies to ensure that we give you the best experience on our website Read the privacy policy