Developing an effective mashup app

Do you remember your first mobile phone? For me, it was the Nokia 3310, an indestructible “tube” that tirelessly delighted me with a meager set of entertainment in the form of snake games, WAP and wonderful monophonic ringtones. The industry has made great strides over the past thirty years. And that’s putting it mildly: mobile chips are close in performance to modern computers, and the two most popular systems at the moment – Android and iOS – provide almost limitless possibilities for creating applications for every taste.

Paying via NFC, ordering a taxi in just a couple of swipes, and even the same Instagram has become so tightly embedded in our lives that the need to create a mobile client for your business no longer raises questions. In this case, the standard for development is considered to be native applications. They work smoothly, have a familiar UI and UX, as well as access to a variety of hardware capabilities of the smartphone and its operating system. The main disadvantages of this approach include the need to have dedicated iOS and Android developers on the staff, the emergence of difficulties in organizing testing, and a longer release cycle compared to the web. We must not forget about segmentation: some users prefer to stay on old versions of the application, old versions of iOS and Android, they love their old phones. Therefore, a bug that was not found in the release, leaked to the side, resembles an earthquake with a long aftershock.

If you already have a team of experienced mobile developers and have established CI, then it seems that the choice is obvious. But there are often situations when the launch time of the functionality in production plays a decisive role, and constant updates do not benefit the application’s reputation. At least once in our life, each of us took out a loan, or at least seriously thought about it. Usually this process includes filling out a questionnaire. Let’s imagine that you have such a profile on your website and in your mobile application. And so the bank decided to free salary clients from half of the fields – this is certainly great, but it entails changes on the website, as well as in iOS and Android applications. Given our asynchronous release cycles, as well as the possibility of bugs during the update, there is a risk of getting three different questionnaires for an indefinite period. What if these changes need to be made frequently?

The obvious solution is hybrid… There are many frameworks that allow you to write code for both platforms at once: Flutter, React Native, Ionic, but their implementation into an existing project can cost significant time and effort. There is an easier way: by placing part of the functionality in the WebView, we can quickly and relatively cheaply reuse part of the logic already implemented on the site. Content downloaded from the web, in conjunction with native components, is sometimes completely indistinguishable from the native screen. This way, users will have access to new features simultaneously with the web version, and the mobile team will be able to work out a full-fledged native process in a less rigid time frame.

If you have taken the path of “hybrid”, it is important to understand when this decision is temporary and when it is permanent. The screen in the WebView, like any other, is part of ecosystem applications… When launching functionality with large business logic, you will have to invest significant time and resources to support it. But why, if everything has been laid out for a long time and works great?

50 shades of services

Testing for different browsers and resolutions is a common thing in front-end development. Now this checklist will also be added to the mobile application. It’s all about WebKit, a free web page rendering engine that runs all the most popular browsers. He is responsible for parsing HTML uniformly, constructing the DOM, creating window and document objects, working with CSS, as well as building layouts and positioning UI elements. However, with all the apparent convenience, it has a considerable number of versions, or, as they are also called, “ports”.

Approaches to managing rendering, decoding images and working with video may differ from one version to another; codec support is changing, the network layer is changing, and different JS engines are used. WebKit also allows you to enable or disable any functionality at compile time using compile-time feature flags, and even at runtime, when passing parameters on the command line or configuration. Add to all this the factors that depend on the hardware, and it becomes obvious: the browser on the phone will definitely differ from its desktop counterpart of the same name.

Thus, embedding a “browser on minimums” into the application before rolling out to production is still worth adding additional time to testing the screen, and best of all, the process.

WebView ≠ adaptive

If users are accustomed to swiping between tabs, they’ll expect the same behavior to be supported on a WebView screen. The same goes for native navigation between screens and UI elements (buttons, input fields, context menus, etc.).

From a UX and design perspective, the application process must remain consistent and the guidelines for developing user interface platforms must be followed. You can assume that creating a separate layout for WebView is an inevitable price to pay for the ability to instantly update functionality without being tied to mobile releases. To ensure that WebView functionality doesn’t hurt you, spend time building a base of UI components with the styles used in the application from the beginning.

Seamless process

Has the UI been tweaked and even the most nervous designer put the knife down? The new screen does not depend on others and does not require data entry? Then, perhaps, you can skip this point … But you’d better take your time.

