J2ME软键包装器

本文介绍了J2ME软键包装器的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

阅读一些文章告诉我，软键因设备而异. 有人说-6或-21表示左软键，而-7或-22表示右软键. 在这种情况下，是否有任何良好的包装程序或函数或最佳做法可以正确处理?

Reading some articles, told me that soft keys varies between devices. Some says -6 or -21 for left soft key and -7 or -22 for right soft key. Given this situation, is there any good wrapper or function or best practice to handle it properly?

如果无法在所有设备上使用，则支持大多数设备的最佳方法是什么?几乎没有或根本没有黑客入侵?

If not possible for ALL devices, what is the best way to support most devices? with minor or no hack at all?

推荐答案

要使您了解问题的范围，请查看此表.

To give you a feel for the scope of the problem have a look at this table of keycodes.

如果您能够根据目标手机来改变JAD内容，例如通过查看来自手持式Web浏览器的下载请求中的用户代理标头字段，Omermuhammed的方法就是一种很好的方法.

Omermuhammed's approach is a good one if you are able to vary the JAD content depending on the target handset, for example by looking at the user-agent header field in a download request from an on-handset web browser.

如果在交付应用程序之前无法识别手机，则可以查看此基本上在运行时确定主机手机并适当设置键码映射. 不过对我来说看起来很麻烦.

If you cannot identify the handset until the app has been delivered, you could look at something like this that basically determines the host handset at run time and sets the keycode mappings appropriately. Looks cumbersome to me though.

最后，如果您的应用程序使用了一部分代码，则您也许可以摆脱硬编码列表-对于某些代码，没有冲突或冲突很少(LEFT通常为-3或-61，并且这些代码通常并不表示其他含义).同样，这不是理想的方法.

Lastly, if your application uses a subset of codes you may be able to get away with hard-coded lists - for some codes there are no or few collisions (LEFT is usually either -3 or -61, and those codes usually don't mean something else). Again, not an ideal approach.

为您提供的最终建议资源: wurfl 或用户代理字符串，以及用于设备密钥代码的J2MEPolish 设备数据库.

Final suggested resources for you: wurfl or user agent strings, and the J2MEPolish devices database for device keycodes.