I can understand why you would want to write an app for a game like Angry Birds, but I don't really see the point for Facebook or Linkedin. These platforms already provide a browser and the sites in question operate perfectly well from the browser on my desktop. The last time I checked, HTTP included information about the type of browser that the request is coming from, so why don't these companies generate specialized HTML that's geared toward the screen size and capabilities of these devices instead of generating and supporting an entirely new code base? What am I missing?
Mobile web pages don't allow the amount of flexibility as apps do, in terms of their capabilities. Take for example, m.facebook.com
vs. Facebook.app
on iOS. The mobile version of Facebook's website works fine for small things like status updates, but the app can do much more than the website, such as upload pictures from the device's Camera Roll, or even access the camera and upload straight from there. Plus, apps are generally better for websites that would require a lot of page navigation. Some mobile websites try to emulate iOS's interfaces, and it's never as good as an actual native app (they may feel awkward and / or slow to use).
In general, native apps are much better because there is much more flexibility than in a web app. Within a native app, a programmer can use all the APIs that are provided to make the application as easy to use as possible, whereas in a web app, you can't.
Maybe you want to add support for notifications other than email, or you want to have a way to upload pictures directly to the web from your device.
I'm sure there are a lot of other reasons too.
I have an Edge/2G connection on my phone (due to receiving free phones that do not have the correct 3G radio frequency for my cell provider) and, as such, browsing the web is a massive pain. It is so bad that I avoid it whenever possible - even mobile sites are painfully slow to load.
Having an app that can limit the data it requires to show required information makes using web-related services much more tolerable. Apps are better tailored to the smaller bandwidth that smart phones have.
Beyond that, apps can better cache and server details offline than websites can.
There could be a bunch of reasons:
1) stubborn execs just want it that way
2) to have a presence in the app stores
3) need to hook into the devices native tools
4) want to leverage native UI elements
That said, you are correct...often a mobile version of the current site is all that's needed.
Partly because native applications work more seamless and smooth, partly because the in a app-hype going on.
In the long term Google thinks webapps will replace native apps and i tend to agree.
I think one of the biggest points is user convenience. It's like a bookmark-shortcut that launches the site from it, but also tags posts with "Android" or "iPhone". You can tell others what phone you're using. The site can be organized a lot better when you pay more focus to the individual devices.
From a user's point of view, using web pages on mobile devices still feels clunky. They're less responsive, especially if javascript is involved. Thick clients can also utilize more efficient caching strategies. They also can use fancier graphics/animations, and you generally need to transfer less data. Those are just a few reasons.
Speaking from the android side of things:
Yeah good question! HTML has a ton of advantages - like the ability to update a UI without your user needing to re-install the app. Also the analytics for web are WAY better than for phone apps at this point. I guess the obvious reason for a native app is that it's going to perform better and feel better to users. Still, I've been looking at the APIs and seen some interesting stuff.
First off there's WebView - http://developer.android.com/reference/android/webkit/WebView.html
This allows you to embed a web page (or have a web page be) your app without the browser chrome - it's just a floating web pane. What's interesting about this is that there are APIs that allow you to expose native android OS functionality to the downloaded JavaScript. Also, you can load we pages from the phone instead of the internet - gets around the long load times issues. So it's possible to have your UI be in JavaScript with a web-based front end. I've been thinking I'm going to try doing this in my next app.
There's also PhoneGap - http://www.phonegap.com/ - Allows you to write HTML apps that then show up in android. I've been sorta unimpressed with their implementation myself, but hey it's a start.
Anyway, would really be worth exploring. It's much slower to write and change a phone app and those are HUGE dis-advantages.
Using the Native UI helps the user experience of your end product.
Also, as phones are in general resource-light, by stripping away the "browser" layer, your end product is likely to be more responsive, and need less overhead in the form of data transmitted.
In terms of Android, I believe the strong allure is to hook into the Intent
system. It is very powerful and incredibly seamless. Not sure about the iThings, have not developed for them yet.
精彩评论