It is important to take into account that the screen in the WebView should not lead the user to other pages of the site. Many applications store customer personal data and therefore require authentication. And everyone who once entered their personal account will expect that they will remain logged in and on the screen in WebView. Using the link interception mechanism, you can direct the user to the native login or registration process, and thus avoid unplanned script branches in the browser.

Throughout the user journey, it is often necessary to save progress and information received. When opening a hybrid screen, it will not be superfluous to pass everything that is needed to continue working in the link parameters. Real-time data exchange is easy to organize using callbacks. For example, using them, WebView can transmit information about the items that should be displayed in the context menu, and the native menu, in turn, will return the item that the user clicked on, and the browser will load the desired page.

Want to embed a screen into an existing process? No problem. But at the same time, the logic of the application must remain consistent, and the data must be consistent. The WebKit library in conjunction with JS tools, implemented interfaces on the Android side and the message handler on the iOS side are able to provide deep integration of the WebView screen and native code. You will be able to add native widgets on top of pages, manage their UI, add the desired behavior and customize the visibility.

The dark side of WebView

Starting with Android 10 and iOS 13, there is a functionality called “dark theme”. This is an alternative UI color scheme designed to take care of your eyes while using your phone at night. The WebKit library allows you to set the settings according to which the loaded page will be displayed in accordance with the theme currently set on the phone (recommended mode), always in a dark or light form. Note that adding dark theme support to a web page’s CSS by line @media (prefers-color-scheme: dark) will not give the desired result, since this setting affects only the controls – the scroll bar, zoom and zoom buttons, etc., but not the style of the content displayed inside the WebView.

if (WebViewFeature.isFeatureSupported(WebViewFeature.FORCEDARK)) {
    WebSettingsCompat.setForceDark(WebSettingsCompat.FORCEDARK_AUTO)
}

If your application has styled for a dark theme, that’s fine, but the screen in the WebView must then look the same.

Divide and rule

One of the most important indicators of the stability of mobile applications is the share of crash-free users and reviews in stores. And if earlier all the data on errors, logs and custom metrics could be found in Firebase or any other service you like, now debugging and collecting analytics will become somewhat more difficult. At the same time, user ratings will still reflect their attitude towards the product as a whole, regardless of what part of the work with the hybrid they had difficulties in. Analysis of each such case will now begin with identifying the source: an error in the native or the web, or in the integration. The solution could be segmenting user reviews by tags and transferring analytics to a single cross-platform service.

One of the popular services for monitoring application activity in the App Store and Google Play is AppFollow. It provides automatic markup of user reviews. To do this, you need to write down the rules according to which tags will be affixed. For example, complaints about bugs include reviews with the words “bug”, “error” or “does not work” in the text, as well as with a score of less than 3.

And for collecting analytics, ClickHouse, an open source Russian-developed DBMS designed to work with large amounts of data, is perfect. It is capable of efficiently processing queries in real time, while their syntax is as close as possible to classic SQL. In addition to the speed and low entry threshold for users, it is also worth noting the excellently implemented data compression and the absence of connection problems – the service has an active community, at the moment there are ready-made connectors for most popular programming languages. And if I still haven’t been able to convince you, then take a look leadership, acquaintance with the functionality will take just a couple of hours, and test data is included in the kit.

Summing up, it becomes clear that “quickly and relatively cheaply to launch in WebView” is a non-trivial task when it comes to large and well-tested features. But on the other hand, this approach is great for short-term promotions, a section with help information, dynamic feedback forms – in other words, for screens with frequently changing information that are not tied to the main application scenarios.

When choosing between running MVP in native and WebView, it is important to understand that the best decision is made only in the context of the task. Native SDKs allow you to effectively control the amount of memory used by the application, download files in the background, store large amounts of data locally, and also take advantage of all the hardware advantages of modern smartphones and iOS and Android systems. Requires a minimum Time To Market? The hybrid solution allows you to launch new functionality synchronously with the site, fix bugs quickly and simultaneously on all devices. However, if it is poorly executed, the user experience can be seriously affected.

So where is the golden mean? A WebView can perform well as a stub, however, as you know, nothing is more permanent than temporary. A great option would be to start developing the native version at the same time as the hybrid page. Mobile developers will be able to quickly immerse themselves in the context, fronts – to correct the layout correctly, users will receive the feature as soon as possible, and after the release the screen will already become native. Choose wisely, use the tools correctly, and the result will not be long in coming.

PS: And for those who can’t wait to add WebView to their applications, there is great news. The next article will be devoted to the implementation features, the interaction of web and native components, as well as testing hybrid screens. Stay tuned!