手机上的 J2ME 应用程序与浏览器答案

【问题标题】：J2ME app Vs browser on a handset手机上的 J2ME 应用程序与浏览器
【发布时间】：2009-03-04 04:42:35
【问题描述】：

最近我开始开发 J2ME 应用原型。我注意到开发一个好看的 UI 是多么困难。考虑在 J2ME 中开发一个应用程序来预订与 Web 服务交互的航班。

一个预订航班的网站将易于开发，具有漂亮的用户界面，并且可以通过手机上的浏览器访问。我知道并非所有手机都有浏览器，但所有新的和即将推出的手机都有浏览器并且也有大屏幕。

在 j2me 中开发这样一个需要与 webservice 对话才能工作的应用程序是个好主意吗？还是 j2me 只适合独立应用？

【问题讨论】：

标签： java-me mobile

【解决方案1】：

J2ME 的优势：

可以访问电话资源，如文件系统、电话簿和 GPS。最后一点在地图应用中非常重要。
您可以构建更丰富的用户界面。正如您所说，这可能很困难，但是有许多 GUI 库可以帮助您。相反，移动浏览器的 UI（不能依赖 CSS 和 javascript 工作）会很差。
通信逻辑更加灵活。您可以加密/解密数据、压缩它们、使用 SOAP Web 服务。使用浏览器，最好的办法是开发 REST 服务。

J2ME的缺点：

需要对Midlet 进行签名。这会产生一些成本，而且在某些情况下，即使是已签名的应用也无法在特定手机上正常运行。
开发一个能在所有类型的手机中运行的 midlet 是一场噩梦。相反，一个设计良好的移动网络应用程序将在所有最近的手机中正常显示。
您需要有一个渠道来分发您的应用程序。人们需要下载它并为所需的带宽付费。您需要照顾那些对应用程序有问题的愤怒客户。有了网站，事情就变得更简单了。
J2ME 应用程序不可避免地与本地应用程序（iPhone、Windows Mobile、Symbian）进行比较。与这些相比，它们非常贫穷，许多人会发现为它们付费甚至使用它们是不合理的。

我的结论：如今真正的智能手机越来越受欢迎，并赢得了越来越大的市场份额。在这种情况下，J2ME 的优势并不能真正克服它的限制。我能想到的唯一例外是，如果必须开发 GPS 应用程序。对于所有其他情况，移动网站是一个更好的主意。

【讨论】：

一些更正。首先，midlets 不需要签名，这对于 BREW 等平台来说是一个很大的优势。其次，智能手机通常共享相同的 JVM，因此开发一个可以在任何地方运行的应用程序并没有那么复杂。顺便说一句，如果您针对浏览器，您将把手机排除在范围之外。第三，如果 JVM 足够快，带有 MSA 的 Java ME 几乎可以完成本机应用程序所做的所有事情。主要的问题是 WM 对 Java ME 的支持……嗯，非常糟糕，而且 iPhone 根本不支持它。不过，Symbian 使用 Java ME 应该没有问题。
Midltes do 如果他们想做的不仅仅是在屏幕上绘图（访问网络或文件系统，读取 GPS 数据），则必须对其进行签名。更糟糕的是，您不能单独签署一个 Midlet 以在所有手机中运行。每个制造商和运营商都需要不同的证书。我不知道 MSA 是什么，但 J2ME 应用程序，即使已签名，也确实受到限制。它们对可以使用的内存有限制，例如不能作为服务运行或在启动时启动。
哦不，他们没有。 GPS/network/filesystem/bluetooth/camera 等无需签名都可以正常使用，尝试时只会收到安全提示。此外，说“开发一个在所有类型的手机上运行的 midlet 是一场噩梦”是非常主观的，在我看来也不正确。如果你小心点，就不会。

【解决方案2】：

在前面的答案中有很多的误解和明显的错误陈述。

我建议您自己进行研究。如今，您可以使用 J2ME 开发非常漂亮的应用程序，而无需编写自己的 GUI 框架。看看 LWUIT 真的。例如，他们将虚拟键盘作为其触摸屏功能之一，而 N97 等设备本身没有虚拟键盘。顺便说一句，使用 LWUIT，如果有人关心的话，你会包含一个 Blackberry 和 Android 端口。

如今，应用程序也成为许多平台的中心舞台，而不仅仅是 iPhone。看看这个领域的最新发展，比如 OVI、RIM、三星、SE、Orange World，它们都是从应用商店开始的。

“让人们在手机上使用网站比让他们下载应用程序更容易。”这只是一个没有证据的主张。你不能这样说。这取决于很多其他因素。 - 为什么用户要再次在相当小的屏幕上输入您的移动网址？

无论如何，这个答案可能为时已晚，所以我不会写更多。移动行业现在正在快速变化，但对于跨平台开发，还没有 J2ME 的替代品。也许在未来会有更好的浏览器和小部件技术。

