The objectives of this chapter are to

• Learn about general communication layers in hybrid applications on mobile OS
• Learn how hybrid applications work
• Learn about webview obstacles
• Provide recommendations

This chapter covers many of the good and the bad aspects of hybrid applications. It begins with how hybrid mobile applications work and then teaches the concept of webviews on mobile.

Mobile Devices

So far, the focus of this book has been on Android, iPhone, and Windows Phone. However, hybrid applications can be deployed on LG webOS, Fire OS, Blackberry, and so forth. Android has been considered our main target platform because it is has more users than the iPhone and Windows Phone. However, Microsoft technologies will be the focus of most of the server-side code.

Architecture

We can generalize layered and native application architecture by considering layers. The top layer in Figure 5-1 denotes the application created using the device’s preferred languages, for example, Java for Android.

The application framework can act as a mediator between OS, device features, and the application.

However, when it comes to hybrid applications, one very specific component plays an important role: the webview. We are going to see more about this component later in this chapter.

Based on the goal to provide native device features to the hybrid application, we may have different architectural approaches. We are going to discuss these approaches in this chapter.

Approach: Define a custom framework or plug-in—on top of WebKit or the Trident engine—that can be used further to access device features. This framework may use a channel or socket, through which messaging can take place, since the WebKit engine is not common to all. It works for Chrome and Safari, which means the Android and the iPhone. Analogically, this approach is more like plug-in development on a browser with permissions to access device features.

Approach: Use the webview control provided by the vendor. It can render the UI contents as well. Access to native device features is not directly available by using only a webview. External components are required. Some vendors—like Microsoft on Windows Phone 8—provide direct access to the device features using JavaScript without extra components.

The focus of this chapter is on the second approach only.

OS

A new OS version launch is always important from the hybrid application’s view. As discussed earlier, hybrid applications are dependent on the webview component. If there are webview implementation changes in an OS upgrade, this impacts the hybrid application. How?

Webview components work on a default browser engine. The following is a sample mapping:

• Android based webview uses Chrome uses the WebKit engine
• iPhone based webview uses Safari uses the WebKit engine
• Windows Phone based webview uses IE uses the Trident engine

So, when there is a change in the browser due to updates or a new OS version launch, a hybrid application may require attention. Earlier iOS and Android never used the default browser’s rendering engine as it is in a webview; rather, the engine or logic for the webview itself was different!

Back then, the performance difference for a hybrid application running in a webview vs. a default browser was considerable. Running a web application in the native browser was much faster than running the hybrid application in a webview.

In 2011, Facebook made a hybrid application. It was launched for iOS. But eventually, Facebook withdrew the application due to the slowdown of a UI webview-based rendering. Facebook later finalized a native approach.

Apple announced a WebKit-based rendering at the 2014 World Wide Developer Conference (WWDC). This forced hybrid application developers to do a check whether their app was running on iOS 8 (or above/below) before the application started. Developers continue to fear that “We can check version of iOS and verify that it’s 8.0 or greater, but what if Apple removes WKWebKit in iOS 9?

