MobileUsing WebViews on Tablets with HD Screens

Using WebViews on Tablets with HD Screens

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

This article was re-printed with permission from Amazon Digital Services, Inc.

By E-dan Bloch, Solutions Architect for Amazon

The new Kindle Fire HD 7” and 8.9” tablets introduce high definition screens that provide a great opportunity for mobile app developers to deliver an improved user interface, high resolution images,and apps that take advantage of more “screen real estate”. While native layouts make use of these higher resolutions by default, layouts within WebViews may require some HTML adjustments to be made.

(ad)
Amazon Coins

WebView control may display pages that are logically longer and wider than the physical screen size, allowing users to pinch to zoom and scroll through a web page. To accommodate the difference in size, the WebView control takes two properties into consideration: the native view size (the size of the control itself) and the logical view port size (the size of the content currently visible within the control).

The viewport, with respect to the WebView control, is the area of the page currently visible to the user. The native Android layout engine controls the view size, and the HTML page determines the logical viewport size. For example, when the WebView displays a page that is zoomed in, the logical viewport size is smaller than the actual size of the control (hence the zooming). This can lead to seemingly unexpected behavior of web apps, especially when JavaScript is used to create the page’s layout.

There are two key properties that mobile app developers leveraging WebViews should be familiar with: the viewport metadata property and the android:theme property.

The “viewport” metadata property is represented as <meta name=”viewport” content=”…” />. Adding this entry to the <head> section of your HTML pages will allow you to better control how your pages are displayed on users’ devices. Control this property by setting its content attribute with the following descriptors:

height = [pixel_value | device-height],

width = [pixel_value | device-width ],

initial-scale = float_value,

maximum-scale = float_value,

minimum-scale = float_value,

user-scalable = [yes | no],

target-densitydpi =

[dpi_value | device-dpi | high-dpi | medium-dpi | low-dpi]

 

By default, the target-densitydpi descriptor assumes the medium-dpi value. For Kindle Fire HD devices, you should change this setting to high-dpi so that your content will display properly. Alternatively, you can use the device-dpivalue and have the WebView control determine the density dynamically according to the device being used. This automatic setting will cause the viewport to scale differently for each device’s pixel density.


 

To use this automatic setting, add the following line to the <head> section of the HTML page being viewed:

<meta name=”viewport” content=”target-densitydpi = device-dpi” />

 

In instances where a web page uses a fixed-size layout, or a purely relative (fluid) layout, we may also want to have the width and/or height descriptors set to device-width or device-height (respectively). Setting these values will set the logical size of the WebView to match that of the device being used. So the viewport property would look like this:

<meta name=”viewport” content=”target-densitydpi = device-dpi, width = device-width” />

 

Combined with the auto-density selection we get:

<meta name=”viewport” content=” target-densitydpi = device-dpi, target-densitydpi = device-dpi, width = device-width” />

 

To demonstrate the effect of the latter tag, here is a side-by-side comparison of a simple web page displaying different size values with and without it:

Default behavior vs. custom behavior

Notice how, in the example on the right, the ViewPort size matches the WebView size. The difference, in both examples, between the screen size and the WebView size are due to the status (above) and menu (below) bars.

The second property is the android:theme property. Although it relates to the Android activity itself, and not just the WebView control, it can impact the screen real estate that your apps use. A good example is full-screen browsing. The Kindle Fire’s soft-key menu provides developers with power over the amount of screen their app can use by allowing them to hide both the title bar and the menu buttons. To use this feature, you can add the android:theme attribute to the <application> or <activity> elements in your AndroidManifest.xml manifest file and set the appropriate theme. For example, you can use@android:style/Theme.NoTitleBar to hide the top title bar, or

@android:style/Theme.NoTitleBar.Fullscreen to hide both the title bar and the soft-key menu bar. For example, if you want your entire app to operate in full-screen, your AndroidManifest.xml file might look like this:

<application

  android_icon=”@drawable/icon”

  android_label=”@string/app_name”

  android_theme=”@android:style/Theme.NoTitleBar.Fullscreen”>…</application>

 

This last value gives you the most screen area to work with. However, this option should be used with care as it affects the user experience by minimizing standard controls such as the clock and battery indicator, as well as the “back”, “search”, and “home” buttons.

 

To demonstrate, here is a side-by-side comparison of the default theme versus the Fullscreen theme:

 

Default behavior vs. custom behavior

Notice how, in the example on the right, all buttons are hidden until the user taps on the pull-up button seen on the bottom.

 

For more information, please also see the  User Experience Guidelines.

(ad)

This article was re-printed with permission from Amazon Digital Services, Inc. This site does business with Amazon Digital Services, Inc.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories