Unit 6 - Practice Quiz

The WebView class is a component that extends Android's View class and is used to display web pages as a part of your activity layout.

The loadUrl() method is the standard function used to instruct a WebView instance to fetch and display the content from a given web address.

To allow your app, including its WebView components, to connect to the internet, you must declare the INTERNET permission in your app's manifest file.

By default, WebView delegates URL handling to the system. To override this and keep navigation within your app, you must provide a WebViewClient.

For security reasons, JavaScript is disabled by default in WebView. You must explicitly enable it through the WebSettings object associated with your WebView.

The viewport meta tag gives the browser instructions on how to control the page's dimensions and scaling, which is crucial for responsive design on mobile devices.

The width=device-width part of the viewport meta tag tells the browser to match the page's width to the device's width in device-independent pixels.

Relative units like em and rem allow font sizes to scale based on a parent element or the root element's font size, which is better for accessibility and responsiveness than fixed pixel sizes.

Using WebView allows for dynamic content updates. You can change the web page on your server, and all users will see the new content immediately without needing to update the app from the app store.

This method creates a bridge, allowing the JavaScript running in the web page to interact with and invoke public methods of a supplied Java/Kotlin object.

WebViewClient is used for handling events related to rendering the content, such as page navigation, form submissions, and errors. It allows you to keep navigation within your WebView.

Legal documents like Terms of Service often change. Displaying them in a WebView loaded from a URL allows the business to update the terms on their website, and the app will automatically show the latest version.

CSS Media Queries allow you to apply specific styles based on device characteristics like its width, height, orientation, or resolution, which is the foundation of responsive web design.

While WebView is powerful, native components are generally more performant and offer a more fluid, platform-consistent user experience, especially for complex animations and interactions.

WebChromeClient is responsible for handling events that affect the browser UI (the 'chrome'), such as progress bar updates, JavaScript dialogs (alert, confirm), and receiving the page's title or icon.

Android provides a special URL scheme, file:///android_asset/, to access files packaged within the app's assets directory directly from a WebView.

Content that is document-centric and needs frequent updates without requiring deep integration with device hardware is an ideal candidate for a WebView-based approach.

The initial-scale=1.0 part of the viewport tag sets the initial zoom level when the page is first loaded, ensuring a 1:1 relationship between CSS pixels and device-independent pixels.

The goBack() method navigates to the previously visited page in the WebView's history, similar to the back button in a standard web browser.

The canGoBack() method returns a boolean value indicating whether the WebView has a back history. It's best practice to check this before calling goBack() to avoid unexpected behavior.

For security purposes, JavaScript is disabled in a WebView by default to prevent potential cross-site scripting (XSS) attacks. To allow a web page to execute JavaScript, you must explicitly enable it via the WebSettings object.

By setting a custom WebViewClient and overriding the shouldOverrideUrlLoading() method, you can intercept all URL loading requests. Returning true from this method indicates that your app has handled the URL, preventing the WebView from taking its default action (like opening an external browser).

The viewport meta tag is crucial for responsive web design. width=device-width tells the browser to set the width of the page to the screen-width of the device, and initial-scale=1.0 sets the initial zoom level. This allows CSS media queries to work correctly.

The standard and secure mechanism for creating a bridge from JavaScript to native code is to use addJavascriptInterface(). Methods that you want to be accessible from JavaScript must be annotated with @JavascriptInterface to explicitly expose them, preventing unintended security vulnerabilities.

WebChromeClient is responsible for handling UI-related events like progress updates, JavaScript dialogs, and favicons. The onProgressChanged() callback provides the loading progress as an integer from 0 to 100, which is ideal for updating a ProgressBar.

DOM Storage, which includes localStorage and sessionStorage, is disabled by default. To allow the web application to use these storage APIs and persist data, you must explicitly enable it with setDomStorageEnabled(true).

setUseWideViewPort(true) allows the WebView to use a viewport wider than the device screen, and setLoadWithOverviewMode(true) zooms out the content to fit the screen width upon initial load. Together, they provide a good overview of desktop-centric sites.

The evaluateJavascript() method is the modern and preferred way to execute JavaScript and get a result back. It runs the script asynchronously and delivers the result of the execution to the provided ValueCallback, avoiding the performance and security issues of the older loadUrl("javascript:...") method.

The correct place to handle this is in the Activity's onBackPressed() callback. You should check if (webView.canGoBack()), and if it returns true, call webView.goBack(). Otherwise, you call super.onBackPressed() to allow the default back button behavior (like exiting the app).

The native file chooser is not automatically triggered by a WebView. To handle file uploads, you must provide a custom WebChromeClient and implement the onShowFileChooser() method. Inside this method, you create and launch an Intent (e.g., Intent.ACTION_GET_CONTENT) to open the system file picker.

