Skip to content

Commit e64256d

Browse files
scottamainAndroid (Google) Code Review
authored andcommitted
Merge "docs: revise webview description and add info for targeting screen densities" into froyo
2 parents 6750bb7 + 8b3cea0 commit e64256d

File tree

1 file changed

+103
-20
lines changed

1 file changed

+103
-20
lines changed

core/java/android/webkit/WebView.java

Lines changed: 103 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -109,36 +109,50 @@
109109
* {@link #getSettings() WebSettings}.{@link WebSettings#setBuiltInZoomControls(boolean)}
110110
* (introduced in API version 3).
111111
* <p>Note that, in order for your Activity to access the Internet and load web pages
112-
* in a WebView, you must add the <var>INTERNET</var> permissions to your
112+
* in a WebView, you must add the {@code INTERNET} permissions to your
113113
* Android Manifest file:</p>
114114
* <pre>&lt;uses-permission android:name="android.permission.INTERNET" /></pre>
115115
*
116-
* <p>This must be a child of the <code>&lt;manifest></code> element.</p>
116+
* <p>This must be a child of the <a
117+
* href="{@docRoot}guide/topics/manifest/manifest-element.html">{@code &lt;manifest&gt;}</a>
118+
* element.</p>
117119
*
118120
* <h3>Basic usage</h3>
119121
*
120122
* <p>By default, a WebView provides no browser-like widgets, does not
121-
* enable JavaScript and errors will be ignored. If your goal is only
123+
* enable JavaScript and web page errors are ignored. If your goal is only
122124
* to display some HTML as a part of your UI, this is probably fine;
123125
* the user won't need to interact with the web page beyond reading
124126
* it, and the web page won't need to interact with the user. If you
125-
* actually want a fully blown web browser, then you probably want to
126-
* invoke the Browser application with your URL rather than show it
127-
* with a WebView. See {@link android.content.Intent} for more information.</p>
127+
* actually want a full-blown web browser, then you probably want to
128+
* invoke the Browser application with a URL Intent rather than show it
129+
* with a WebView. For example:
130+
* <pre>
131+
* Uri uri = Uri.parse("http://www.example.com");
132+
* Intent intent = new Intent(Intent.ACTION_VIEW, uri);
133+
* startActivity(intent);
134+
* </pre>
135+
* <p>See {@link android.content.Intent} for more information.</p>
128136
*
137+
* <p>To provide a WebView in your own Activity, include a {@code &lt;WebView&gt;} in your layout,
138+
* or set the entire Activity window as a WebView during {@link
139+
* android.app.Activity#onCreate(Bundle) onCreate()}:</p>
129140
* <pre class="prettyprint">
130141
* WebView webview = new WebView(this);
131142
* setContentView(webview);
143+
* </pre>
132144
*
145+
* <p>Then load the desired web page:</p>
133146
* // Simplest usage: note that an exception will NOT be thrown
134147
* // if there is an error loading this page (see below).
135148
* webview.loadUrl("http://slashdot.org/");
136149
*
137-
* // Of course you can also load from any string:
150+
* // OR, you can also load from an HTML string:
138151
* String summary = "&lt;html>&lt;body>You scored &lt;b>192</b> points.&lt;/body>&lt;/html>";
139152
* webview.loadData(summary, "text/html", "utf-8");
140153
* // ... although note that there are restrictions on what this HTML can do.
141-
* // See the JavaDocs for loadData and loadDataWithBaseUrl for more info.
154+
* // See the JavaDocs for {@link #loadData(String,String,String) loadData()} and {@link
155+
* #loadDataWithBaseURL(String,String,String,String,String) loadDataWithBaseURL()} for more info.
142156
* </pre>
143157
*
144158
* <p>A WebView has several customization points where you can add your
@@ -148,15 +162,20 @@
148162
* <li>Creating and setting a {@link android.webkit.WebChromeClient} subclass.
149163
* This class is called when something that might impact a
150164
* browser UI happens, for instance, progress updates and
151-
* JavaScript alerts are sent here.
165+
* JavaScript alerts are sent here (see <a
166+
* href="{@docRoot}guide/developing/debug-tasks.html#DebuggingWebPages">Debugging Tasks</a>).
152167
* </li>
153168
* <li>Creating and setting a {@link android.webkit.WebViewClient} subclass.
154169
* It will be called when things happen that impact the
155170
* rendering of the content, eg, errors or form submissions. You
156-
* can also intercept URL loading here.</li>
157-
* <li>Via the {@link android.webkit.WebSettings} class, which contains
158-
* miscellaneous configuration. </li>
159-
* <li>With the {@link android.webkit.WebView#addJavascriptInterface} method.
171+
* can also intercept URL loading here (via {@link
172+
* android.webkit.WebViewClient#shouldOverrideUrlLoading(WebView,String)
173+
* shouldOverrideUrlLoading()}).</li>
174+
* <li>Modifying the {@link android.webkit.WebSettings}, such as
175+
* enabling JavaScript with {@link android.webkit.WebSettings#setJavaScriptEnabled(boolean)
176+
* setJavaScriptEnabled()}. </li>
177+
* <li>Adding JavaScript-to-Java interfaces with the {@link
178+
* android.webkit.WebView#addJavascriptInterface} method.
160179
* This lets you bind Java objects into the WebView so they can be
161180
* controlled from the web pages JavaScript.</li>
162181
* </ul>
@@ -191,8 +210,8 @@
191210
* <h3>Cookie and window management</h3>
192211
*
193212
* <p>For obvious security reasons, your application has its own
194-
* cache, cookie store etc - it does not share the Browser
195-
* applications data. Cookies are managed on a separate thread, so
213+
* cache, cookie store etc.&mdash;it does not share the Browser
214+
* application's data. Cookies are managed on a separate thread, so
196215
* operations like index building don't block the UI
197216
* thread. Follow the instructions in {@link android.webkit.CookieSyncManager}
198217
* if you want to use cookies in your application.
@@ -201,15 +220,79 @@
201220
* <p>By default, requests by the HTML to open new windows are
202221
* ignored. This is true whether they be opened by JavaScript or by
203222
* the target attribute on a link. You can customize your
204-
* WebChromeClient to provide your own behaviour for opening multiple windows,
223+
* {@link WebChromeClient} to provide your own behaviour for opening multiple windows,
205224
* and render them in whatever manner you want.</p>
206225
*
207-
* <p>Standard behavior for an Activity is to be destroyed and
208-
* recreated when the devices orientation is changed. This will cause
226+
* <p>The standard behavior for an Activity is to be destroyed and
227+
* recreated when the device orientation or any other configuration changes. This will cause
209228
* the WebView to reload the current page. If you don't want that, you
210-
* can set your Activity to handle the orientation and keyboardHidden
229+
* can set your Activity to handle the {@code orientation} and {@code keyboardHidden}
211230
* changes, and then just leave the WebView alone. It'll automatically
212-
* re-orient itself as appropriate.</p>
231+
* re-orient itself as appropriate. Read <a
232+
* href="{@docRoot}guide/topics/resources/runtime-changes.html">Handling Runtime Changes</a> for
233+
* more information about how to handle configuration changes during runtime.</p>
234+
*
235+
*
236+
* <h3>Building web pages to support different screen densities</h3>
237+
*
238+
* <p>The screen density of a device is based on the screen resolution. A screen with low density
239+
* has fewer available pixels per inch, where a screen with high density
240+
* has more — sometimes significantly more — pixels per inch. The density of a
241+
* screen is important because, other things being equal, a UI element (such as a button) whose
242+
* height and width are defined in terms of screen pixels will appear larger on the lower density
243+
* screen and smaller on the higher density screen.
244+
* For simplicity, Android collapses all actual screen densities into three generalized densities:
245+
* high, medium, and low.</p>
246+
* <p>By default, WebView scales a web page so that it is drawn at a size that matches the default
247+
* appearance on a medium density screen. So, it applies 1.5x scaling on a high density screen
248+
* (because its pixels are smaller) and 0.75x scaling on a low density screen (because its pixels
249+
* are bigger).
250+
* Starting with API Level 5 (Android 2.0), WebView supports DOM, CSS, and meta tag features to help
251+
* you (as a web developer) target screens with different screen densities.</p>
252+
* <p>Here's a summary of the features you can use to handle different screen densities:</p>
253+
* <ul>
254+
* <li>The {@code window.devicePixelRatio} DOM property. The value of this property specifies the
255+
* default scaling factor used for the current device. For example, if the value of {@code
256+
* window.devicePixelRatio} is "1.0", then the device is considered a medium density (mdpi) device
257+
* and default scaling is not applied to the web page; if the value is "1.5", then the device is
258+
* considered a high density device (hdpi) and the page content is scaled 1.5x; if the
259+
* value is "0.75", then the device is considered a low density device (ldpi) and the content is
260+
* scaled 0.75x. However, if you specify the {@code "target-densitydpi"} meta property
261+
* (discussed below), then you can stop this default scaling behavior.</li>
262+
* <li>The {@code -webkit-device-pixel-ratio} CSS media query. Use this to specify the screen
263+
* densities for which this style sheet is to be used. The corresponding value should be either
264+
* "0.75", "1", or "1.5", to indicate that the styles are for devices with low density, medium
265+
* density, or high density screens, respectively. For example:
266+
* <pre>
267+
* &lt;link rel="stylesheet" media="screen and (-webkit-device-pixel-ratio:1.5)" href="hdpi.css" /&gt;</pre>
268+
* <p>The {@code hdpi.css} stylesheet is only used for devices with a screen pixel ration of 1.5,
269+
* which is the high density pixel ratio.</p>
270+
* </li>
271+
* <li>The {@code target-densitydpi} property for the {@code viewport} meta tag. You can use
272+
* this to specify the target density for which the web page is designed, using the following
273+
* values:
274+
* <ul>
275+
* <li>{@code device-dpi} - Use the device's native dpi as the target dpi. Default scaling never
276+
* occurs.</li>
277+
* <li>{@code high-dpi} - Use hdpi as the target dpi. Medium and low density screens scale down
278+
* as appropriate.</li>
279+
* <li>{@code medium-dpi} - Use mdpi as the target dpi. High density screens scale up and
280+
* low density screens scale down. This is also the default behavior.</li>
281+
* <li>{@code low-dpi} - Use ldpi as the target dpi. Medium and high density screens scale up
282+
* as appropriate.</li>
283+
* <li><em>{@code &lt;value&gt;}</em> - Specify a dpi value to use as the target dpi (accepted
284+
* values are 70-400).</li>
285+
* </ul>
286+
* <p>Here's an example meta tag to specify the target density:</p>
287+
* <pre>&lt;meta name="viewport" content="target-densitydpi=device-dpi" /&gt;</pre></li>
288+
* </ul>
289+
* <p>If you want to modify your web page for different densities, by using the {@code
290+
* -webkit-device-pixel-ratio} CSS media query and/or the {@code
291+
* window.devicePixelRatio} DOM property, then you should set the {@code target-densitydpi} meta
292+
* property to {@code device-dpi}. This stops Android from performing scaling in your web page and
293+
* allows you to make the necessary adjustments for each density via CSS and JavaScript.</p>
294+
*
295+
*
213296
*/
214297
@Widget
215298
public class WebView extends AbsoluteLayout

0 commit comments

Comments
 (0)