This bypasses any need to modify KMW keyboard loading (say, via .fetch), though it does require a number of collateral changes to be made in order for CORS, etc to be satisfied.
Build-bot: skip build:ios
Pretty much just what the title says; it's been silently missing this whole time.
This doesn't fix iOS keyboard's display by itself, but it is a prerequisite for the full solution offered by #16136.
Build-bot: skip build:ios
Test-bot: skip
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
- Also renamed `prefixed` and `withoutPrefix` functions to use the name
that was aliased on most cases: `toPrefixedKeyboardId` and
`toUnprefixedKeyboardId`.
- Renamed `ModelManager` class to `ModelCache` which was the name used
everywhere except in comments.
Part-of: #15292
Test-bot: skip
Also adds minor documentation to new SentryManager.swift additions
Fixes: KEYMAN-IOS-MJ
This error was manually triggered to validate this PR's actual changes, given that the aim is to enhance error logging.
Warnings about known devices without predefined keyboard-scale map entries will be
limited to once per startup of the app and/or app-extension.
Test-bot: skip
See-also: #13769
Fixes: #12589Fixes: #13688
At some point, iOS seems to have enacted behavior that will cause a toolbar to go translucent/transparent in certain scenarios - such as when it would cover up the bottom of a fully-scrolled view. This has been triggering on our keyboard-search page, directly causing the behavior seen in #12589.
Reference: https://stackoverflow.com/a/71985231
It appears fixing this thoroughly _also_ addresses #13688, so... yay for "two birds, one stone"!
This PR updates the database that KeymanEngine uses to determine what size of keyboard to use for each device. This should ensure the default size for the keyboard matches the system keyboard's dimensions.
Fixes: #12590
If we're already showing the package-installer for a keyboard the user found via search... then we clearly downloaded it successfully. Why double-notify?
It turns out that #12590 itself was due to our usage of a TabBarController outside the prescribed safe use cases. We're actually fine most of the time... but it seems the tab area doesn't play nicely with a NavigationController toolbar, which is what displays download + update notifications. Rather than find a way to force that to work, it's simpler to just... not show the toolbar, **ever**, when the package installer is displayed.
This tweaks the recently-merged #13631, which accidentally introduced a bug in which _any_ downward swiping motion on the Settings view would always dismiss it, even should the user attempt to cancel dismissal.
Fixes: #13443
Slide-dismissal of the settings menu, and of the keyboard-height setting view in particular, should apply changes after dismissal... not only after backing out via navigation buttons.
Certain aspects of the iOS API didn't make it easy, though. After some searching, I found that "presentation controllers" and related can be leveraged to ensure we can detect Settings menu dismissal. With that detection in place, we can use the same method that's been working fine for us when backing out of Settings via button. This also ensures the keyboard will immediately display after dismissal, too!
