Iphone 应用程序与离线网络应用程序。哪种方式最聪明？
我考虑从头开始构建一个小型应用程序，满足两个技术要求：
- 应该可以在 iPhone 上使用
- 应该可以离线工作
这里有两个明显的替代方案可供选择
- 具有离线功能的真正 iPhone 应用程序
- 使用 HTML5 离线、Google Gears 或类似功能的 Web 应用程序
没有 iPhone 应用程序开发经验（我没有 iPhone），我想知道哪条路最容易走？
构建离线 HTML 与构建 iPhone 应用程序的学习曲线是怎样的？
I think about starting from scratch building a small application fullfilling two technical requirements:
- should be usable on iPhone
- should work offline
There are two obvious alternatives here to choose between
- A real iPhone application with offline capabilities
- A web app using HTML5 offline, Google Gears or similar
Having no iPhone app development experience (I don't own an iPhone), i wonder which way would be the easiest to go?
What are the learning curves for building offline HTML vs building an iPhone app?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
老实说，这取决于您的应用程序要做什么。
MobileSafari 支持所有 HTML5 离线内容，因此您可以将数据存储在客户端 SQL 数据库中、缓存应用程序客户端等...移动 Gmail 应用程序可能是其中最著名的示例，它使您可以对 Gmail 进行全功能访问即使离线时。您还可以通过 3.0 中添加的 JavaScript API 使用地理定位。 Web Clip 还可以让您的 Web 应用程序与本机应用程序共享主屏幕。 这篇 Stack Overflow 帖子。
显然，喜欢处理 HTML、CSS 和 JavaScript（可能还有服务器端运行的任何语言）的人会对开发 Web 应用程序感兴趣。使用离线 Web 应用程序可以做一些非常巧妙的事情，但其性能不会像本机应用程序那么好，尤其是在 3GS 之前的设备上。
开发本机应用程序需要您学习 Objective-C（或在 Mono Touch 面向大众推出后立即学习 C#），并支付 99 美元的费用才能在设备上进行测试并部署到 App Store。系统的更多部分通过各种 API 向您展示，例如相机、指南针、多点触控等。
如果您熟悉 Java，那么 Objective-C 很容易上手。您只需要习惯方括号语法和内存管理，然后就非常简单了。
然后是混合系统，例如 PhoneGap，只要 Web 应用程序在特殊容器应用程序。它也是跨平台的，因此如果您愿意，您也可以在 Android 和 BlackBerry 上部署该应用程序。这仍然需要您支付 App Store 费用，但如果您更熟悉 Web 开发，这可以让您两全其美。
Honestly, it depends what your app is going to do.
MobileSafari supports all the HTML5 offline stuff, so you could store data in a clientside SQL database, cache the application clientside, etc... The mobile Gmail app is probably the most notable example of that, giving you full-featured access to your Gmail even when offline. You can also use geolocation through JavaScript APIs that were added in 3.0. Web Clips let your web app share the home screen with native applications too. There is more on using web apps on the iPhone on this Stack Overflow post.
Obviously, doing a Web app will be of interest to people who like dealing with HTML, CSS, and JavaScript (and possibly whatever language is running server-side). It is possible to do really neat stuff with offline Web apps, but its performance won't be as good as that of native apps, especially on pre-3GS devices.
Developing a native application will require you to learn Objective-C (or C# as soon as Mono Touch is available to the masses) and pay a $99 fee to be allowed to test on-device and deploy to App Store. A lot more of the system is exposed to you through the various APIs, such as the camera, compass, multitouch, and so on.
Objective-C is pretty simple to pick up if you're familiar with Java; you only really need to get used to the square bracket syntax and memory management and then it's pretty straight-forward.
Then there are the hybrid systems, like PhoneGap, which expose more of the device's APIs, provided the Web app runs in a special container app. It is also crossplatform, so you could also deploy the app on Android and BlackBerry if you wanted to. This still requires you to pay the App Store fee, but if you're more familiar with Web development, this gives you the best of both worlds.
一般来说，我不能告诉你太多关于 HTML 应用程序的信息，但我可以告诉你
UIWebView的 API 非常少，当然，与本机 iPhone 应用程序相比，您能做的事情要少得多。I can't tell you too much about HTML apps in general, but I can tell you that the API for the
UIWebViewis extremely minimal, and of course there is much less you can do than in a native iPhone application.HTML5 离线应用程序会存在安全问题，因为您必须将您的 oauth 秘密硬编码为任何人都可以看到的代码（通过单击“查看源代码”或在 Firebug 中检查）。您可以简单地使用 http 身份验证，但随后您会从应用程序发送的每条推文中获得丑陋的“来自 API”信用，以及来自浏览器的丑陋的 http 身份验证弹出窗口。
An HTML5 offline app would have security issues as you would have to hard code your oauth secret into code that anyone could see ( by clicking view source, or inspecting in Firebug ). You could simply use http auth, but then you get the ugly "from API" credit with every tweet sent from your app, and also that ugly http auth popup from the browser.