【讨论】：

【解决方案3】：

请注意，谷歌地图或 gmail 手机等应用程序可能不使用 WebServices 与其服务器部分通信。 WebService 有很多开销，尤其是考虑到移动用户通常根据他们传输的数据量来评分时。在客户端应用程序与其服务器部分之间执行通信的最佳方式是通过套接字连接使用二进制数据。

我个人认为，要制作一个可在大量手机上运行的一致且可靠的 J2ME 应用程序真的很难。根据我的经验，如果有严格的要求，我只会开发 J2ME 应用程序（而不是 Web 应用程序）——例如，能够在不连接到网络的情况下查看您的预订。与 J2ME 应用程序相关的其他成本 - 必须下载应用程序，当应用程序尝试连接时，用户将被询问是否允许连接到网络（这种情况有例外，但我认为必须对应用程序进行签名由第 3 方公司 - 涉及更多 $$$），您将不得不维护在各种手机上运行的应用程序的不同版本（应用程序更复杂），等等......

这样想 - 如果您正在为计算机开发类似的东西，您会构建桌面应用程序还是 Web 应用程序？对于今天的手机（其中许多可以使用 javascript - 这意味着 ajax 访问完整的 html 网站），这个问题的命题是有效的。

【讨论】：

a) en.wikipedia.org/wiki/Web_service ：“两大阵营：大 Web 服务和 RESTful Web 服务”。谷歌经常使用后者。 b) 问题是“这是个好主意……”，而不是“难不难……”。我不反对后者。然而，对于用户来说，拥有一个专门的应用程序肯定是值得的。

【解决方案4】：

我认为一个好的经验法则应该是：如果您想要实现的目标可以通过移动网站完成 - 选择网站。

恕我直言，只有在无法利用移动硬件（如位置、声音、视频、3d、图片等）的情况下才能使用应用程序...

即使应用程序的开发成本微不足道（通常不会），您也必须提供一些非常惊人的功能来让用户不费吹灰之力地下载它。

（所有这些对于 J2ME/BREW 来说基本上都是正确的。iPhone 有点不同，因为应用程序占据了中心舞台）

【讨论】：

【解决方案5】：

有一点值得强调：部署 MIDlet 的唯一标准方法是通过 OTA 下载，因此您不会期望支持 J2ME 的手机没有网络浏览器。

Webkit 和 Opera 等移动网络浏览器的性能比 J2ME 更快（至少在 MIDP3.0 开始发布之前，如果有的话）。

无论您选择哪个平台，您都需要在许多设备上测试您的服务。我不认为从 J2ME 切换到 webapp 在这方面有很大的不同，因为手机制造商一直在更改手机固件中的二进制文件。

让人们在手机上使用网站比让他们下载应用程序更容易。除非他们在购买手机时已经安装了该应用程序。

您可能希望查看 LWUIT 以获得更好、更简单的 J2ME GUI。

J2ME 将为航班预订服务完成的一件事是通过不需要持续的网络数据传输来节省电池寿命，这要归功于本地存储机制。

【讨论】：

【解决方案6】：

有很多很棒的 j2me 应用程序（需要）与 Web 服务通信。想想谷歌应用程序，比如 gmail 手机和手机地图。它们比通过手机浏览器使用服务更快、更容易使用。所以如果你能设计出一个好的应用程序，那绝对是值得的。

编辑：此外，j2me 应用程序使 Web 应用程序无法提供的功能成为可能：与电话功能（地址簿、日历）、“拨打此号码”、位置 api 等集成。

【讨论】：

【解决方案7】：

我认为对于商业应用程序或更多面向文本/数据的事物，移动 web/wap 网站可能更易于维护，因为您不必处理将客户端更新推送到手机的问题。

对于 UI 密集型应用（地图、游戏等），客户端应用可能是最佳选择，因此您可以在客户端处理更多的处理和渲染。

不过，这两种选择都很困难，因为手机存在很多兼容性问题。缩小您希望为您的应用程序支持的手机类型可能会为您提供最好的服务。如果您认为您的大多数客户将是 iPhone 或 Android 手机，那么您可以针对这些平台（使用客户端应用程序或 Web 应用程序）并完全避免使用老式的 j2me。

【讨论】：

【解决方案8】：

我讨厌手机上的 WebApp。它们速度很慢，并且不能在半连接环境中工作。

J2ME 应用可以进行本地备份、蓝牙备份、两部手机之间的蓝牙数据共享以及响应速度更快的 UI。然而，这需要金钱、技能、时间等。

我对 MIDP 的主要抱怨是推动软件更新和 wav 实时混音。从技术上讲，这些在 MIDP 的范围内是可能的，但在车轮上的暴徒并不是很有创意。

【讨论】：