Just as with standard web development, the best practice is to use responsive image techniques. The srcset attribute on <img> tags allows the browser (and WebView) to select the most appropriate image file based on the device's pixel density, ensuring sharpness without wasting bandwidth on unnecessarily large files.

A complete data wipe requires multiple steps. clearCache(true) clears the resource cache, clearHistory() clears the back/forward list, and CookieManager.getInstance().removeAllCookies() is essential for clearing session cookies. A single method does not cover all data types.

Enabling hardware acceleration for the Activity allows the WebView to use the GPU for rendering operations. This significantly improves performance for graphically intensive content like CSS animations, transforms, and WebGL. It is enabled by default for modern target SDKs but is critical to ensure is active.

Android's WebView component is tied to the version of Chromium shipped with the OS. On older Android versions, this Chromium version can be significantly outdated and lack support for modern JavaScript and CSS features. To fix this, developers often use transpilers like Babel to convert modern code to a more compatible version (ES5).

The device-pixel-ratio media feature allows you to apply specific CSS rules for high-density (Retina) screens. A value of 2 targets devices like XHDPI, while 3 targets XXHDPI, enabling you to serve higher-resolution assets or adjust typography for clarity on these displays.

The two most significant security risks in a WebView come from executing malicious scripts and allowing those scripts to access the local file system. Disabling JavaScript (setJavaScriptEnabled(false)) prevents script execution, and disabling file access (setAllowFileAccess(false)) prevents scripts from accessing local file:/// URLs, providing a much more secure environment for untrusted content.

Android's WebView provides fine-grained control over mixed content (HTTP content on an HTTPS page). The setMixedContentMode() setting allows you to specify the policy, with MIXED_CONTENT_ALWAYS_ALLOW being the most permissive option. However, for security, the recommended approach is to fix the web content to use HTTPS for all resources.

The shouldInterceptRequest callback allows you to intercept any resource request (images, scripts, etc.) made by the WebView. You can inspect the request and return a custom WebResourceResponse with your own data, allowing for powerful features like custom caching, ad blocking, or modifying responses on the fly.

WebChromeClient handles interactions with browser UI elements. By overriding onJsAlert(), you can intercept the JavaScript alert() call, prevent the default dialog from appearing, and show a native Android AlertDialog instead for a more integrated user experience. Returning true indicates you have handled the event.

adjustResize is the default behavior, where the activity's main window is resized to make room for the soft keyboard. This changes the WebView's height and can disrupt layouts using vh units. adjustPan avoids resizing; instead, the contents of the window are panned to ensure the current focus is visible, preserving the WebView's original dimensions.

The ValueCallback's onReceiveValue is guaranteed to be called on the main thread. The correct pattern is to receive the result on the main thread and then immediately hand off the heavy processing to a background thread (e.g., using a coroutine, RxJava, or an Executor) to prevent blocking the UI. The other options are either incorrect (hidden APIs are not reliable) or less direct for this specific problem.

shouldInterceptRequest is called on a background thread, but it must return a WebResourceResponse synchronously for the given request. If you need to perform an asynchronous operation (like another network call or a complex DB query) to get the data, you must block the current thread until the result is ready. Using a synchronization aid like CountDownLatch or CompletableFuture.get() is a common pattern to solve this.

There is no automatic mechanism for WebView to pass window insets to CSS. The correct, advanced approach is to listen for insets on the native WebView View, extract the relevant values (e.g., from DisplayCutout), and then use JavaScript injection to set CSS custom properties (variables) on the <html> or <body> element. The web content's CSS can then use these variables with var(--safe-area-inset-top).

The most robust and seamless way to integrate advanced native networking logic (like an OkHttp Authenticator) is to intercept all WebView requests via shouldInterceptRequest. Inside this method, you create and execute an equivalent OkHttp Request, which will trigger your Authenticator on a 401. You then synchronously wait for the result and convert the OkHttp Response into a WebResourceResponse for the WebView. This transparently adds native capabilities to the WebView's networking.

WebView can hold a strong reference to its Context. To properly clean it up, you must first detach it from its parent View, which breaks the View hierarchy's reference chain. Only after detaching it should you call destroy() to clean up its internal state. Performing this in onDestroyView ensures it happens when the Fragment's view is being torn down.

With multi-process WebView, the renderer runs in a separate, sandboxed process. When JavaScript calls a native method via the JS Bridge, the arguments and return values must be marshalled and sent over an IPC (Binder) transaction. This means large data transfers can be slow or even fail with a TransactionTooLargeException, a problem that does not exist with the older, in-process WebView.

