WebView and native code writing in iOS development is this a tangled thing? I'm writing this article to introduce some of the experiences and techniques I've been working on iOS for two years in conjunction with WebView and native code, of course, based on Internet apps, We hope to help you.
First of all, what are the pros and cons of both? WebView and operational costs are low and updates are almost independent of app versions, but there is a big gap between interaction and performance with native code. Native code corresponds to it.
Note, I do not say HTML5 here, because I think, HTML5 does bring a new era to the Web. What this era is, web App. That is, only out of the native premise, in the browser environment, the meaning of HTML5 can be revealed, and when we discuss the iOS app, HTML5 obviously meaningless.
Whether using WebView or native code, I have two principles:
1, no discount on user experience
2, operation and maintenance cost is low
Note, why not mention the development cost. Because doing web development and iOS development is fundamentally different. Of course, web development has evolved over the years, and for some implementations it's faster than the native app. But in most cases, the same feature, for both iOS developers and web developers, has the lowest cost of development in their own way, so it is often a pseudo proposition that a feature development cost is low.
Just said, the advantage of WebView is that the update does not rely on the version, then in an app, only the interface that will be updated frequently to consider webview is meaningful. So which interface will be updated frequently, this will be different from the app, I only say two years, I have access to some.
Home. Home resources can be a battleground, the content of a day to change is normal phenomenon, a few changes a day is not uncommon. And if only the content of the replacement, not to the last WebView is a bit radical. In fact, the changes in the home page is strange, holidays change face, special circumstances hanging an announcement, occasionally also special approval strong push a business, and so on.
Before, I design the first page of the app, the first page configuration design is very complex. App side to deal with n cases, n parameters, server side to remember the N rules, until one day, I collapsed, the home page completely replaced WebView, just suddenly enlightened.
The active page. Doing the internet is known, activity, is one of the most common means of operation. The characteristic is that the period is short, the function is few, but basically can not reuse. These characteristics all identify the activities are not suitable for native, to be implemented with WebView.
Even if someone tells you that my activity is a long-term activity and that the form remains the same, do not trust him. Because in the second, third, and fourth, he will add some very strange, but there are very reasonable small changes, which you can not achieve in that version at all.
New function of water test. This interface, often design immature, need to continue to collect user feedback during the operation, update upgrade, or even decide to stay. So, only webview can hold such an unstable function.
Remember that before a feature is not determined, do not develop native code in a very powerful unit, you know, you write these code, three days after the change, and to publish online.
Rich text content. Needless to say, it's not a small project to do a webtext according to the usual HTML tags. and rich text changes too much, a little can not match, will lead to the entire interface ugly.
OK, above said I think the most use of WebView 4 interface, respectively with different characteristics, with these features to describe an interface, if it is, then do not hesitate, make WebView bar. Said which interface made Webviev, say how to do webview to avoid its shortcomings.
Just said, WebView interaction is a short board, so WebView in an app, only as an interface, not allowed to appear in the interface action.
And how a WebView interface can be combined with native code, my answer is, a hyperlink. Clicking on the hyperlink on the WebView will call the Shouldload method of WebView delegate, from where the request is intercepted and processed. Here is a description of this method, previous article: http://pingguohe.net/2011/06/25/webview_to_nativeview/
Since WebView's links are all URLs, I recommend that you manage the entire app's interface with a URL. From the 320 framework of VC management to get inspiration, to build a new application, always first set up a set of protocols, encapsulating a method, each time the VC switching through the URL. As a result, the server interacts with the app a lot simpler, and so is webview.
The last is the problem of looks, webview difficult to grow into a native view. And my plan is to pretend to be too long. In some cases, disable WebView scrolling and use the scrolling frame (Iscroll is good) to implement. WebView leaves a blank background of 200pixel, and Y starts at 200. Otherwise you know, WebView will have a shadow background, not hidden will be very ugly. And so on, there are many other ways to disguise WebView, which are to be used in a situation.