Java me 良好的J2ME项目设计

在针对尽可能多的功能手机（诺基亚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数组。该类有一个带有巨大开关块的paint方法，它在UiElement的inputType上分支。从那里，它转到“graphics”类上的静态方法，该类为每种不同类型的“控件”提供了处理该“控件”绘画的方法

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

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

---

这样做对吗？我们被告知的事情正确吗？我希望尽量避免这种情况变成提交给DailyWTF。

在J2ME开发中，我们不能让OOP原则继续下去，最好的方法是将所有内容都保存在一个类中，即使没有任何包来实现最佳内存使用。但从编程的角度来看，我们倾向于某种程度的OO概念，比如将代码划分为一组有用的类和包。但你最好不要选择这种分类概念。在开发J2ME应用程序（特别是通用应用程序）时，J2ME抛光非常有用。在我看来，您走的是正确的道路，我们不能在开发J2ME应用程序时应用所有OOP，因为堆大小有限，特别是在开发涉及大量手持设备的通用J2ME应用程序时。

欢迎来到J2ME世界

随着时间的推移，情况有所好转。但事实上，你看到的是最古老的手机（特别是诺基亚40系列（第一代））和古老的三星手机的操作方式。事实上，任何添加的类都会使您的jar大小增加。而且，由于一些手机规定了64kb的限制，任何字节都会计数

如果这些旧手机不再是目标，你可以放弃这种古老的做法，走更多的面向对象的道路

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

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

无论如何，听起来你有一个开发人员在那里有很多j2me编码的经验（包袱？）。可能有点太多了。如果没有必要针对老式手机，那么请清理代码，使其更加现代。

我的价值0.02英镑的手机：

内置UI组件（LCDUI）通常都很可怕。如果你想让你的应用程序看起来像一个“手机原生”应用程序，它们会很有用；然而，你对它们的外观几乎没有控制权。在一部手机上看起来漂亮的东西在另一部手机上看起来很糟糕，不合适。使用LCDUI编写跨手机友好的代码是非常困难的，我希望避免这种瘟疫

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

关于字体，我个人不喜欢麻烦位图字体。它们速度慢、重量重、笨重，而且可能很难找到正确的外观，因为您需要实现自己的内核处理等，再加上国际化又如何？诚然，有些手机字体令人讨厌（尤其是雷尼尔提到的老式Motos）。但是，请记住，用户将习惯于在手机上使用这些字体，仔细的UI设计（和组件实现）意味着您可以使用任何大小的字体（请注意，如果您要求使用小字体，旧Motos会给您大字体的原因是，它们实际上只有一种字体）

有