HybridPageKit – library for newspaper reading applications

Tram Ho

As you all know, the article is a combination of HTML, CSS, JS, including paragraphs with images and videos intertwined together. To meet the display on many web and mobile web platforms, the mobile app must use Webview to download and render HTML, which is a must-have solution for newspaper reading applications.

Let’s learn a little bit about UIWebView and WKWebView.

1. UIWebView vs WKWebView

Stability

  • UIWebView has lots of WebCore, JavaScriptCore crashes, and system memory leaks that can cause OOM, which is a major danger to application stability.
  • WkWebView is based on an independent process, does not occupy application memory and does not lead to app crashes. So in terms of stability, WKWebView has more advantages.

Speed

  • WKWebView significantly optimizes the speed of JS through JIT, but for newspaper readers, the loading and rendering of WKWebView’s HTML is much slower than UIWebView.

Compatibility

  • NSURLProtocol, clear cache on iOS8, configure cookies and UA, execute JS asynchronously.
  • A series of issues has become the biggest challenge to replace WKWebView.

Ability of extension

  • WKWebView has more interfaces, more HTML and CSS support and more JS-friendly interaction.
  • At the same time, the constant updating of the API and the active community are great advantages in terms of long-term use.

With the use of HybridPageKit , the problems of WKWebView have been solved to a great extent and it has worked very well.

2. Combine WebView with other UIs

For newspaper reading applications, 1 WebView cannot meet complex interface and logic. You can see for example the following article: With the article with Google Ads, Video, Image, the WebView download and render UI as above is not realistic.

Here I will outline 2 ways to handle combining multiple UI together.

Use TableView

Principles:

  • Because there are many modules combined in the article such as related articles, comments .., so the easiest implementation is that these modules are handled by TableView.
  • To accomplish this, there are two ways as shown above: TableView is inserted into WebView based on contentInset and WebView is the TableView header.

Advantages:

  • The solution is relatively simple and easy to recognize the layout of each module.
  • At the same time, based on TableView it can easily handle flexible updating, adding, and removing modules. The combination with WebView is also smooth.

Defect:

  • This solution is difficult to reuse the UI and module logic. The layout of the UI depends on TableView’s mode and its flexibility.
  • With the increase of component types, different view types cannot be reused by the tableView cell.
  • At the same time, it also affects rendering of WebView or TableView, and difficulty in maintaining it later.
  • Moreover, using headers and insets is really hard to add to the UI at the top like pullToRefresh.

Use ScrollView

Principles:

  • This solution uses ScrollView as a container and components such as WebView and corresponding modules as subViews.
  • All subViews are not allowed to scroll and all scrolling events are handled in containers.
  • For subViews in scrollView if contentSize is smaller than the height of the screen it will be used as a normal view, otherwise it will be set to screen height and recalculate offset and frame.
  • It will automatically adjust the view related to the container frame and adjust contentOffset to achieve scroll effect.

Advantages:

  • This solution is completely independent from the implementation of each module, making the UI and logic reciprocal.
  • And the rendering of HTML is independent.
  • Modules are loaded and laid out flexibly, easy to manage and reuse.
  • It is easy to add and delete modules. Flexibility and reuse are greatly improved.

Defect

  • Because this solution needs to recalculate the scrollView offset, the frame and offset of the modules are very complicated.
  • Luckily, HybridPageKit handled this very well.

3. Display complex UIs in WebView

With complex components such as videos, images, music and even maps, it will significantly reduce the rendering speed of WebView and will increase the time for development and maintenance later.

Difficulties in user interface and complex interaction

  • For a better experience, posts often add more content like continuous video playback, maps, tap on photos to open full screen, detect QR codes …
  • The logical result increases CSS and JS, increasing communication between the app and the web; and large amounts use LocalStorage and HTTP buffers.
  • Therefore, with complex interfaces that only use webView to display will be very difficult and cause development and maintenance costs to increase later.

Display image

  • The simplest way to display images in WebView is to attach the <img> tags in the post, and it depends on the download and display of the webView itself.
  • However, the flexibility of this method is relatively low.
  • The application cannot properly control the download time, nor does it perform caching and cropping if necessary.
  • To simultaneously with flexibility and shorten image loading time, HybridPageKit has replaced all images in WebView into UIImageView.
  • It can reduce unnecessary processes and communication, greatly improving loading speed.

Replace all UIs in the webView to be native except for text

  • To reduce the cost of developing and maintaining complex UIs and complex interactive modules, reducing the communication logic between the Web and App, improving module display speed in WebView.
  • HybridPageKit has replaced all non-office components into native UIs.

Use empty div

  • Combined with templates and data from the server, all components are not text to map into div tags but are combined with IDs for later identification.
  • For data synchronization, the size of components can be set at the beginning or updated later.

Get the frame through JS when the rendering process is finished

  • When the webView render finishes, it will retrieve all the div tags with frames and ids through JS

Add native views

  • When JS returns all frames, the native components will also update the frame based on the id

4. Reuse components in ScrollView

  • After changing all non-text components into native components
  • The number of images, videos .. will increase a lot, so if you can not reuse the components, you will face two problems: performance and memory.
  • At the same time, to improve the user experience, it is necessary to calculate the position of each element when scrolling.

Ways to allow reuse in scrollView

Reuse components in WebView

  • ReusableNestingScrollview expands scrollate delegates to handle subView reuse
  • Therefore, the reuse and recovery of all subViews need not be inherited
  • Because the view needs to be reused, the data state of the view must be stored in the object.
  • It is not only easy to extend but also optimizes the logic of reuse.
  • And caching information like frames helps optimize render layout.

Reuse other components in ScrollView

  • After changing all non-text components to native and solved the reuse problem in webView.
  • We apply the deployment to other components in the scrollView like related posts and comments

This is the link framework: https://github.com/dequan1331/HybridPageKit The next article I will make a demo application to describe the practical use.

Share the news now

Source : Viblo