WebView – Part 1 Capabilities and Limitations

1. It is possible to intercept the events in the WebView to overload many of the default behaviour e.g. we can overload the behaviour when Page loading is completed, similarly, loads of other events can be overloaded to customize the behaviour of WebView in specific circumstances.


2. Assets like Videos and Images can be referenced from HTML running in WebView; even the Assets from APK file can be loaded.


3. Assets can also be downloaded over internet and saved into Android device then these Assest can be loaded in HTML.


4. This Widget can be used to load and display HTML’s over the network just like normal web browser.


5. HTML’s that are saved on Android device can also be loaded in WebView.


6. HTML can also be dynamically generated and viewed in WebView, e.g. we can generate HTML based on certain parameter that depends on Time elapsed like we can use GPS and Time elapsed to calculate the distance covered and then display the results in format of Dynamically generated HTML into WebView.


7. HTML code can also be presented in Application resources inside the APK file, this approach can be used to display predetermined data in a formatted way using HTML and WebView

1. Its not easy to intercept the events generated by WebView component


2. There are many events that cannot be intercepted, and there is limitation in what behaviours can be overloaded, which limits the customization of this component and changing the default behaviour of this component difficult.


3. By default, a WebView provides no browser-like widgets, does not enable JavaScript and web page errors are ignored. If your application has such requirements it better to invoke Browser application than using WebView like this:

        Uri uri = Uri.parse("http://www.example.com");

        Intent intent = new Intent(Intent.ACTION_VIEW, uri);

        startActivity(intent);

4.      By default, requests by the HTML to open new windows are ignored.

5.      By default, requests by the HTML to open new windows are ignored

Building web pages to support different screen densities

• The window.devicePixelRatio DOM property. The value of this property specifies the default scaling factor used for the current device. For example, if the value of window.devicePixelRatio is "1.0", then the device is considered a medium density (mdpi) device and default scaling is not applied to the web page; if the value is "1.5", then the device is considered a high density device (hdpi) and the page content is scaled 1.5x; if the value is "0.75", then the device is considered a low density device (ldpi) and the content is scaled 0.75x. However, if you specify the "target-densitydpi" meta property (discussed below), then you can stop this default scaling behavior.


• The -webkit-device-pixel-ratio CSS media query. Use this to specify the screen densities for which this style sheet is to be used. The corresponding value should be either "0.75", "1", or "1.5", to indicate that the styles are for devices with low density, medium density, or high density screens, respectively. For example:

  rel="stylesheet" media="screen and (-webkit-device-pixel-ratio:1.5)" href="hdpi.css" />

• The target-densitydpi property for the viewport meta tag. You can use this to specify the target density for which the web page is designed, using the following values:


• device-dpi - Use the device's native dpi as the target dpi. Default scaling never occurs.


• high-dpi - Use hdpi as the target dpi. Medium and low density screens scale down as appropriate.


• medium-dpi - Use mdpi as the target dpi. High density screens scale up and low density screens scale down. This is also the default behavior.


• low-dpi - Use ldpi as the target dpi. Medium and high density screens scale up as appropriate.


• - Specify a dpi value to use as the target dpi (accepted values are 70-400).

 name="viewport" content="target-densitydpi=device-dpi" />