ios - iOS 13 默认显示系统表情符号键盘

Question

解决方案

这是一个full solution/work关于这个问题，请投票 Blld 的 answer也是因为这是所需的重要信息!

辅助搜索的替代标题

• 将表情符号键盘显示为 UIKeyInput 对象的默认设置(在 iOS 13 中)
• 强制 iOS 13 显示表情符号键盘
• 将 UITextInputMode.primaryLanguage 设置为表情符号
• 以编程方式将键盘设置为表情符号

ios13之前返回带有等于“表情符号”的 primaryLanguage 的 UITextInputMode 将默认显示表情符号键盘(见下图)。

返回“表情符号”的示例代码UITextInputMode。

//
//  ViewController.swift
//  Keyboard Info
//
//  Created by Richard Stelling on 30/09/2019.
//  Copyright © 2019 Richard Stelling. All rights reserved.
//

import UIKit

class TestButton: UIButton, UIKeyInput {

    var hasText: Bool = true

    func insertText(_ text: String) { print("\(text)") }

    func deleteBackward() {}


    override var canBecomeFirstResponder: Bool { return true }

    override var canResignFirstResponder: Bool { return true }

    override var textInputMode: UITextInputMode? {
        for mode in UITextInputMode.activeInputModes {
            if mode.primaryLanguage == "emoji" {
                return mode
            }
        }
        return nil
    }
}

在 iOS 12 上运行此代码会将键盘设置为系统表情符号键盘，但在 iOS 13 上没有任何影响。

这是一个已知的错误吗？有解决方法吗？

更新

• 请求者:@Navillus ，“事件输入模式”的完整列表是； "en-GB", "表情符号"
• 已测试并确认； 13.0、13.1、13.1.1、13.1.2 和 13.2(种子 1)

Answer 1

我针对 iOS 13 提交了雷达，因为我有一个日语/英语双语应用程序。有些字段是日语，有些是英语，因此显然向用户提供正确的键盘类型而不是让他们来回翻转 20 次是有意义的。

对此有一个解决方法，那就是在 UIKit 调用“textInputMode”之后，您可以在主线程中执行以下操作:

// has to be done after the textInputMode method is called
if #available(iOS 13, *) {
    textField.keyboardType = textField.keyboardType
} 

这会强制键盘在使用您想要的 textInputMode 应答后重新加载。我向他们通报了该错误以及获得正确行为的解决方法。

因此，在 iOS 13.1 中，该错误并未得到修复，但它们阻止了我的解决方法。

不错。我不会再向他们报告任何错误。相反，如果我找到解决方法，我就会使用它。

所以看来他们现在正在默默地禁用此功能。它是一个功能，这实际上就是这个方法调用的目的，找出应该向用户呈现什么输入模式。

如果您有其他语言并且想要选择英语，它仍然可以正常工作。

因此，如果我的用户将日语设置为键盘选择，那么我可以强制使用英语键盘。只是不是相反。任何获得日语输入模式的尝试都会以英语键盘告终。

编辑:

还有另一种方法可以解决这个问题，但它涉及内部 API 的发现和使用，这并不简单。您必须本质上找到用于管理点击地球按钮的结果的函数。如果您这样做，您实际上是在模拟用户的点击，并且它具有广泛的效果，也就是说，键盘也会针对其他应用程序进行更改。所以不推荐，100%会提交App Store失败。由于我上次解决方法的结果，我不想发布它。

我认为不太容易理解苹果。我所知道的是:

1. API 未按照发布的方式运行
2. 已报告，但他们没有修复该错误
3. 自报告之日起，他们(有意或无意)违反了解决方法

因此， future 的解决方法应该被囤积起来，直到他们的意图明确和/或他们修复了这个错误(这是他们应该做的)。简单地撤销部分 API 而不发布更改是一个主要错误。