Readers of this article need to have a certain foundation of Hybrid, related concepts have been explained in many excellent articles, not repeated here. The focus of this article is how to complete a WAP page download on mobile (not limited to specific platforms) based on the Hybrid framework. This page will contain rich media resources, including images, audio, video, etc. Once the download is complete, we can still read the full content of the page while offline.
Scenario analysis
Using WAP pages to display content on mobile terminals has many application scenarios, such as common news reading, simple books or gold-digging articles display. The client provides webView container, supporting a series of front-end and client interaction capabilities. The front-end uses templates to generate different content in batches and then delivers it, giving play to the extremely high flexibility of the front-end and enjoying many native capabilities of the client.
In the previous scenario, users have little need for caching. In some products, however, it may be necessary to provide a page download for offline viewing of content that users may revisit repeatedly. Wap pages can not only display text, but also often show pictures. Some pages also contain audio or even video. How to complete the download needs to be analyzed according to different scenarios.
Scheme selection
In general, a WAP page that provides download capability is necessarily limited in the form of content it will display. If every page thrown in requires caching, it is difficult to ensure that the display is offline.
NSURLProtocol is used to implement caching
For simple pages, such as those containing only text and images, Hybrid can be implemented without the need. NSURLProtocol is an alternative, and its coverage can be much broader. NSURLProtocol is used to filter network requests. If a specific HTML, CSS, JS request or image request is found in the local cache data, the local data is used to package the response data of the network request. Otherwise, the corresponding network request is executed. In this way, even when the network is available, the local cache data is preferentially used, which not only completes the offline display of the page, but also effectively speeds up the loading of the page when the network is available. Naturally, this is the way many WAP page acceleration solutions work.
Hybrid based WAP page
For waP pages containing audio and video content, the client often takes over the presentation of these resources for user experience purposes. For example, when a page contains music, the user clicks on it and finds that it is being played by the client’s player. This is an example of a Hybrid application. A common implementation scheme is: the client provides the interface for the front-end to play audio. For all the audio in the WAP page, the front-end native writing method is abandoned, and the interface provided by the client is adopted. The implementation of this interface in the client side, naturally, is to tune up the client audio player and play the corresponding audio. This process will involve successful callback, synchronization between the client player and waP page, and many other problems, but this is not the focus of this article. The scenario discussed in this article that requires a full waP page download is based on this scenario.
The specific implementation
Page presentation scheme
As can be seen from the above example, the WAP page presented based on Hybrid solution not only requires the client to provide various capabilities for front-end invocation, but also requires the front-end to make corresponding invocation when writing the code. Both ends work together to achieve highly customized WAP pages. In the example above, the client provides an interface for image, audio, and video, so that the interaction of the corresponding content in the WAP page is left to the client’s native implementation. The implementation of the client interface, naturally, is the first to search in the local cache data, if the data has been downloaded, then use the local data, otherwise the corresponding network acquisition, so as to be compatible with the network and offline situation.
In addition to the above application of offline caching, there is also the advantage that content in the WebView can enjoy the native processing mode of the client. For example, the client implementation of the picture interface can be handed over to the network image asynchronous loading tool (SDWebImage or YYWebImage, etc.) used in the project, so that the image loading in webView and the image loading in the native scene can share the cache data, and the images loaded in the native scene. There is no need to repeat web fetching when presented in a WebView, and vice versa. Based on the principle of locality, this can achieve the effect of image loading acceleration to a certain extent (reduce repeated network requests).
Further optimization
In fact, in a highly customized WAP page scenario, we have strict control over the types of pages that can appear in a WebView. We can use content control to avoid external page jumps in WAP pages, and we can also use the corresponding proxy method of WebView to prohibit the types of jumps we do not want to appear, or use double protection to ensure that the current WebView container will only appear our customized content. Since the type of WAP page is limited, it naturally occurs that the same type of page is mostly generated by the front end using templates, and the HTML, CSS, JS resources used by the page are likely to be the same, or a limited number of copies, and it becomes feasible to package them directly with the client locally. When the corresponding URL is loaded, local resources are directly loaded.
For network requests in webView, the client can also take over, for example in your Hybrid framework, register an interface for the front-end to initiate network requests. All network requests on waP pages are sent through this interface. In this way, the client can do a lot of things, for example, NSURLProtocol can not intercept the network request initiated by WKWebview, using Hybrid mode to send to the client, can achieve the corresponding interception.
Based on the above scheme, the complete presentation flow of our WAP page looks like this: The client loads a URL in the WebView, judges that it meets the rules, and loads the local template HTML. The internal implementation of this page is to initiate a network request to obtain the specific page content through the network request interface provided by the client, and obtain the filled data to complete the display.
How do I determine which resources to download
We haven’t found a very efficient way for clients to determine what resources a particular WAP page will contain. Fortunately, most of the pages in this scenario are internally produced and highly customized, which makes it possible for the backend to provide resource statistics (page data is originally produced by the backend). Therefore, we adopt the solution that the backend provides corresponding interface support. According to the ID of the WAP page, the specific resources contained in the page can be obtained. When performing a user’s download behavior, the resource statistics interface is invoked using the corresponding page ID to obtain the resources contained in the page. This includes the page padding data in JSON format, as well as the URL of the media file. JSON data can be cached using a simple caching framework (such as YYCache). Images can be cached using the scene image caching framework. Audio and video files can be processed into regular file download tasks.
conclusion
- This article does not focus on how the specific Hybrid framework is implemented, but on providing a specific business scenario that can be implemented based on Hybrid.
- The scheme described in this paper is the technical implementation of the company’s internal scenarios. There will be unreasonable places, welcome to discuss.