Custom Keyboard Extension 的屁事博 -- 在Container App 中植入键盘(一)

亲爱的甲方在键盘的Container App里面做一个「学习模块」,想要就是在Container App里面让用户学习使用键盘的模式。这是基于我们keyboard Extension本身功能已经健全(绝对没有一丝的设计不合理,也不是因为输入法学习成本高,只是为某些LowB用户提供的智商扶贫计划😉)。

基于这样的需求,我们不能简单给用户一个输入框,让用户自己切换输入法在那练练练,而是把键盘直接植入到应用程序画面中,用户进入画面中,我们的键盘就已经在画面中stand by了。

项目开始调查,我开始了植入方案的研究。项目会议时,我提出了几个方案:

  1. 将现有的输入法代码加入容器App的编译,并在容器中以某种方式实现加载该输入法,并实现联动输入框
  2. 在容器App中重新实现(Copy)一套输入法逻辑,就像普通的自定义轮子一样加载View,并不与输入法的一套规则产生联系
  3. 告诉客户:这个方案太贵了,原因如下。。。

方案选择:

方案1

当然是最好的方案,优点是完全重用现有输入法逻辑,与现有产品在功能式样上保持高度一致,将来需求的变更可以同步反映,代码量少,大量的代码规模都可以用于业务逻辑✌️。但缺点也很明显:可行性未知国内相关经验少,相关资料几乎为0,仅在栈溢出论坛上有少量的有用信息。

方案2

一个泥瓦匠刚刚学会砌墙,就希望拿手上这点手艺,修建高楼大厦,用这种无限使用于未来的方法,置换体内星辰河流。这个方法无疑是最体力活、最屌丝的方法:大量重复逻辑的编写,工匠之心囿于界面与接口;无法反映将来输入法需求变更的修改;随着项目规模扩大,它将难以维护。但就目前来说,它具有高可行性,能实现现阶段的客户需求。

方案3

却下,客户说:有的是钱。

讨论的结果是,先前期调查方案1的可行性,并尝试实现植入,如果可行,便上马,如若不行或短时间内不行,还有方案2作为备胎方案,暂时放下你的破情怀,先面向需求编程再说。