So the following code snippet (from http://floatlearning.com) is recommended for detecting the webview version:

if (NSClassFromString(@"WKWebView")) {
    _webView = [[WKWebView alloc] initWithFrame: [[self view] bounds]];
} else {
    _webView = [[UIWebView alloc] initWithFrame: [[self view] bounds]];
}

This code checks whether WKWebView is available on the current iOS, based on a non-OS element.

In 2014, Google announced the Android “Lollipop” version along with support for an updatable webview. This launch provided the boost required for hybrid application development. Since then, hybrid applications have been more consistent between devices and they give better performance. With this launch, Google also made remote debugging available for Android apps. More information is available at https://developer.chrome.com/devtools/docs/remote-debugging.

The following summarizes this discussion:

• Hybrid applications are now faster and even more recommended.
• While defining hybrid application around WKWebView, you have to consider the OS versions on which the application is going to work.

Let’s discuss how the application framework or platform works for hybrid applications. We’ll cover the core of hybrid application development: Apache Cordova.

Application Frameworks and Platforms

Apache Cordova is an open source hybrid mobile application framework. You can download it at https://cordova.apache.org.

The Apache Software Foundation launched Cordova in 2012. The entire code for a hybrid application based on Cordova is normally written in one single file named index.html. Cordova helps HTML and JavaScript code to work on webview. In order to access native features of the device, a plug-in is required.

As per Apache.org: “A plug-in is an interface available for Cordova and native components to communicate with each other.” There are many third-party plug-ins available that can be downloaded and used in the project based on the functionality required. These plug-ins are mentioned in the plug-in registry at http://cordova.apache.org/plug-ins/. You can author your own plug-in with helper files offered by Apache at https://cordova.apache.org/docs/en/5.1.1/guide/hybrid/plug-ins/index.html.

Figure 5-2 lists core device features supported by core plug-ins in Cordova.

How Do Hybrid Applications Work on Devices?

A webview is very generic name given to a browser-like control by the mobile OS. This control is used by native applications when the application wants to load and show local web content on the device.

Normally, hybrid application developers exploit the webview control to load web content from a local or a remote server. To code, we use JavaScript—dynamic behavior and data loading happens through JavaScript. Please note that webviews render the UI using native browser context, which means Safari matters for the iPhone, Chrome matters for the Android, and IE for Windows Phone. The launch of a new SDK along with a webview directly affects hybrid applications. New updates are made available by vendors less frequently.

Why a webview and not the browser directly? Browsers restrict calls to devices. A webview is a native component offered by the platform. A webview can have access to other native components and libraries and indirectly access device features.

The difficult part to understand is how a hybrid application developed using HTML and JavaScript gets access to native device features. The short answer is “through a webview.” The long answer is through the JavaScript calls made by the developer along with Cordova are intercepted by the webview. For example, JavaScript calls to a function like camera are converted into prompt commands, and then through JsBridge, with a webview, the actual camera can be accessed.

This is insane, as the mapping call from JavaScript to native may differ from vendor to vendor, like from Android to Apple. But, we are not concerned with this because Cordova does this brilliantly. Cordova has a lot of work already done.

Figure 5-3 describes the communication with native APIs using a webview. As you can see, a webview runs and hosts HTML5 and JavaScript code. Normally, HTML code is preferred in a single file. This means that multiple pages or views exist in the application and then a hide-show-div approach is preferred.

The usage of multiple files through MV* (Model-View-*) design approach may make it difficult to maintain a state of the data while navigation takes place. In MV*, the * represents “Controller” or “Presenter” or a similar component.

A Cordova JavaScript file is always required in the project. The entire program is based on a configuration XML file that conveys to the webview information about the device features referred to in the program.

Consider our first hybrid application. What if we need to use a core or a custom plug-in on top of Cordova? Can we configure the same using Telerik AppBuilder?

Of course! We can customize references to the application using AppBuilder. If an application is created on Cordova version 2.X, then, by default, all the core plug-ins are referred to in the application. Using AppBuilder, you aren’t able to modify the core plug-in architecture of the application.

However, if an application is created on Cordova 3.X, then enabling and disabling the plug-in is easily allowed through AppBuilder.

Kindly make a note that if you have several projects in the AppBuilder, then a plug-in addition is not global. These plug-ins need to be added individually in each project. Let’s look at how this can be done.

1. Open our first hybrid application project, Apress Project, using AppBuilder in the browser client. Let’s focus on Solution Explorer, as shown in Figure 5-4.

   

   Figure 5-4. AppBuilder in Solution Explorer

   We have a default reference to cordova.js in the project.

2. You can configure the plug-ins by double-clicking Properties. The location is highlighted in Figure 5-3. The configuration window is displayed, as shown in Figure 5-5. The highlighted portion denotes the availability of Cordova plug-in 3.X.

   

   Figure 5-5. Project configure properties

   As discussed earlier, you can customize (enable or disable) the core Cordova plug-ins if the application uses Cordova 3.X. This is normally done to minimize the deploy size as well as increase performance.

3. After clicking Properties, a configuration window appears (see Figure 5-6).

   

   Figure 5-6. Cordova plug-ins

   As you can see in Figure 5-6, custom plug-ins can be installed by importing.

   Plug-ins from the marketplace can also be installed and used in an application. The core plug-ins are shown in Figure 5-6. Marketplace plug-ins are shown in Figure 5-7.

   

   Figure 5-7. Marketplace plug-ins

   You don’t need to manually add any entries for core plug-ins in index.html and config.XML.

4. After enabling or disabling the required plug-ins, add or remove any third-party plug-ins. You can continue to use the AppBuilder as you did in the first hybrid application.

Some plug-ins may be vendor-specific. An example for storing data securely in local storage you can use iOS Keychain plug-in. It can be downloaded from http://plug-ins.telerik.com/cordova/plug-in/keychain.

It is always suggested to keep reference of those plug-ins that are required and used by a hybrid application. Remove whatever is nonsense and is not required.

Due to security flaws, avoid Android “Gingerbread” as a targeted OS. (More on this at http://www.techworm.net.)

If you want to load or show remote unknown contents into the app, using the in-browser plug-in is suggested. It loads remote contents using the native browser’s security model, restricting access to resources on the machine.

A list of well-known plug-ins is available at http://cordova.apache.org/docs/en/edge/cordova/plug-ins/plug-inapis.html.

Webview Hybrid Limitations

A webview in a hybrid application may surprise you with its strange behavior. Let’s look at the example of embedding video inside a hybrid application. You can use an HTML5-specific video tag. However, if you use iFrame to load a YouTube video, then it may render the video content outside the container. The memory required while using iFrame is on the high side. This kind of issue is considered a behavior on iOS.

Another problem is that while referring contents from a local file, memory usage can be on the higher side. On an iPad, you may use an iPad-based web server to get the content like CocoaHTTPServer. It can be downloaded from https://github.com/robbiehanson/CocoaHTTPServer.

Comparison: Native vs. Hybrid Applications

Table 5-1 is compares native and hybrid applications, listing only the core working architecture of either application type. The + and the – denote comparatively better or less favorable, respectively. These comparisons may help you choose between a native and a hybrid application.

However, if you consider the following factors, hybrid applications are far better in these aspects.

• Cost of development
• Time to market the application
• Resources availability in the market
• Reusability of the code
• Plug-in availability

Summary

This chapter discussed the importance of the webview and how hybrid applications work. It also focused on the Cordova plug-in, on top of which many plug-ins are built. Finally, it compared hybrid and native applications from the perspective of internals.

The next chapter discusses data access techniques in hybrid applications.