Upgrade Android Devices

The Digitise Apps software is generally supplied as a download from our web site. Therefore, before you can upgrade to the latest version of Digitise Apps, you will need to download it from the web site. You, or someone in your organisation, should have received an email, when the Software Licence was purchased or renewed, providing full details of how to download and unzip the software.

The Product Download includes the install file for a version of the standard Digitise Apps Client for Android devices, under its Client Installs\Android folder. If you have already upgraded a development PC or App Server machine, you can also usually find a copy of this Client install file on the upgraded machine, in the Installs\Android folder below the installed Digitise Apps software's root folder. Either of these versions of the install file can be used to upgrade existing Clients to the latest Digitise Apps Clients. You can also generate an updated pre-configured version of the Digitise Apps Client and/or Standalone App versions from within the latest App Studio supplied with the Digitise Apps software.

You can download and upgrade the latest version of a standard or pre-configured Client or an upgraded Standalone App to Android devices in the same way as you would install a new version, see Install Clients and Standalone Apps on Android Devices.

Existing Digitise apps and MX apps for the Android Platform will generally work with the latest Digitise Apps Clients and App Server without any modification. This means that after upgrading, you should be able to continue to run existing versions of a Client, together with it's existing apps, and existing Standalone Apps in conjunction with the latest version of the App Server.

You may also be able to do the reverse, i.e. to run apps created with the latest version of Digitise Apps with earlier versions of the App Server, providing that the apps don't contain newer features, introduced since the version of the App Server you are using, that are incompatible with your version of App Server. In addition, if you have an app which was created using MX or Digitise Apps from v10 onwards, you may also be able to download and run that app using a different version of the Client than that supplied with the product version in which the app was created, e.g., to run a v10.9 Digitise app in a v10.4 MX Client, providing, once again, that the app doesn't include any features which are backwardly incompatible with the version of the Client you are using.

If you are upgrading from a version of Digitise Apps' predecessor, MX, please note the following potential issues when running pre-existing MX apps with a Digitise Apps Client:

• Control positioning now uses density independent pixels (DIP) on Android devices. This means Control Properties, such as left, right, top and bottom, now use DIP values rather than pixel values and the GetSystemInfo Scripting Method will return the screen height and width values in DIPs.

  This may affect the operation of existing apps when upgrading to Digitise Apps and so an option is provided to disable this change, allowing your app to work as it did before the upgrade.

  To disable this change, you need to edit your app in the latest App Studio and add the following comment into the Application OnLoad event's script:

  ' #DISABLE ANDROID_SCREEN_INFO_DPI_FIX

  For more information see Control Properties or GetSystemInfo.

• MX v10 included some changes to the operation of Combo Box Controls when using SetControlValue in order to make the operation of these Controls consistent across different Platforms. Differences in operation on Android devices have been retained to maintain backwards compatibility. However, if you are upgrading from MX v8 or earlier and use Combo Boxes with SetControlValue in any of your apps, we recommend that you test those apps after upgrading and check that your Combo Boxes work as expected.

• From MX v10, the GetSystemInfo Scripting Method now returns the correct device ID on Android Devices instead of an empty string when using the “Device.PIN” parameter. If you have any existing apps on Android devices which use this method to check whether the app is running on an Android device, you will need to edit the app to take account of the new return value.

• If you are upgrading from MX v7.0 or earlier and you have used images within Ink Picture Controls, at runtime these will now be displayed at their actual size whereas previously they were auto-sized to fit the size of the Control. If you have any apps which have images displayed in Ink Picture Controls, you will need to check the display of the image after upgrading and adjust the app if necessary.

Read the information under Edit Existing apps After Upgrading below for further details about compatibility issues which might arise after upgrading.

As always, when upgrading, we strongly advise you to test all apps in a test environment before you upgrade live systems and users, especially if you want to mix and match components from different versions of the product.

After upgrading your development PCs to the latest version of Digitise Apps, existing Digitise and MX apps can be edited in the latest App Studio as before. Simply open the app in App Studio in the usual way.

Before you do this, however, you need to be aware of the following points:

• If you make changes to an existing app which was originally sideloaded onto devices and you want to upgrade it to a new version via the Google Play Store, you will need to uninstall the original app from your devices before downloading it from the app store, otherwise you may end up with two versions of the app on the devices.

• If you are upgrading MX software from version 8.0 or earlier there are some changes which can be implemented after installing the upgrade by editing various Properties in App Studio:

  • If you are upgrading from MX v7.0 or earlier, a later change could inadvertently affect the way numbers are dealt with in Data Sources when uploading data to a remote data source. This could result in numbers which were previously transferred as integers becoming floating point numbers. If this problem occurs after upgrading, you can use the SQL Type Override Property for affected data items to change the data type used to store the data in the local database on the device. This Property can be accessed by loading the affected app’s Project in App Studio, displaying the Data Sources Pane and selecting an affected data item. The Properties for the selected item will be displayed in the Properties Pane. Locate the SQL Type Override Property and try setting it to an integer data type.

  • v10 introduced support for Null values in variables and as parameters to various Methods. This means that Null (case-insensitive) is now a reserved word and cannot be used for variable or Function names.

    A Property is provided in the Project Properties which allows you to retain the existing way of working in your legacy Projects: Enable Null Script Variables. By default, this Property will be set to False for legacy Projects which means that ‘Null’ will not be treated as a reserved word.

    If you want to change your Project to use Nulls, simply change this Property to True.

    In this case, if you have any variables etc. named ‘Null’, when your Scripts are verified the Syntax Checker will list them as errors in the Script Errors Pane and you will need to locate and rename any such items.

    For new Projects, the default value for this Property is True.

  • The Date and Time Methods, e.g. DateAdd, DateDiff, Day, Hour etc., have been updated to provide consistency across Platforms. Most Methods are now available on the Android Platform and work in the same way on all supported Platforms.

    A new Property has been added to the Project properties to allow you to retain the previous method of working for these Methods: Use Cross-Platform Date Functions. By default, this Property will be set to False for legacy Projects which means that date functions will continue to work as they did.

    If you want to change your Project to use the new date Methods, simply change this Property to True. For new Projects, the default value for this Property is True.

  • MX versions later than v8.0 have a Property allowing you to stop a Timer Control from running when the user moves off the form it is on. The new option is a Property of the Timer Control called Active on Parent Form Only. By default, this Property will be set to False for legacy Projects which means that Timers will continue to work as they did before and continue running when the form they are on is hidden. If you want to stop the Timer when the form is not the current form, set this Property to True. If set to True, the Timer will stop when you move off the form and continue if the form is redisplayed.

• If you are upgrading MX software from a version of MX prior to v6.1, note the following:

  • MX v6.1 introduced support for floating point division using the ‘/’ operator. Previously ‘/’ performed integer division only and so earlier apps may need to be modified to account for floating point numbers or to retain the previous method of working. To do this, load the app within App Studio and a message will be displayed asking if you want to retain the integer division functionality or change to floating point.

    Choose Yes to move to floating point division or No to retain the previous method of working. You can also change between the two methods using the Floating Point Division Property in the Project Properties.

    If you change to using floating point division, anywhere you have used the ‘/’ operator will now perform floating point division and you may need to edit your Scripts to allow for different results being returned by the operation. You can also modify your existing Scripts to retain integer division by editing the relevant Scripts and replacing the ‘/’ operator with the newer integer division operator: ‘\’, which will return an integer result as before.