Android IMF的一處瑕疵

Android IMF提供了實現第三方輸入法的快捷通道，這個框架基能夠滿足一般輸入法的開發需要，顯然設計者對於IMF還是投入了不少精力。但是任何的設計都不可能是盡善盡美， 設計者並非是萬能的神，所有的方面他都考慮到，總有一些地方做的不夠好，留下一些瑕疵。在我的工作當中，就發現了這麼一個不盡人意的地方。

Android IME

此前受客戶委托，開發一個輸入法，其中有一個要求，即DELETE鍵和其他按鍵不一樣，背景要區別於其他普通按鍵。這意味著我們程序應該達到這樣一個效果，每個按鍵獨立享有背景設置。

通過IMF的分析可以知道，KeyboardView的XML屬性android:keyBackground，可以為按鍵定義背景。縱觀Android PinyinIME，即谷歌拼音輸入法，其每個按鍵的背景都是相同的，似乎它並沒有想到單獨為按鍵設置背景。

進而查看它的源碼，更加印證我的猜測，在KeyboardView類的onBufferDraw方法中可以看到背景的繪制方法：

for (int i = 0; i < keyCount; i++) {
    final Key key = keys[i];
    if (drawSingleKey && invalidKey != key) {
        continue;
    }
    int[] drawableState = key.getCurrentDrawableState();
    keyBackground.setState(drawableState);
 
    // Switch the character to uppercase if shift is pressed
    String label = key.label == null? null : adjustCase(key.label).toString();
 
    final Rect bounds = keyBackground.getBounds();
    if (key.width != bounds.right ||
            key.height != bounds.bottom) {
        keyBackground.setBounds(0, 0, key.width, key.height);
    }
    canvas.translate(key.x + kbdPaddingLeft, key.y + kbdPaddingTop);
    keyBackground.draw(canvas);
    // 省去剩余部分
}

其中的keyBackground正是我們所要尋找的關鍵，可惜Android IMF的設計師在這個地方偷懶了，他沒有提供給我們單獨設置keyBackGround的接口。如果繼續看下去，我們會看到按鍵icon的實現，此時你會覺得我說設計師在偷懶一點都不為過，為什麼呢？我們來看按鍵icon部分是如何繪制的。

else if (key.icon != null) {
    final int drawableX = (key.width - padding.left - padding.right
                    - key.icon.getIntrinsicWidth()) / 2 + padding.left;
    final int drawableY = (key.height - padding.top - padding.bottom
            - key.icon.getIntrinsicHeight()) / 2 + padding.top;
    canvas.translate(drawableX, drawableY);
    key.icon.setBounds(0, 0,
            key.icon.getIntrinsicWidth(), key.icon.getIntrinsicHeight());
    key.icon.draw(canvas);
    canvas.translate(-drawableX, -drawableY);
}

就這樣，按鍵的icon可以單獨設置，並且方便的繪制處理，那麼為什麼背景就要一刀切，所有按鍵一個背景呢？我認為設計師沒有足夠的理由來說服我。它只要在定義icon的時候，同步定義keyBackground，然後把keyBackground如同icon一樣作為Keyboard.Key的一個屬性，接下來的處理類似icon。這樣一來，大家皆大歡喜，豈不是很好？