feat(ios): add keyman-version to package-version check

[mcdurdin]

For Keyman for iOS, add the new keyman-version parameter to the api.keyman.com/package-version call so that updates to packages that are not supported on the current version of Keyman will not be offered. This supports the scenario where an updated keyboard or lexical model depends on a newer version of Keyman. Note that an older version of the keyboard or lexical model package will not be offered (the user can still download and install an older version manually, but generally, the recommended solution is to upgrade Keyman; there would be significant cost to add support for querying and installation of older version keyboards on the server side, for limited benefit).

Also change order of handling for response so that error responses are recognized even if non-error fields are present. (The current api endpoint, before keymanapp/api.keyman.com#325 lands, can return kmp and version fields even when an error field was present, and the iOS code would see that as a valid response for upgrade, when it shouldn't. The keymanapp/api.keyman.com#325 change ensures that the additional fields are not set if there is an error field.)

Relates-to: keymanapp/api.keyman.com#325

User Testing

• TEST_UPGRADE: Install an older version of a keyboard and lexical model from downloads.keyman.com, and then check for updates, and verify that the packages are updated successfully.

• TEST_MISSING_KEYBOARD: Create a keyboard package with an id that is not on Keyman Cloud, and install it. Check for updates and verify that the app functions correctly and does not offer updates for the keyboard.

• TEST_MISSING_MODEL: Create a model package with an id that is not on Keyman Cloud, and install it. Check for updates and verify that the app functions correctly and does not offer updates for the keyboard.

(It is not currently possible to test the scenario where a keyboard/model requires a newer Keyman version in the app, but the outcome should be identical to the missing keyboard/model outcome.)

[keymanapp-test-bot]

User Test Results

Test specification and instructions

• ⬜ TEST_UPGRADE (OPEN)
• ⬜ TEST_MISSING_KEYBOARD (OPEN)
• ⬜ TEST_MISSING_MODEL (OPEN)

Results Template

# Test Results

* **TEST_UPGRADE (OPEN):** notes
* **TEST_MISSING_KEYBOARD (OPEN):** notes
* **TEST_MISSING_MODEL (OPEN):** notes

Test Artifacts

• iOS
  • Keyman for iOS (simulator image)
  • FirstVoices Keyboards for iOS (simulator image)
  • FirstVoices Keyboards for iOS (simulator image) (old PRs)
  • Keyman for iOS (simulator image) (old PRs)
  • TestFlight internal PR build version - 19.0.248 (0.16138.16012)

[mcdurdin]

Check for error results first.

The package-version api could in the past return 'error' values alongside 'kmp' and 'version' properties for some scenarios, e.g. https://api.keyman.com/package-version?platform=ioskeyboard=enhlao:

{
    "keyboards": {
        "enhlao": {
            "version": "1.1",
            "error": "not available for platform",
            "kmp": "https://keyman.com/go/package/download/keyboard/enhlao?version=1.1&update=1"
        }
    }
}

Note that after keymanapp/api.keyman.com#325 merges, it will instead return:

{
    "keyboards": {
        "enhlao": {
            "error": "Not available for platform ios"
        }
    }
}

This was unlikely to ever have arisen in the past because the only errors this could happen for were 'not available for platform' or 'not available as package', and it's hard to see how someone could have installed the keyboard in the first place in that scenario!

But that changes once we have min version checking in place. Consistency in the api response and the processing is neat and tidy, even though fixing just at one end would be sufficient to address the problem.