WebViews and HTML5 Containers
Until recently, web applications were restricted to browsers. Now, they can run on mobile devices (in a webview) and on the desktop (in an HTML5 container). The proliferation of mobile devices, the release of the Chromium Embedded Framework, and the emergence of Electron have all contributed to the widespread use of web technologies outside of a typical web browser.
The ChartIQ library can operate in any of these environments. All of the guidance and tutorials provided by our documentation applies, regardless of whether you're developing your application for browsers, mobile devices or desktop containers. This tutorial will:
- Introduce you to webviews and containers
- Discuss issues related to working with webviews/containers.
- Recommend resources for further reading.
First, let's clear up some terminology.
Webview vs Container
Webview: At the most basic level, a webview is simply a UI-less browser window configured to run in full screen. It's just a frame that delivers web content.
Container: A container is a platform that embeds Chromium into a native shell. The container allows a developer to build native apps without C++ or Java.
Communicating with WebViews and Containers
You will probably need to communicate between your webview and the native code that it's running within. Consider the case where you'd like to put charts into your existing native mobile application. If all that's required is a chart that displays up to date data, the task is simple. But as soon as you introduce UI that alters the chart state, you will need to pass instructions from the native app to the embedded webview; the webview may also need to communicate back to the native application when its state changes. The example below shows how to use a native iOS button to trigger a chart type change inside of a webview:
Sidebar: Advantages of Remote Deployment
When designing your application's architecture, you will need to decide how to manage its assets (files). You can either host them on a server, or bundle them with the application itself. While there are valid reasons to bundle your assets with your application, we believe that the pros of remote hosting generally outweigh the cons. Some of the benefits of remote hosting are:
- Upgrading our library becomes trivial. If the library is packaged with your application, you will need to release a new version before the library license expires. If your users don't upgrade their application, they could be stuck with an expired version of the library. If the library is hosted on your server, you simply need to swap out the files for your users to automatically be upgraded.
- Because it's so easy to swap out files on a server, the application can be upgraded as frequently as necessary. Shorter release cycles allow for incremental improvement; which in turn leads to less user confusion.
Special considerations when working with webviews/containers
Now that you know what webviews and containers are and how to communicate with them, let's talk about some of the things you need to consider when deploying an application inside of one.
ChartIQ Licensing for native apps
Trial versions of the ChartIQ library are mobile ready and will run on any mobile OS even if bundled with the application itself. So will the production versions when hosted remotely on a server. If you are planning on bundling the production version with your application, please let us know so we can send you a suitable package. The standard domain locked library will not work in this case. See 'Sidebar: Advantages of Remote Deployment' for details on these 2 approaches.
iOS WebViews do not automatically follow relative paths. You'll need to ensure that your files can be found by iOS. For more information about relative paths in iOS apps, see this tutorial. Or search for 'Add files and folders to a project' in the Apple xcode help site
You won't have a dev console immediately available. Debugging code running in webviews and containers requires special considering. For more information on remote debugging, check out our debugging tutorial.
Synchronous and asynchronous code
Here is sample code for creating a native to JS bridge:
Mobile specific library settings
By default, the cross-hair location will be slightly offset so a user can see where the cross-hair is instead of having render it right under their finger. This is done because in small devices, especially when displaying small candles the finger will cover a large area,losing track of where they are.
You can adjust the offsets by modifying the following parameters:
The following flags are available to identify devices:
Managing sliding and swiping:
Sometimes the chart will be embedded in a larger page that can be swiped up or down. To decide if you want the chart to respond to the swiping or let the page manage it, see the following settings:
- Browser Performance
- ChartIQ Java integration Documentation
- Going "all in" with HTML5 containers
- Github starter kits and sample applications
- What is a webview?
iOS provides two webviews - UIWebView, and WKWebView. WKWebView is based on WebKit, the same rendering engine that powers Safari and Chromium. We recommend using wkWebview because it includes just in time (JIT) compiling and therefore performs much better than the older UIWebView.
For building Android applications we strongly recommend using the Intel Crosswalk SDK. Crosswalk automatically bundles the latest Chromium build which improves performance on Android devices prior to version 4.4.
Here are some useful links: