Android/frameworks_base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

am 65e62f4f: docs: new web apps dev guides

Browse Source 
Merge commit '65e62f4f908394fc469cf535fef7c16035a428a2' into gingerbread

* commit '65e62f4f908394fc469cf535fef7c16035a428a2':
  docs: new web apps dev guides
This commit is contained in:
Scott Main
2010-10-08 15:43:44 -07:00
committed by Android Git Automerger
parent a4682ed754 65e62f4f90
commit d7170b2a68
11 changed files with 1021 additions and 69 deletions
Download Patch File Download Diff File Expand all files Collapse all files

76
docs/html/guide/developing/debug-tasks.jd
View File

@@ -40,10 +40,13 @@ your applications. Here are some tools that you'll use most often:</p>
your application, which can help you profile the performance of your application.</dd>
<dt><strong><a href="{@docRoot}guide/developing/tools/ddms.html#logcat">logcat</a></strong></dt>
<dd>Dumps a log of system
messages. The messages include a stack trace when the emulator throws an error,
messages. The messages include a stack trace when the device throws an error,
as well as {@link android.util.Log} messages you've written from your application. To run
logcat, execute <code>adb logcat</code> or, from DDMS, select <strong>Device > Run
logcat</strong>.
logcat, execute <code>adb logcat</code> from your Android SDK {@code tools/} directory or,
from DDMS, select <strong>Device > Run
logcat</strong>. When using the <a href="{@docRoot}sdk/eclipse-adt.html">ADT plugin for
Eclipse</a>, you can also view logcat messages by opening the Logcat view, available from
<strong>Window > Show View > Other > Android > Logcat</strong>.
<p>{@link android.util.Log} is a logging
class you can use to print out messages to the logcat. You can read messages
in real time if you run logcat on DDMS (covered next). Common logging methods include:
@@ -148,72 +151,7 @@ following options (among others):</p>
<h2 id="DebuggingWebPages">Debugging Web Pages</h2>
<p>If you're developing a web application for Android devices, you can debug your JavaScript in the
Android Browser using the Console APIs, which will output messages to logcat. If you're familiar
debugging web pages with Firefox's FireBug or WebKit's Web Inspector, then you're probably familiar
with the Console APIs. The Android Browser (and the {@link android.webkit.WebChromeClient}) supports
most of the same APIs.</p>
<p>When you call a function from the Console APIs (in the DOM's {@code window.console} object),
you will see the output in logcat as a warning. For example, if your web page
executes the following JavaScript:</p>
<pre class="no-pretty-print">
console.log("Hello World");
</pre>
<p>Then the logcat output from the Android Browser will look like this:</p>
<pre class="no-pretty-print">
W/browser ( 202): Console: Hello World http://www.example.com/hello.html :82
</pre>
<p>All Console messages from the Android Browser are tagged with the name "browser" on Android
platforms running API Level 7 or higher. On platforms running API Level 6 or lower, Browser
messages are tagged with the name "WebCore". The Android Browser also formats console messages
with the log message
preceded by "Console:" and then followed by the address and line number where the
message occurred. (The format for the address and line number will appear different from the example
above on platforms running API Level 6 or lower.)</p>
<p>The Android Browser (and {@link android.webkit.WebChromeClient}) does not implement all of the
Console APIs provided by Firefox or other WebKit-based browsers. Primarily, you need to depend
on the basic text logging functions:</p>
<ul>
<li>{@code console.log(String)}</li>
<li>{@code console.info(String)}</li>
<li>{@code console.warn(String)}</li>
<li>{@code console.error(String)}</li>
</ul>
<p>Although the Android Browser may not fully implement other Console functions, they will not raise
run-time errors, but may not behave the same as they do on other desktop browsers.</p>
<p>If you've implemented a custom {@link android.webkit.WebView} in your application, then in order
to receive messages that are sent through the Console APIs, you must provide a {@link
android.webkit.WebChromeClient} that implements the {@link
android.webkit.WebChromeClient#onConsoleMessage(String,int,String) onConsoleMessage()} callback
method. For example, assuming that the {@code myWebView} field references the {@link
android.webkit.WebView} in your application, you can log debug messages like this:</p>
<pre>
myWebView.setWebChromeClient(new WebChromeClient() {
public void onConsoleMessage(String message, int lineNumber, String sourceID) {
Log.d("MyApplication", message + " -- From line " + lineNumber + " of " + sourceID);
}
});
</pre>
<p>The {@link android.webkit.WebChromeClient#onConsoleMessage(String,int,String)
onConsoleMessage()} method will be called each time one of the Console methods is called from
within your {@link android.webkit.WebView}.</p>
<p>When the "Hello World" log is executed through your {@link android.webkit.WebView}, it will
now look like this:</p>
<pre class="no-pretty-print">
D/MyApplication ( 430): Hello World -- From line 82 of http://www.example.com/hello.html
</pre>
<p class="note"><strong>Note:</strong> The {@link
android.webkit.WebChromeClient#onConsoleMessage(String,int,String) onConsoleMessage()} callback
method was added with API Level 7. If you are using a custom {@link
android.webkit.WebView} on a platform running API Level 6 or lower, then your Console messages will
automatically be sent to logcat with the "WebCore" logging tag.</p>
<p>See the <a href="{@docRoot}guide/webapps/debugging.html">Debugging Web Apps</a> document.</p>
<h2 id="toptips">Top Debugging Tips</h2>

19
docs/html/guide/guide_toc.cs
View File

@@ -450,6 +450,25 @@
</ul>
</li>
<li>
<h2><span class="en">Web Applications</span>
</h2>
<ul>
<li><a href="<?cs var:toroot ?>guide/webapps/targetting.html">
<span class="en">Targetting Android Devices</span>
</a> <span class="new">new!</span></li>
<li><a href="<?cs var:toroot ?>guide/webapps/webview.html">
<span class="en">Building Web Apps in WebView</span>
</a> <span class="new">new!</span></li>
<li><a href="<?cs var:toroot ?>guide/webapps/debugging.html">
<span class="en">Debugging Web Apps</span>
</a> <span class="new">new!</span></li>
<li><a href="<?cs var:toroot ?>guide/webapps/best-practices.html">
<span class="en">Best Practices for Web Apps</span>
</a> <span class="new">new!</span></li>
</ul>
</li>
<li>
<h2><span class="en">Appendix</span>
<span class="de" style="display:none">Anhang</span>

90
docs/html/guide/webapps/best-practices.jd Normal file
View File

@@ -0,0 +1,90 @@
page.title=Best Practices for Web Apps
@jd:body
<style>
.bold li {
font-weight:bold;
}
.bold li * {
font-weight:normal;
}
</style>
<p>Developing web pages and web applications for mobile devices presents a different set of
challenges compared to developing a web page for the typical
desktop web browser. To help you get started, the following is a list of practices you should
follow in order to provide the most effective web application for Android and other mobile
devices.</p>
<ol class="bold">
<li>Redirect mobile devices to a dedicated mobile version of your web site
<p>There are several ways you can redirect requests to the mobile version of your web site, using
server-side redirects. Most often, this is done by "sniffing" the User Agent
string provided by the web browser. To determine whether to serve a mobile version of your site, you
should simply look for the "mobile" string in the User Agent, which matches a wide variety of mobile
devices. If necessary, you can also identify the specific operating system in the User Agent string
(such as "Android 2.1").</p>
</li>
<li>Use a valid markup DOCTYPE that's appropriate for mobile devices
<p>The most common markup language used for mobile web sites is <a
href="http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/">XHTML Basic</a>. This standard
ensures specific markup for your web site that works best on mobile devices. For instance, it does
not allow HTML frames or nested tables, which perform poorly on mobile devices. Along with the
DOCTYPE, be sure to declare the appropriate character encoding for the document (such as
UTF-8).</p>
<p>For example:</p>
<pre>
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd"&gt;
</pre>
<p>Also be sure that your web page markup is valid against the declared DOCTYPE. Use a
validator, such as the one available at
<a href="http://validator.w3.org/">http://validator.w3.org</a>.</p>
</li>
<li>Use viewport meta data to properly resize your web page
<p>In your document {@code &lt;head&gt;}, you should provide meta data that specifies how you
want the browser's viewport to render your web page. For example, your viewport meta data can
specify the height and width for the browser's viewport, the initial web page scale and even the
target screen density.</p>
<p>For example:</p>
<pre>
&lt;meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no"&gt;
</pre>
<p>For more information about how to use viewport meta data for Android-powered devices, read <a
href="{@docRoot}guide/webapps/targetting.html">Targetting Android Devices</a>.</p>
</li>
<li>Avoid multiple file requests
<p>Because mobile devices typically have a connection speed far slower than a desktop
computer, you should make your web pages load as fast as possible. One way to speed it up is to
avoid loading extra files such as stylesheets and script files in the {@code
&lt;head&gt;}. Instead, provide your CSS and JavaScript directly in the &lt;head&gt; (or
at the end of the &lt;body&gt;, for scripts that you don't need until the page is loaded).
Alternatively, you should optimize the size and speed of your files by compressing them with tools
like <a href="http://code.google.com/p/minify/">Minify</a>.</p>
</li>
<li>Use a vertical linear layout
<p>Avoid the need for the user to scroll left and right while navigating your web
page. Scrolling up and down is easier for the user and makes your web page simpler.</p>
</li>
</ol>
<p>For a more thorough guide to creating great mobile web applications, see the W3C's <a
href="http://www.w3.org/TR/mobile-bp/">Mobile Web Best Practices</a>. For other guidance on
improving the speed of your web site (for mobile and desktop), see Yahoo!'s guide to <a
href="http://developer.yahoo.com/performance/index.html#rules">Exceptional Performance</a> and
Google's speed tutorials in <a href="http://code.google.com/speed/articles/">Let's make the web
faster</a>.</p>

158
docs/html/guide/webapps/debugging.jd Normal file
View File

@@ -0,0 +1,158 @@
page.title=Debugging Web Apps
@jd:body
<div id="qv-wrapper">
<div id="qv">
<h2>Quickview</h2>
<ul>
<li>You can debug your web app using console methods in JavaScript</li>
<li>If debugging in a custom WebView, you need to implement a callback method to handle debug
messages</li>
</ul>
<h2>In this document</h2>
<ol>
<li><a href="#Browser">Using Console APIs in the Android Browser</a></li>
<li><a href="#WebView">Using Console APIs in WebView</a></li>
</ol>
<h2>See also</h2>
<ol>
<li><a href="{@docRoot}guide/developing/debug-tasks.html">Debugging Tasks</a></li>
</ol>
</div>
</div>
<p>If you're developing a web application for Android, you can debug your JavaScript
using the {@code console} JavaScript APIs, which output messages to logcat. If you're familiar with
debugging web pages with Firebug or Web Inspector, then you're probably familiar
with using {@code console} (such as {@code console.log()}). Android's WebKit framework supports most
of the same APIs, so you can receive logs from your web page when debugging in Android's Browser
or in your own {@link android.webkit.WebView}.</p>
<h2 id="Browser">Using Console APIs in the Android Browser</h2>
<div class="sidebox-wrapper">
<div class="sidebox">
<h2>Logcat</h2>
<p>Logcat is a tool that dumps a log of system messages. The messages include a stack trace when
the device throws an error, as well as log messages written from your application and
those written using JavaScript {@code console} APIs.</p>
<p>To run logcat and view messages, execute
{@code adb logcat} from your Android SDK {@code tools/} directory, or, from DDMS, select
<strong>Device > Run logcat</strong>. When using the <a href="{@docRoot}sdk/eclipse-adt.html">ADT
plugin for Eclipse</a>, you can also view logcat messages by opening the Logcat view, available from
<strong>Window > Show View > Other > Android > Logcat</strong>.</p>
<p>See <a href="{@docRoot}guide/developing/debug-tasks.html">Debugging
Tasks</a> for more information about logcat.</p>
</div>
</div>
<p>When you call a {@code console} function (in the DOM's {@code window.console} object),
the output appears in logcat. For example, if your web page executes the following
JavaScript:</p>
<pre>
console.log("Hello World");
</pre>
<p>Then the logcat message looks something like this:</p>
<pre class="no-pretty-print">
Console: Hello World http://www.example.com/hello.html :82
</pre>
<p>The format of the message might appear different depending on which version of Android you're
using. On Android 2.1 and higher, console messages from the Android Browser
are tagged with the name "browser". On Android 1.6 and lower, Android Browser
messages are tagged with the name "WebCore".</p>
<p>Android's WebKit does not implement all of the console APIs available in other desktop browsers.
You can, however, use the basic text logging functions:</p>
<ul>
<li>{@code console.log(String)}</li>
<li>{@code console.info(String)}</li>
<li>{@code console.warn(String)}</li>
<li>{@code console.error(String)}</li>
</ul>
<p>Other console functions don't raise errors, but might not behave the same as what you
expect from other web browsers.</p>
<h2 id="WebView">Using Console APIs in WebView</h2>
<p>If you've implemented a custom {@link android.webkit.WebView} in your application, all the
same console APIs are supported when debugging your web page in WebView. On Android
1.6 and lower, console messages are automatically sent to logcat with the
"WebCore" logging tag. If you're targetting Android 2.1 (API Level 7) or higher, then you must
provide a {@link android.webkit.WebChromeClient}
that implements the {@link android.webkit.WebChromeClient#onConsoleMessage(String,int,String)
onConsoleMessage()} callback method, in order for console messages to appear in logcat.</p>
<p>Additionally, the {@link
android.webkit.WebChromeClient#onConsoleMessage(String,int,String)} method introduced in API
Level 7 has been deprecated in favor of {@link
android.webkit.WebChromeClient#onConsoleMessage(ConsoleMessage)} in API Level 8.</p>
<p>Whether you're developing for Android 2.1 (API Level 7) or Android 2.2 (API Level 8 or
greater), you must implement {@link android.webkit.WebChromeClient} and override the appropriate
{@link
android.webkit.WebChromeClient#onConsoleMessage(String,int,String) onConsoleMessage()} callback
method. Then, apply the {@link android.webkit.WebChromeClient} to your {@link
android.webkit.WebView} with {@link android.webkit.WebView#setWebChromeClient(WebChromeClient)
setWebChromeClient()}.
<p>Using API Level 7, this is how your code for {@link
android.webkit.WebChromeClient#onConsoleMessage(String,int,String)} might look:</p>
<pre>
WebView myWebView = (WebView) findViewById(R.id.webview);
myWebView.setWebChromeClient(new WebChromeClient() {
public void onConsoleMessage(String message, int lineNumber, String sourceID) {
Log.d("MyApplication", message + " -- From line "
+ lineNumber + " of "
+ sourceID);
}
});
</pre>
<p>With API Level 8 or greater, your code for {@link
android.webkit.WebChromeClient#onConsoleMessage(ConsoleMessage)} might look like this:</p>
<pre>
WebView myWebView = (WebView) findViewById(R.id.webview);
myWebView.setWebChromeClient(new WebChromeClient() {
public boolean onConsoleMessage(ConsoleMessage cm) {
Log.d("MyApplication", cm.{@link android.webkit.ConsoleMessage#message()} + " -- From line "
+ cm.{@link android.webkit.ConsoleMessage#lineNumber()} + " of "
+ cm.{@link android.webkit.ConsoleMessage#sourceId()} );
return true;
}
});
</pre>
<p>The {@link android.webkit.ConsoleMessage} also includes a {@link
android.webkit.ConsoleMessage.MessageLevel MessageLevel} to indicate the type of console message
being delivered. You can query the message level with {@link
android.webkit.ConsoleMessage#messageLevel()} to determine the severity of the message, then
use the appropriate {@link android.util.Log} method or take other appropriate actions.</p>
<p>Whether you're using {@link
android.webkit.WebChromeClient#onConsoleMessage(String,int,String)} or {@link
android.webkit.WebChromeClient#onConsoleMessage(ConsoleMessage)}, when you execute a console method
in your web page, Android calls the appropriate {@link
android.webkit.WebChromeClient#onConsoleMessage(String,int,String)
onConsoleMessage()} method so you can report the error. For example, with the example code above,
a logcat message is printed that looks like this:</p>
<pre class="no-pretty-print">
Hello World -- From line 82 of http://www.example.com/hello.html
</pre>

419
docs/html/guide/webapps/targetting.jd Normal file
View File

@@ -0,0 +1,419 @@
page.title=Targetting Android Devices
@jd:body
<div id="qv-wrapper">
<div id="qv">
<h2>Quickview</h2>
<ul>
<li>You can target your web page for different screens using viewport metadata, CSS, and
JavaScript</li>
<li>Techniques in this document work for Android 2.0 and greater</li>
</ul>
<h2>In this document</h2>
<ol>
<li><a href="#Metadata">Using Viewport Metadata</a>
<ol>
<li><a href="#ViewportSize">Defining the viewport size</a></li>
<li><a href="#ViewportScale">Defining the viewport scale</a></li>
<li><a href="#ViewportDensity">Defining the viewport target density</a></li>
</ol>
</li>
<li><a href="#DensityCSS">Targetting Device Density with CSS</a></li>
<li><a href="#DensityJS">Targetting Device Density with JavaScript</a></li>
</ol>
</div>
</div>
<p>If you're developing a web application for Android or redesigning one for mobile devices, you
should account for some factors that affect the way the Android Browser renders your web page by
default. There are two fundamental factors that you should account for:</p>
<dl>
<dt>The size of the viewport and scale of the web page</dt>
<dd>When the Android Browser loads a web page, the default behavior is to load the
page in "overview mode," which provides a zoomed-out perspective of the web page. You can override
this behavior for your web page by defining the default dimensions of the viewport or the initial
scale of the viewport. You can also control how much the user can zoom in and out of your web
page, if at all.
<p>However, the user can also disable overview mode in the
Browser settings, so you should not assume that your page will load in overview mode. You
should instead customize the viewport size and/or scale as appropriate for your page.</p></dd>
<dt>The device's screen density</dt>
<dd>The screen density (the number of pixels per inch) on an Android-powered device affects
the resolution and size at which a web page is displayed. (There are three screen density
categories: low, medium, and high.) The Android Browser compensates for variations in the screen
density by scaling a web page so that all devices display the web page at the same perceivable size
as a medium-density screen. If graphics are an important element of your web design, you
should pay close attention to the scaling that occurs on different densities, because image scaling
can produce artifacts (blurring and pixelation).
<p>To provide the best visual representation on all
screen densities, you should control how scaling occurs by providing viewport metadata about
your web page's target screen density and providing alternative graphics for different screen
densities, which you can apply to different screens using CSS or JavaScript.</p></dd>
</dl>
<p>The rest of this document describes how you can account for these effects, and how to target
your web page for specific screen configurations.</p>
<p class="note"><strong>Note:</strong> The features described in this document are supported
by the Android Browser application on Android 2.0 and greater. Third-party web browsers running on
Android might not support these techniques for controlling the viewport size and targetting
screen densities.</p>
<h2 id="Metadata">Using Viewport Metadata</h2>
<p>The viewport is the area in which the Android Browser
draws a web page. Although the viewport's visible area matches the size of the screen,
the viewport has its own dimensions that determine the number of pixels available to a web page.
That is, the number of pixels available to a web page before it exceeds the screen area is
defined by the dimensions of the viewport,
not the dimensions of the device screen. For example, although a device screen might have a width of
480 pixels, the viewport can have a width of 800 pixels, so that a web page designed to be 800
pixels wide is completely visible on the screen.</p>
<p>You can define properties of the viewport for your web page using the {@code "viewport"}
property in an HTML {@code &lt;meta&gt;} tag (which must
be placed in your document {@code &lt;head&gt;}). You can define multiple viewport properties in the
{@code &lt;meta&gt;} tag's {@code content} attribute. For example, you can define the height and
width of the viewport, the initial scale of the page, and the target screen density.
Each viewport property in the {@code content} attribute must be separated by a comma.</p>
<p>For example, the following snippet from an HTML document specifies that the viewport width
should exactly match the device screen width and that the ability to zoom should be disabled:</p>
<pre>
&lt;head&gt;
&lt;title&gt;Example&lt;/title&gt;
&lt;meta name="viewport" content="width=device-width, user-scalable=no" /&gt;
&lt;/head&gt;
</pre>
<p>That's an example of just two viewport properties. The following syntax shows all of the
supported viewport properties and the general types of values accepted by each one:</p>
<pre>
&lt;meta name="viewport"
content="
<b>height</b> = [<em>pixel_value</em> | device-height] ,
<b>width</b> = [<em>pixel_value</em> | device-width ] ,
<b>initial-scale</b> = <em>float_value</em> ,
<b>minimum-scale</b> = <em>float_value</em> ,
<b>maximum-scale</b> = <em>float_value</em> ,
<b>user-scalable</b> = [yes | no] ,
<b>target-densitydpi</b> = [<em>dpi_value</em> | device-dpi |
high-dpi | medium-dpi | low-dpi]
" /&gt;
</pre>
<p>The following sections discuss how to use each of these viewport properties and exactly what the
accepted values are.</p>
<div class="figure" style="width:300px">
<img src="{@docRoot}images/webapps/compare-default.png" alt="" height="300" />
<p class="img-caption"><strong>Figure 1.</strong> A web page with no viewport metadata and an
image that's 320 pixels wide (the viewport is 800 pixels wide, by default).</p>
</div>
<div class="figure" style="width:300px">
<img src="{@docRoot}images/webapps/compare-width400.png" alt="" height="300" />
<p class="img-caption"><strong>Figure 2.</strong> A web page with viewport {@code width=400}
(the image in the web page is 320 pixels wide).</p>
</div>
<h3 id="ViewportSize">Defining the viewport size</h3>
<p>Viewport's {@code height} and {@code width} properties allow you to specify the size of the
viewport (the number of pixels available to the web page before it goes off screen). By default, the
Android Browser's minimum viewport width is 800 pixels, so if your web
page specifies its size to be 320 pixels wide, then your page renders smaller than the visible
screen (even if the physical screen is 320 pixels wide, because the viewport simulates a
drawable area that's 800 pixels wide), as shown in figure 1. So, you should explicitly define the
viewport {@code width} to match the width for which you have designed your web page.</p>
<p class="note"><strong>Note:</strong> Width values that are greater than 10,000 are ignored and
values less than (or equal to) 320 result in a value equal to the device-width. Height values that
are greater then 10,000 or less than 200 are also ignored.</p>
<p>For example, if your web page is designed to be exactly 320 pixels wide, then you might
want to specify that for the viewport width:</p>
<pre>
&lt;meta name="viewport" content="width=320" /&gt;
</pre>
<p>In this case, your web page exactly fits the screen width, because the web page width and
viewport width are the same.</p>
<p>To demonstrate how this property affects the size of
your web page, figure 2 shows a web page that contains an image that's 320 pixels wide, but with the
viewport width set to 400.</p>
<p class="note"><strong>Note:</strong> If you set the viewport width to match your web page width
and the device screen width does <em>not</em> match those dimensions, then the web page
still fits the screen even if the device has a high or low-density screen, because the
Android Browser scales web pages to match the perceived size on a medium-density
screen, by default (as you can see in figure 2, when comparing the hdpi device to the mdpi device).
Screen densities are discussed more in <a href="#ViewportDensity">Defining the viewport target
density</a>.</p>
<h4>Automatic sizing</h4>
<p>As an alternative to specifying the viewport dimensions with exact pixels, you can set the
viewport size to always match the dimensions of the device screen, by defining the
viewport properties {@code height}
and {@code width} with the values {@code device-height} and {@code device-width}, respectively. This
is appropriate when you're developing a web application that has a fluid width (not fixed width),
but you want it to appear as if it's fixed (to perfectly fit every screen as
if the web page width is set to match each screen). For example:</p>
<pre>
&lt;meta name="viewport" content="width=device-width" /&gt;
</pre>
<p>This results in the viewport width matching whatever the current screen width is, as shown in
figure 3. It's important to notice that, this results in images being scaled to fit the screen
when the current device does not match the <a href="#ViewportDensity">target
density</a>, which is medium-density if you don't specify otherwise. As a result, the image
displayed on the high-density device in figure 3 is scaled up in order to match the width
of a screen with a medium-density screen.</p>
<div class="figure" style="width:300px">
<img src="{@docRoot}images/webapps/compare-initialscale.png" alt="" height="300" />
<p class="img-caption"><strong>Figure 3.</strong> A web page with viewport {@code
width=device-width} <em>or</em> {@code initial-scale=1.0}.</p>
</div>
<p class="note"><strong>Note:</strong> If you instead want {@code
device-width} and {@code device-height} to match the physical screen pixels for every device,
instead of scaling your web page to match the target density, then you must also include
the {@code target-densitydpi} property with a value of {@code device-dpi}. This is discussed more in
the section about <a href="#ViewportDensity">Defining the viewport density</a>. Otherwise, simply
using {@code device-height} and {@code device-width} to define the viewport size makes your web page
fit every device screen, but scaling occurs on your images in order to adjust for different screen
densities.</p>
<h3 id="ViewportScale">Defining the viewport scale</h3>
<p>The scale of the viewport defines the level of zoom applied to the web page. Viewport
properties allow you to specify the scale of your web page in the following ways:</p>
<dl>
<dt>{@code initial-scale}</dt>
<dd>The initial scale of the page. The value is a float that indicates a multiplier for your web
page size, relative to the screen size. For example, if you set the initial scale to "1.0" then the
web page is displayed to match the resolution of the <a href="#ViewportDensity">target
density</a> 1-to-1. If set to "2.0", then the page is enlarged (zoomed in) by a factor of 2.
<p>The default initial scale is calculated to fit the web page in the viewport size.
Because the default viewport width is 800 pixels, if the device screen resolution is less than
800 pixels wide, the initial scale is something less than 1.0, by default, in order to fit the
800-pixel-wide page on the screen.</p></dd>
<dt>{@code minimum-scale}</dt>
<dd>The minimum scale to allow. The value is a float that indicates the minimum multiplier for
your web page size, relative to the screen size. For example, if you set this to "1.0", then the
page can't zoom out because the minimum size is 1-to-1 with the <a href="#ViewportDensity">target
density</a>.</dd>
<dt>{@code maximum-scale}</dt>
<dd>The maximum scale to allow for the page. The value is a float that indicates the
maximum multiplier for your web page size,
relative to the screen size. For example, if you set this to "2.0", then the page can't
zoom in more than 2 times the target size.</dd>
<dt>{@code user-scalable}</dt>
<dd>Whether the user can change the scale of the page at all (zoom in and out). Set to {@code yes}
to allow scaling and {@code no} to disallow scaling. The default is {@code yes}. If you set
this to {@code no}, then the {@code minimum-scale} and {@code maximum-scale} are ignored,
because scaling is not possible.</dd>
</dl>
<p>All scale values must be within the range 0.01&ndash;10.</p>
<p>For example:</p>
<pre>
&lt;meta name="viewport" content="initial-scale=1.0" /&gt;
</pre>
<p>This metadata sets the initial scale to be full sized, relative to the viewport's target
density.</p>
<h3 id="ViewportDensity">Defining the viewport target density</h3>
<p>The density of a device's screen is based on the screen resolution. There are three screen
density categories supported by Android: low (ldpi), medium (mdpi), and high (mdpi). A screen
with low density has fewer available pixels per inch, whereas a screen with high density has more
pixels per inch (compared to a medium density screen). The Android Browser targets a medium density
screen by default.</p>
<div class="figure" style="width:300px">
<img src="{@docRoot}images/webapps/compare-initialscale-devicedpi.png" alt="" height="300" />
<p class="img-caption"><strong>Figure 4.</strong> A web page with viewport {@code
width=device-width} and {@code target-densitydpi=device-dpi}.</p>
</div>
<p>Because the default target density is medium, when users have a device with a low or high density
screen, the Android Browser scales web pages (effectively zooms the pages) so they display at a
size that matches the perceived appearance on a medium density screen. Specifically, the Android
Browser applies approximately 1.5x scaling to web pages on a high density screen
(because its screen pixels are smaller) and approximately 0.75x scaling to pages on a low density
screen (because its screen pixels are bigger).</p>
<p>Due to this default scaling, figures 1, 2, and 3 show the example web page at the same physical
size on both the high and medium density device (the high-density device shows the
web page with a default scale factor that is 1.5 times larger than the actual pixel resolution, to
match the target density). This can introduce some undesirable artifacts in your images.
For example, although an image appears the same size on a medium and high-density device, the image
on the high-density device appears more blurry, because the image is designed to be 320 pixels
wide, but is drawn with 480 pixels.</p>
<p>You can change the target screen density for your web page using the {@code target-densitydpi}
viewport property. It accepts the following values:</p>
<ul>
<li><code>device-dpi</code> - Use the device's native dpi as the target dpi. Default scaling never
occurs.</li>
<li><code>high-dpi</code> - Use hdpi as the target dpi. Medium and low density screens scale down
as appropriate.</li>
<li><code>medium-dpi</code> - Use mdpi as the target dpi. High density screens scale up and low
density screens scale down. This is the default target density.</li>
<li><code>low-dpi</code> - Use ldpi as the target dpi. Medium and high density screens scale up
as appropriate.</li>
<li><em><code>&lt;value&gt;</code></em> - Specify a dpi value to use as the target dpi. Values must
be within the range 70&ndash;400.</li>
</ul></p>
<p>For example, to prevent the Android Browser from scaling of your web page for different screen
densities, set
the {@code target-densitydpi} viewport property to {@code device-dpi}. When you do, the Android
Browser does not scale the page and, instead, displays your web page to match the current screen
density. In this case, you should also define the viewport width to match the device width, so your
web page naturally fits the screen size. For example:</p>
<pre>
&lt;meta name="viewport" content="target-densitydpi=device-dpi, width=device-width" /&gt;
</pre>
<p>Figure 4 shows a web page using these viewport settings&mdash;the high-density device
now displays the page smaller because its physical pixels are smaller than those on the
medium-density device, so no scaling occurs and the 320-pixel-wide image is drawn using exactly 320
pixels on both screens. (This is how you should define your viewport if
you want to customize your web page based on screen density and provide different image assets for
different densities, <a href="#DensityCSS">with CSS</a> or
<a href="#DensityJS">with JavaScript</a>.)</p>
<h2 id="DensityCSS">Targetting Device Density with CSS</h2>
<p>The Android Browser supports a CSS media feature that allows you to create styles for specific
screen densities&mdash;the <code>-webkit-device-pixel-ratio</code> CSS media feature. The
value you apply to this feature 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.</p>
<p>For example, you can create separate stylesheets for each density:</p>
<pre>
&lt;link rel="stylesheet" media="screen and (-webkit-device-pixel-ratio: 1.5)" href="hdpi.css" /&gt;
&lt;link rel="stylesheet" media="screen and (-webkit-device-pixel-ratio: 1.0)" href="mdpi.css" /&gt;
&lt;link rel="stylesheet" media="screen and (-webkit-device-pixel-ratio: 0.75)" href="ldpi.css" /&gt;
</pre>
<div class="figure" style="width:300px">
<img src="{@docRoot}images/webapps/compare-width-devicedpi-css.png" alt="" height="300" />
<p class="img-caption"><strong>Figure 5.</strong> A web page with CSS that's targetted to
specific screen densities using the {@code -webkit-device-pixel-ratio} media feature. Notice
that the hdpi device shows a different image that's applied in CSS.</p>
</div>
<p>Or, specify the different styles in one stylesheet:</p>
<pre class="no-pretty-print">
#header {
background:url(medium-density-image.png);
}
&#64;media screen and (-webkit-device-pixel-ratio: 1.5) {
// CSS for high-density screens
#header {
background:url(high-density-image.png);
}
}
&#64;media screen and (-webkit-device-pixel-ratio: 0.75) {
// CSS for low-density screens
#header {
background:url(low-density-image.png);
}
}
</pre>
<p class="note"><strong>Note:</strong> The default style for {@code #header} applies the image
designed for medium-density devices in order to support devices running a version of Android less
than 2.0, which do not support the {@code -webkit-device-pixel-ratio} media feature.</p>
<p>The types of styles you might want to adjust based on the screen density depend on how you've
defined your viewport properties. To provide fully-customized styles that tailor your web page for
each of the supported densities, you should set your viewport properties so the viewport width and
density match the device. That is:</p>
<pre>
&lt;meta name="viewport" content="target-densitydpi=device-dpi, width=device-width" /&gt;
</pre>
<p>This way, the Android Browser does not perform scaling on your web page and the viewport width
matches the screen width exactly. On its own, these viewport properties create results shown in
figure 4. However, by adding some custom CSS using the {@code -webkit-device-pixel-ratio} media
feature, you can apply different styles. For example, figure 5 shows a web page with these viewport
properties and also some CSS added that applies a high-resolution image for high-density
screens.</p>
<h2 id="DensityJS">Targetting Device Density with JavaScript</h2>
<p>The Android Browser supports a DOM property that allows you to query the density of the current
device&mdash;the <code>window.devicePixelRatio</code> DOM property. The value of this property
specifies the scaling factor used for the current device. For example, if the value
of <code>window.devicePixelRatio</code> is "1.0", then the device is considered a medium density
device and no scaling is applied by default; if the value is "1.5", then the device is
considered a high density device and the page is scaled 1.5x by default; if the value
is "0.75", then the device is considered a low density device and the page is scaled
0.75x by default. Of course, the scaling that the Android Browser applies is based on the web page's
target density&mdash;as described in the section about <a href="#ViewportDensity">Defining the
viewport target density</a>, the default target is medium-density, but you can change the
target to affect how your web page is scaled for different screen densities.</p>
<p>For example, here's how you can query the device density with JavaScript:</p>
<pre>
if (window.devicePixelRatio == 1.5) {
alert("This is a high-density screen");
} else if (window.devicePixelRation == 0.75) {
alert("This is a low-density screen");
}
</pre>

328
docs/html/guide/webapps/webview.jd Normal file
View File

@@ -0,0 +1,328 @@
page.title=Building Web Apps in WebView
@jd:body
<div id="qv-wrapper">
<div id="qv">
<h2>Quickview</h2>
<ul>
<li>Use {@link android.webkit.WebView} to display web pages in your Android application
layout</li>
<li>You can create interfaces from your JavaScript to your client-side Android code</li>
</ul>
<h2>In this document</h2>
<ol>
<li><a href="#AddingWebView">Adding a WebView to Your Application</a></li>
<li><a href="#UsingJavaScript">Using JavaScript in WebView</a>
<ol>
<li><a href="#EnablingJavaScript">Enabling JavaScript</a></li>
<li><a href="#BindingJavaScript">Binding JavaScript code to Android code</a></li>
</ol>
</li>
<li><a href="#HandlingNavigation">Handling Page Navigation</a>
<ol>
<li><a href="#NavigatingHistory">Navigating web page history</a></li>
</ol>
</li>
</ol>
<h2>Key classes</h2>
<ol>
<li>{@link android.webkit.WebView}</li>
<li>{@link android.webkit.WebSettings}</li>
<li>{@link android.webkit.WebViewClient}</li>
</ol>
<h2>Related tutorials</h2>
<ol>
<li><a href="{@docRoot}resources/tutorials/views/hello-webview.html">Web View</a></li>
</ol>
</div>
</div>
<p>If you want to deliver a web application (or just a web page) as a part of a client application,
you can do it using {@link android.webkit.WebView}. The {@link android.webkit.WebView} class is an
extension of Android's {@link android.view.View} class that allows you to display web pages as a
part of your activity layout. It does <em>not</em> include any features of a fully developed web
browser, such as navigation controls or an address bar. All that {@link android.webkit.WebView}
does, by default, is show a web page.</p>
<p>A common scenario in which using {@link android.webkit.WebView} is helpful is when you want to
provide information in your application that you might need to update, such as an end-user agreement
or a user guide. Within your Android application, you can create an {@link android.app.Activity}
that contains a {@link android.webkit.WebView}, then use that to display your document that's
hosted online.</p>
<p>Another scenario in which {@link android.webkit.WebView} can help is if your application provides
data to the user that
always requires an Internet connection to retrieve data, such as email. In this case, you might
find that it's easier to build a {@link android.webkit.WebView} in your Android application that
shows a web page with all
the user data, rather than performing a network request, then parsing the data and rendering it in
an Android layout. Instead, you can design a web page that's tailored for Android devices
and then implement a {@link android.webkit.WebView} in your Android application that loads the web
page.</p>
<p>This document shows you how to get started with {@link android.webkit.WebView} and how to do some
additional things, such as handle page navigation and bind JavaScript from your web page to
client-side code in your Android application.</p>
<h2 id="AddingWebView">Adding a WebView to Your Application</h2>
<p>To add a {@link android.webkit.WebView} to your Application, simply include the {@code
&lt;WebView&gt;} element in your activity layout. For example, here's a layout file in which the
{@link android.webkit.WebView} fills the screen:</p>
<pre>
&lt;?xml version="1.0" encoding="utf-8"?&gt;
&lt;WebView xmlns:android="http://schemas.android.com/apk/res/android"
android:id="@+id/webview"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
/&gt;
</pre>
<p>To load a web page in the {@link android.webkit.WebView}, use {@link
android.webkit.WebView#loadUrl(String) loadUrl()}. For example:</p>
<pre>
WebView myWebView = (WebView) findViewById(R.id.webview);
myWebView.loadUrl("http://www.example.com");
</pre>
<p>Before this will work, however, your application must have access to the Internet. To get
Internet access, request the {@link android.Manifest.permission#INTERNET} permission in your
manifest file. For example:</p>
<pre>
&lt;manifest ... &gt;
&lt;uses-permission android:name="android.permission.INTERNET" /&gt;
...
&lt;/manifest&gt;
</pre>
<p>That's all you need for a basic {@link android.webkit.WebView} that displays a web page.</p>
<h2 id="UsingJavaScript">Using JavaScript in WebView</h2>
<p>If the web page you plan to load in your {@link android.webkit.WebView} use JavaScript, you
must enable JavaScript for your {@link android.webkit.WebView}. Once JavaScript is enabled, you can
also create interfaces between your application code and your JavaScript code.</p>
<h3 id="EnablingJavaScript">Enabling JavaScript</h3>
<p>JavaScript is disabled in a {@link android.webkit.WebView} by default. You can enable it
through the {@link
android.webkit.WebSettings} attached to your {@link android.webkit.WebView}. You can retrieve {@link
android.webkit.WebSettings} with {@link android.webkit.WebView#getSettings()}, then enable
JavaScript with {@link android.webkit.WebSettings#setJavaScriptEnabled(boolean)
setJavaScriptEnabled()}.</p>
<p>For example:</p>
<pre>
WebView myWebView = (WebView) findViewById(R.id.webview);
WebSettings webSettings = myWebView.getSettings();
webSettings.setJavaScriptEnabled(true);
</pre>
<p>{@link android.webkit.WebSettings} provides access to a variety of other settings that you might
find useful. For example, if you're developing a web application
that's designed specifically for the {@link android.webkit.WebView} in your Android application,
then you can define a
custom user agent string with {@link android.webkit.WebSettings#setUserAgentString(String)
setUserAgentString()}, then query the custom user agent in your web page to verify that the
client requesting your web page is actually your Android application.</p>
from your Android SDK {@code tools/} directory
<h3 id="BindingJavaScript">Binding JavaScript code to Android code</h3>
<p>When developing a web application that's designed specifically for the {@link
android.webkit.WebView} in your Android
application, you can create interfaces between your JavaScript code and client-side Android code.
For example, your JavaScript code can call a method in your Android code to display a {@link
android.app.Dialog}, instead of using JavaScript's {@code alert()} function.</p>
<p>To bind a new interface between your JavaScript and Android code, call {@link
android.webkit.WebView#addJavascriptInterface(Object,String) addJavascriptInterface()}, passing it
a class instance to bind to your JavaScript and an interface name that your JavaScript can call to
access the class.</p>
<p>For example, you can include the following class in your Android application:</p>
<pre>
public class JavaScriptInterface {
Context mContext;
/** Instantiate the interface and set the context */
JavaScriptInterface(Context c) {
mContext = c;
}
/** Show a toast from the web page */
public void showToast(String toast) {
Toast.makeText(mContext, toast, Toast.LENGTH_SHORT).show();
}
}
</pre>
<p>In this example, the {@code JavaScriptInterface} class allows the web page to create a {@link
android.widget.Toast} message, using the {@code showToast()} method.</p>
<p>You can bind this class to the JavaScript that runs in your {@link android.webkit.WebView} with
{@link android.webkit.WebView#addJavascriptInterface(Object,String) addJavascriptInterface()} and
name the interface {@code Android}. For example:</p>
<pre>
WebView webView = (WebView) findViewById(R.id.webview);
webView.addJavascriptInterface(new JavaScriptInterface(this), "Android");
</pre>
<p>This creates an interface called {@code Android} for JavaScript running in the {@link
android.webkit.WebView}. At this point, your web application has access to the {@code
JavaScriptInterface} class. For example, here's some HTML and JavaScript that creates a toast
message using the new interface when the user clicks a button:</p>
<pre>
&lt;input type="button" value="Say hello" onClick="showAndroidToast('Hello Android!')" /&gt;
&lt;script type="text/javascript"&gt;
function showAndroidToast(toast) {
Android.showToast(toast);
}
&lt;/script&gt;
</pre>
<p>There's no need to initialize the {@code Android} interface from JavaScript. The {@link
android.webkit.WebView} automatically makes it
available to your web page. So, at the click of the button, the {@code showAndroidToast()}
function uses the {@code Android} interface to call the {@code JavaScriptInterface.showToast()}
method.</p>
<p class="note"><strong>Note:</strong> The object that is bound to your JavaScript runs in
another thread and not in the thread in which it was constructed.</p>
<p class="caution"><strong>Caution:</strong> Using {@link
android.webkit.WebView#addJavascriptInterface(Object,String) addJavascriptInterface()} allows
JavaScript to control your Android application. This can be a very useful feature or a dangerous
security issue. When the HTML in the {@link android.webkit.WebView} is untrustworthy (for example,
part or all of the HTML
is provided by an unknown person or process), then an attacker can include HTML that executes
your client-side code and possibly any code of the attacker's choosing. As such, you should not use
{@link android.webkit.WebView#addJavascriptInterface(Object,String) addJavascriptInterface()} unless
you wrote all of the HTML and JavaScript that appears in your {@link android.webkit.WebView}. You
should also not allow the user to
navigate to other web pages that are not your own, within your {@link android.webkit.WebView}
(instead, allow the user's
default browser application to open foreign links&mdash;by default, the user's web browser
opens all URL links, so be careful only if you handle page navigation as described in the
following section).</p>
<h2 id="HandlingNavigation">Handling Page Navigation</h2>
<p>When the user clicks a link from a web page in your {@link android.webkit.WebView}, the default
behavior is
for Android to launch an application that handles URLs. Usually, the default web browser opens and
loads the destination URL. However, you can override this behavior for your {@link
android.webkit.WebView},
so links open within your {@link android.webkit.WebView}. You can then allow the user to navigate
backward and forward through their web page history that's maintained by your {@link
android.webkit.WebView}.</p>
<p>To open links clicked by the user, simply provide a {@link
android.webkit.WebViewClient} for your {@link android.webkit.WebView}, using {@link
android.webkit.WebView#setWebViewClient(WebViewClient) setWebViewClient()}. For example:</p>
<pre>
WebView myWebView = (WebView) findViewById(R.id.webview);
myWebView.{@link android.webkit.WebView#setWebViewClient(WebViewClient) setWebViewClient}(new WebViewClient());
</pre>
<p>That's it. Now all links the user clicks load in your {@link android.webkit.WebView}.</p>
<p>If you want more control over where a clicked link load, create your own {@link
android.webkit.WebViewClient} that overrides the {@link
android.webkit.WebViewClient#shouldOverrideUrlLoading(WebView,String)
shouldOverrideUrlLoading()} method. For example:</p>
<pre>
private class MyWebViewClient extends WebViewClient {
&#64;Override
public boolean {@link android.webkit.WebViewClient#shouldOverrideUrlLoading(WebView,String) shouldOverrideUrlLoading}(WebView view, String url) {
if (Uri.parse(url).getHost().equals("www.example.com")) {
// This is my web site, so do not override; let my WebView load the page
return false;
}
// Otherwise, the link is not for a page on my site, so launch another Activity that handles URLs
Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse(url));
startActivity(intent);
return true;
}
}
</pre>
<p>Then create an instance of this new {@link android.webkit.WebViewClient} for the {@link
android.webkit.WebView}:</p>
<pre>
WebView myWebView = (WebView) findViewById(R.id.webview);
myWebView.{@link android.webkit.WebView#setWebViewClient(WebViewClient) setWebViewClient}(new MyWebViewClient());
</pre>
<p>Now when the user clicks a link, the system calls
{@link android.webkit.WebViewClient#shouldOverrideUrlLoading(WebView,String)
shouldOverrideUrlLoading()}, which checks whether the URL host matches a specific domain (as defined
above). If it does match, then the method returns false in order to <em>not</em> override the URL
loading (it allows the {@link android.webkit.WebView} to load the URL as usual). If the URL host
does not match, then an {@link android.content.Intent} is created to
launch the default Activity for handling URLs (which resolves to the user's default web
browser).</p>
<h3 id="NavigatingHistory">Navigating web page history</h3>
<p>When your {@link android.webkit.WebView} overrides URL loading, it automatically accumulates a
history of visited web
pages. You can navigate backward and forward through the history with {@link
android.webkit.WebView#goBack()} and {@link android.webkit.WebView#goForward()}.</p>
<p>For example, here's how your {@link android.app.Activity} can use the device BACK key to navigate
backward:</p>
<pre>
&#64;Override
public boolean {@link android.app.Activity#onKeyDown(int,KeyEvent) onKeyDown}(int keyCode, KeyEvent event) {
// Check if the key event was the BACK key and if there's history
if ((keyCode == KeyEvent.KEYCODE_BACK) &amp;&amp; myWebView.{@link android.webkit.WebView#canGoBack() canGoBack}() {
myWebView.{@link android.webkit.WebView#goBack() goBack}();
return true;
}
// If it wasn't the BACK key or there's no web page history, bubble up to the default
// system behavior (probably exit the activity)
return super.onKeyDown(keyCode, event);
}
</pre>
<p>The {@link android.webkit.WebView#canGoBack()} method returns
true if there is actually web page history for the user to visit. Likewise, you can use {@link
android.webkit.WebView#canGoForward()} to check whether there is a forward history. If you don't
perform this check, then once the user reaches the end of the history, {@link
android.webkit.WebView#goBack()} or {@link android.webkit.WebView#goForward()} does nothing.</p>

BIN
docs/html/images/webapps/compare-default.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 78 KiB

BIN
docs/html/images/webapps/compare-initialscale-devicedpi.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 85 KiB

BIN
docs/html/images/webapps/compare-initialscale.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 87 KiB

BIN
docs/html/images/webapps/compare-width-devicedpi-css.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 87 KiB

BIN
docs/html/images/webapps/compare-width400.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 85 KiB