- 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!
