什么时候去寻找原生Android应用程序以及何时使用HTML5进行混合模型

Question

任何人都可以给我一些指示什么时候给我们一个原生的Android应用程序，什么时候去使用HTML5的混合模型....任何人都可以告诉每个模型的利弊。

Answer 1

Choosing the native app means you target the specific device platform , but with a hybrid app you can target your user audience .

Pros of native app: -outstandig UI effects (you should go this way in case of developing games) Cons of native app: -targeting more platforms means rewriting the app and maintaining more codebase

Pros of hybrid app : -time-to-market factor -low learning-curve (having experience in webdevelopment makes it even easier) -normally it's easy to integrate with the customer's existing data-sources and workflows

Cons of hybrid app: -having many years of experience in enterprise application development causes the feeling that the right dev-tools are still missing

More and more companies realize that HTML5 hybrid application model is essential to implement Line-of-Business application on mobile platform and you can find more-and-mode opensource libraries to build a really responsive app to your customers.

I can see only two risks of hybrid applications, which can be easily avoided: -Developers often test hybrid applications in HTML5-capable desktop browsers. This can cause serious performance issues in the deployed application. So the dev-team should do day-to-day tests on real mobile devices. -You can easily be stuck to a particular framework (Ex. Sencha Touch). Try to prefer using libraries to building application on a specific framework, so you can stay agile and adopt to changing business requirements quickly.

Answer 2

There are two schools of thought here.. 1. cross platform is good 2. cross platform is the least of all things.

When you go for cross platform, you miss out on the specifics of the platform. Years ago I coded for blackberry, but opted to go with J2ME without the blackberry extensions.
This meant my code ran on most java phones. But at the same time, I couldn't make use of the file system on the blackberry, because there were no files in the J2ME world. I could hand code buttons and draw on screen the way I wanted, but I couldn't make use of some of the RIM_JAVA screen classes.

So I got an app that looked and ran the same on smart phones, but didn't take advantage of the RIM hardware. It was a trade off that I was happy to make, because of my target users. If I'd needed some of the RIM specifics, though, I'd have had to have pulled them in, at the expense of a portable application.

It's a coin toss.. If you go with generic, then you get all the common and therefore reach a larger market. But at the same time you don't really get the most out of the hardware.