良好的 J2ME 项目设计

Question

在一个针对尽可能多的功能手机（诺基亚3110 Classic、三星E250、摩托罗拉SLVR L7等）的项目中，在代码结构方面应该如何设计？我并不是指每台手机的支持，因为我们为此使用波兰语。

我是一名经验丰富的 C# 开发人员，正在我的公司从事 J2ME 开发。几个月前，管理层聘请了一位高级 J2ME 开发人员，因为现有的开发人员缺乏任何 J2ME 经验。我现在正与另一位 C# 开发人员一起加入该团队，我们都对我们所看到的有所保留。虽然软件运行并满足业务需求，但应用程序的设计对我来说似乎完全错误。

由于“手机上的内存限制”，大多数代码不是使用 OO，而是由静态方法和常量组成，并且在尽可能少的类中（据我所知是 15 个）。其中一些长达数千行。显然，除了 Canvas 之外，没有使用任何内置 UI 元素，因为它们“没有提供足够的控制”。

所有表单/窗口/页面（不确定正确的术语）在一个类中都有一个静态方法，我们在其中有代码来设置该表单/窗口/页面的 UI。如下：

UiElement items[] = new UiElement[8 + (fieldCount * 4)];
int y = 0;
items[y++] = new UiElement("name", UiElement.TYPE_TEXT_FIELD, "Name", TextField.ANY, true, "", true, null, -1, 0);
items[y++] = new UiElement("address", UiElement.TYPE_TEXT_FIELD, "Mobile", TextField.PHONENUMBER, true, "", true, null, -1, 0);
// ...
items[y++] = UiElement.LINE;
items[y++] = new UiElement("button", UiElement.TYPE_BUTTON, "Save", -1, false, "", true, null, UiElement.TYPE_LINK, ActionHandler.LINK_UPDATE_USER);
items[y++] = new UiElement("", UiElement.TYPE_RED_BUTTON, "Delete user", -1, false, "", true, null, UiElement.TYPE_LINK, ActionHandler.LINK_DELETE_USER);
items[y++] = UiElement.LINE;
items[y++] = new UiElement("", UiElement.TYPE_LINK_ARROWS, "Back to choose category", 0, false, "", true, null, -1, ActionHandler.LINK_MC_SELECT_CATEGORY);
items[y++] = UiElement.LINE;

UiElement 的主要构造函数是

public UiElement(String RMSref, int inputType, String displayText, int additionalInputType, boolean mandatory, String aditional, boolean selectable, Image img, int displayType, int actionLink)

最后，调用将 items 数组保存在扩展 Canvas 的类上。该类有一个带有巨大开关块的绘制方法，在 UiElement 的 inputType 上分支。从那里，它转到“图形”类上的静态方法，该方法为每种不同类型的“控件”提供方法来处理该“控件”的绘画。

实际上，似乎一切都是程序化的，并且只在必要时使用 OO。我问高级开发人员为什么我们没有一个基本的 Control 类，然后是它的子类，每个都有独立的绘画、属性等，而不是这个通用的 UiElement 类，这显然是因为很多类占用太多内存。我还被告知有些手机有错误的 Java 运行时，因此它们不能正确释放内存。这也是只有一个 Canvas 的原因。

作为另一个例子，所有的文本输出都是通过使用位图字体完成的，而不是使用手机的内部字体渲染。有人告诉我们，这是为了提供跨手机的统一渲染，而不是依赖于它们的内部字体集和大小。

这是正确的做法吗？我们被告知的事情是正确的吗？我希望尽量避免这变成对 TheDailyWTF 的提交。

Answer 1

欢迎来到 j2me 的世界。

随着时间的推移，情况有所好转。但您所看到的实际上是最古老的手机（尤其是诺基亚 40 系列（第 1 代））和古老的三星手机上的处理方式。事实上，添加的任何类都会使您的 jar 大小增加。而且由于某些手机规定了 64kb 的限制，因此任何字节都可以计算。

如果这些老手机不再针对，你可以放下这个古老的做法，多走OO的路。

位图字体也是如此。在每个手机品牌（甚至同一品牌的不同型号）上，手机自己的字体大小差异很大。在摩托罗拉上，如果一个人要求一个小字体，一个人会得到一个大字体。更好的是，摩托罗拉上请求的任何字体都很大且无法使用。

手机字体的优缺点： - 手机字体不消耗宝贵的 jar 内存。位图字体很昂贵 - 位图字体在任何手机上看起来都一样 - 手机字体可以用任何颜色绘制（如果你想让它们有两种颜色，则必须将位图字体加倍）。 - 最新的诺基亚手机实际上绘制了手机字体抗锯齿效果非常好。 Bitmp 字体永远不会被消除锯齿，除非它已经在位图中完成，这意味着您只能在一种背景颜色上使用它们（也可以使用一种消除锯齿）。

无论如何，听起来您那里有一位拥有丰富的 j2me 编码经验（包袱？）的开发人员。也许有点太多了。如果不需要针对古老的手机，那就清理代码并使其更现代。

Answer 2

在 J2ME 开发中，我们无法遵循 OOP 原则，最好的方法是将所有内容保持在单个类中，即使没有任何包以优化内存使用。但是从编程的角度来看，我们会采用某种级别的 OO 概念，例如将代码分成有用的类和包集。但是最好不要使用子类概念。 J2ME Polish 在开发 J2ME 应用程序时非常有用，特别是一个通用的应用程序。 IMO 您走在正确的道路上，由于堆大小有限，我们无法在开发 J2ME 应用程序时应用所有 OOP，特别是在开发涉及大量手机设备的通用 J2ME 应用程序时。

Answer 3

我的价值 0.02 英镑：

内置的 UI 组件 (LCDUI) 通常很丑陋。如果您希望您的应用看起来像“手机原生”应用，它们会很有用；但是，您几乎无法控制它们的外观。在一部手机上看起来很漂亮的东西在另一部手机上看起来很糟糕而且不合适。使用 LCDUI 编写跨手机友好的代码非常非常困难，我会像瘟疫一样避免。

滚动您自己的基于画布的组件意味着您可以更好地控制它们在手机上的外观和行为。

关于字体，我个人不喜欢使用位图字体。它们速度慢、重量级、笨重，而且由于您需要实现自己的字距调整等，因此很难看起来正确，再加上国际化呢？诚然，某些手机字体令人讨厌（特别是如 reinier 提到的旧 Motos）。但是，请记住，用户将习惯于使用该手机，并且仔细的 UI 设计（和组件实现）意味着您可以使用 任何 大小的字体（请注意，旧 Motos 给您的原因如果你要求小，那么大，是它们实际上只有一种字体）。

根据您的应用程序的功能，您需要解决很多很多不为人知的手机错误。是的，有些手机在 GC/内存分配方面有一些怪癖，可能会咬你一口。

但是，只有当您的目标是适当的老式/低内存手机时，您才需要完全“将所有内容放在一个类/方法中”极端。与位图字体 IMO 的开销相比，您在该部门所做的任何努力都将毫无意义。

HTH

Answer 4

我在这里第二个 reiner 的帖子。我确实想添加嵌入在代码中的字符串是维护的噩梦，最好将它们作为常量放在 CustomStrings 类中。与图像/资产名称相同，只是更易于维护。

我想说的另一点是针对高端（大于 64k 限制 jar 大小）手机的初始发布目标。这种方式很无痛。稍后您可以添加对低端手机的支持。

另外，那位高级 J2ME 工程师似乎知道他的方法，听他谈谈 J2ME 开发的固有问题，不一定是解决方案。