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?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
为了让您了解问题的范围,请查看此表格 键码。
如果您能够根据目标手机改变 JAD 内容,Omermuhammed 的方法是一种很好的方法,例如通过查看来自手机 Web 浏览器的下载请求中的用户代理标头字段。
如果您在应用程序交付之前无法识别手机,您可以查看类似此的内容它基本上确定运行时的主机手机并适当地设置键码映射。
虽然对我来说看起来很麻烦。
最后,如果您的应用程序使用代码子集,您可能能够摆脱硬编码列表 - 对于某些代码,没有或很少有冲突(LEFT 通常是 -3 或 -61,这些代码通常没有其他含义)。同样,这不是一个理想的方法。
最终为您建议的资源:wurfl 或用户代理字符串,以及 J2MEPolish 设备密钥代码的设备数据库。
To give you a feel for the scope of the problem have a look at this table of keycodes.
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.
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.
Final suggested resources for you: wurfl or user agent strings, and the J2MEPolish devices database for device keycodes.
我发现的最简单的方法是在代码中使用基于 ITU-T 标准的推荐值进行设置,并使用 jad 参数覆盖它。因此,对于任何给定的应用程序,它将在应用程序启动时查找 jad 参数是否存在并设置它,否则它将使用默认值。
我已经使用这些和类似的技术来编写可以快速移植的应用程序,并且这个过程众所周知。
The easiest way I found was to set it up in code with the recommended values based on ITU-T standard and override it with a jad parameter. So, for any given app, it will look for existance of the jad parameter at app startup time and set it, otherwise it will use the default values.
I have used these and similar techniques to write apps that can be rapidly ported, and this process is generally well known.
完全不同意上面的 Martin Clayton 的观点,类似于在运行时识别主机手机的这种方法绝对是解决这个问题的正确方法。在我看来,包含一个标准类来为您执行此操作远比使用多个 JAD/JAR 麻烦得多。
Have to disagree completely with Martin Clayton above, something similar to this method of identifying host handsets at runtime is absolutely the right way to deal with this problem. And including one standard class to do this for you is FAR less cumbersome than faffing around with multiple JADs/JARs IMO.
这是我创建的方法,它使用键代码和键名称。我大约 10 年前编写了这段代码,当时它支持大多数设备。 (不过,我发现的一个例外是某些 Sagem 型号的
-6
和-7
键代码相反!但您可能可以使用再次输入密钥名称 - 但您可能还需要获取用户代理。)更新了代码,基于 http ://www.iteye.com/topic/179073 ...
This is the method I have created, which uses key codes and key names. I wrote this code about 10 years ago and back then it supported most devices. (One exception I found, however, was some Sagem models which have the
-6
and-7
key codes the other way round! But you could probably work around that using the key names again - but you may need to obtain the user agent too.)Updated code, based on http://www.iteye.com/topic/179073 ...
AFAIR getKeyName 方法在大多数手机上返回的结果完全相同,因此它非常可靠,但自从大约 2 年前以来我就没有在 j2me 中编写过任何内容,所以我的记忆可能会出问题。(您已被警告)
AFAIR the getKeyName method returned quite the same on most phones so it was quite reliable, but I haven't written anything in j2me since about 2 years ago, so my memory might play tricks.(you have been warned)