您对移动开发框架有何期望？
我们计划构建一个基于网络的客户端应用程序框架。主要重点是使用 Java 编写具有本机外观的 Web 应用程序，并为您的目标平台编译它们。 我们计划的目标平台是 iPhone 和 Android（基于 PhoneGap）、Backberry 和 Palm WebOS。
我们的目标是创建一个像样的框架，这就是这篇文章的主题。我们想知道开发人员对这样一个框架的期望是什么，以及哪些主题比其他主题更重要。我们还想知道是否提供一个真正感觉像目标平台上的本机应用程序（例如滚动行为）的 UI 框架更重要，还是提供一些像样的 API 来使用 HTML5 和 PhoneGap 功能、存储和操作数据更重要等等。
作为开发人员，您真正希望在这种框架中看到什么？毕竟，您是（希望有一天）会使用它的人。最重要的是：你会使用它吗？
we are planning to build a web based client side application framework. The main focus is to write native looking webapps using Java and compile them for your target platform.
Our planned target platforms would be the iPhone and Android (on top of PhoneGap), Backberry and Palm WebOS.
Our goal is to create a decent framework and that's what this post is about. We want to know what developers would expect of such a framework and on what topics are more important than others. We also want to know if it would be more important to provide a UI-framework which really feels like a native app on the target platform (e.g. scrolling behavior) or to provide some decent APIs to use HTML5 and PhoneGap features, store and manipulate data etc.
What would you, as developers, really like to see in that kind of a framework? After all, you're the ones that will (hopefully some day) be using it. And most important: Would you use it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我想要一个适用于移动平台（至少是 iPhone 和 Android）的良好 GWT 框架，具有原生感觉的 UI（即：平滑滚动、快速单击）以及通过 CSS 进行 UI 定制。
我会为此付出代价！
I would like a good GWT framework for mobile plateforms (at least iPhone and android), with a native feel UI (ie : smooth scroll, fast click), and UI customization by CSS.
I would pay for that !!
使组件的设置和默认行为开箱即用——为它们提供一个构建器模式，以便组件可以在一行中使用，或者为它们提供包含足够数量参数以创建格式良好的对象的构造函数。
沿着这些思路，每个 GUI 组件都应该有一个适配器来采用各种基于模型的数据结构。传递它，不要大惊小怪，不要麻烦，绝对不要装箱/拆箱。
Make the setup and default behaviors of components work right out of the box -- give them either a builder pattern so that the component is ready to be useful in one line, or constructors that contain sufficient amount of parameters to create a well-formed object.
Along these lines, every GUI component should have an adapter to take a variety of model based data structures. Pass it along, no-fuss, no-muss, and absolutely no boxing/unboxing.
基于 webkit 的移动框架的缺点是它们不像其他应用程序那样流畅和快速。这是它们全部堆叠的地方。我建议您编写一个 JAVA Dalvik 框架，它很容易扩展用途，具有良好的错误处理和强大的 UI。它绝对应该有自己的插件模式，这样如果您打算开源，社区可以扩展它
the bad thing about the webkit based mobile frameworks is they are not as smooth and fast as other applications. This is where all they stack. I would recommend you to write a JAVA Dalvik framework, which is easy to extend an use with a nice error handling and strong UI. It should definetly have it's own plugin pattern so the community can extend it if you are planning to go open source
我个人最喜欢的是允许我使用 Widget 标准 http://www.w3 进行开发的东西。 org/TR/widgets/，然后通过将小部件包装到 Web 视图或类似内容中来发布到应用程序商店。 Opera Mobile、Samsung Bada、Symbian 以及现在的 Android 均已支持该平台。 http:// labs.opera.com/news/2010/12/22/
这将包括一个准系统 JS 框架，可以将其闭包编译得更小，仅使用我真正使用的框架的方法/部分，以保持最小的大小。
My personal favourite would be something that would allow me to develop using the Widget Standard http://www.w3.org/TR/widgets/ and then publish to app stores by wrapping the widget into a webview or similar. Opera Mobile, Samsung Bada, Symbian and now Android support the platform already.. http://labs.opera.com/news/2010/12/22/
This would include a barebones JS framework that could be Closure Compiled smaller, using only the methods/ parts of the framework I really used, to keep the size minimal.
我们的方法是尽可能保持设备平台中立。
如前所述：我们的目标是用 Java 编写应用程序，然后针对特定的目标平台对其进行编译。还应该可以为所有我们支持的平台编译相同的应用程序，无需对 Java 代码进行任何更改（或至少尽可能少的更改）。
我们选择使用“网络”作为我们的运行时，因为几乎所有移动平台都提供某种类型的网络环境，我们可以在其中部署应用程序。
Our approach is to be as device platform neutral as possible.
As said before: Our goal is to write an application in Java and to compile it then for a specific target platform. It should also be possible to compile the same application without any (or at least as few as possible) changes in your Java-Code for all our supported platforms.
We choose to use "the web" as our runtime because almost all mobile platforms provide some kind of web environment on which we could deploy our apps.