The HTML <meta name="viewport"> tag is the standard way for a web page to declare its desired viewport properties. Modern WebView implementations prioritize the page's own viewport tag over the native WebSettings. setUseWideViewPort(true) is primarily a fallback for sites that do not have a viewport tag, forcing them to render in a larger viewport instead of a tiny one.

The ValueCallback provided in onShowFileChooser is the mechanism to return the selected file URI(s) back to the WebView. If you store this callback but the user cancels the operation, you must call mUploadMessage.onReceiveValue(null) and then set mUploadMessage = null. Failure to do so can leave the WebView in a state where it's waiting for a callback that will never arrive, effectively breaking all subsequent file upload attempts.

When the renderer process becomes unresponsive or is gone (onRenderProcessGone), the WebView instance becomes invalid and cannot be recovered by simple actions like reload(). The only robust recovery path is to completely destroy the faulty WebView object, create a fresh instance, configure it, add it to your layout, and then attempt to restore its state by loading the previous URL.

The modern, recommended approach for handling back-press is using OnBackPressedDispatcher. The correct pattern is to add a custom callback. Inside the callback, you consume the back press for the WebView's internal navigation (webView.goBack()). If the WebView has no history, you must disable your callback and re-trigger the dispatcher's default behavior so the Activity or Fragment can be popped from the back stack. The deprecated onBackPressed() method should be avoided.

The Service Worker API operates at a lower level than the WebViewClient. When a Service Worker's fetch event handler intercepts a network request, it is handled before WebViewClient.shouldInterceptRequest is ever triggered. To gain control at this level, you must use the dedicated Service Worker APIs, specifically by setting a ServiceWorkerClient via ServiceWorkerController.getInstance().setServiceWorkerClient().

While the JS bridge is convenient, it's not designed for high-throughput, large data transfers, especially with multi-process WebView. The WebMessagePort API is specifically designed for this use case. It creates a dedicated message channel between JavaScript and native code, which is more performant for frequent or large messages than the general-purpose JS bridge, as it can reduce IPC overhead.

Android's density (displayMetrics.density) is equivalent to the web's window.devicePixelRatio. A 1px CSS unit is scaled by this ratio to determine the number of physical pixels. To render a line that is only one physical pixel wide, you must define its CSS width to be 1 / devicePixelRatio CSS pixels. The most reliable way to get the exact device density is from the native side and provide it to the JavaScript context.

onProgressChanged provides a rough percentage of the page load progress, useful for a progress bar. However, onPageCommitVisible is a much more precise signal. It fires at the moment the WebView has parsed enough of the HTML to perform its first paint, meaning the user can actually see content. This is a critical metric for perceived performance, occurring after onPageStarted but often well before onPageFinished.

The Android WebView provides a specific callback, onReceivedClientCertRequest, designed for this exact purpose. When the web server requests a client certificate, this method is invoked on your WebViewClient. Your code is then responsible for retrieving the appropriate PrivateKey and certificate chain (e.g., from an app-specific KeyStore) and passing them to the ClientCertRequest handler to proceed with the TLS handshake.

This approach is the most efficient. evaluateJavascript is the modern, asynchronous way to call into JS. The JS Bridge (@JavascriptInterface) allows JavaScript to directly invoke native methods. Together, they create an event-driven, low-latency, two-way binding. Polling is inefficient and resource-intensive. Using document.title is a clever but outdated and hacky method that is less reliable and performant.

Using a nonce is the modern, secure way to allow specific inline scripts while maintaining a strong CSP. The server (or in this case, the native host) generates a unique nonce for each page load and includes it in the CSP header. Only <script> tags that have the matching nonce attribute will be allowed to execute. This prevents arbitrary script injection while still giving the trusted native host control.

The native Android framework provides the specific onMultiWindowModeChanged callback for this state change. The most robust solution is to listen for this native event and then use the JavaScript bridge (evaluateJavascript) to dispatch a custom JavaScript event within the WebView. The web application's JavaScript can then listen for this specific event and apply layout changes accordingly.

This is a classic inter-process communication problem. The WebView manages its cookies within your app's process. The Android DownloadManager is a system service running in its own process. It has no knowledge of your WebView's session. Therefore, you must act as a bridge: get the necessary authentication cookie from the CookieManager and explicitly add it as a request header to the DownloadManager.Request you create.

For security reasons, remote WebView debugging is disabled by default. It requires two explicit opt-ins: first, the application itself must be debuggable (android:debuggable="true" in AndroidManifest.xml), and second, you must programmatically enable it for all WebViews in your app by calling WebView.setWebContentsDebuggingEnabled(true). This should only be done in debug builds, not in production releases.