youlookwhat/ByWebView for Android WebView integration

ByWebView's Android WebView boundary

ByWebView addresses the repetitive part of putting Android WebView into an application activity. The README describes a wrapper around WebView behavior rather than a general browser engine replacement. Its documented scope includes basic sizing and navigation behavior, page titles, loading progress, JavaScript interaction, image uploads, error pages, full-screen network video, third-party application links, DeepLink handling, opening the app as a third-party browser, and a Tencent X5 example. This makes the project most relevant to Android developers who already have web content and need an activity-level integration layer around it.

The API is intentionally Android-specific. It uses an Activity or a similar lifecycle owner, a parent container for the WebView, Java callbacks, and Android concepts such as `WebView`, `Intent`, `WebViewClient`, and `JavascriptInterface`. It does not present a browser API independent of Android. That boundary is useful when the goal is to bridge an existing website into an Android application, but it is a poor match for teams looking for a cross-platform embedded-browser framework or a complete browser UI.

Builder configuration and page event flow

The visible construction flow starts with `ByWebView.with(this)`. The caller supplies a parent container and `LayoutParams`, optionally selects a progress-bar color, registers callbacks, adds a JavaScript interface, defines an error layout, and finally calls `loadUrl(mUrl)`. The parent container receives the WebView, while the callback types expose title changes, loading progress, orientation requests, page lifecycle events, SSL errors, and decisions about opening third-party URLs.

The WebViewClient callback demonstrates the main data path. `onPageStarted` reports navigation beginning, `onPageFinished` reports completion, and `onReceivedTitle` supplies the page title. `onProgressChanged` returns the WebView's progress value. For links that should leave the WebView flow, `isOpenThirdApp` can delegate to `ByWebTools.handleThirdApp`. The callback returns a boolean, so the application owns the policy decision for each URL.

The library also forwards several events that an Android WebView normally requires the host activity to handle. Lifecycle calls are manually forwarded to `onPause`, `onResume`, and `onDestroy`. Hardware back navigation is routed through `handleKeyEvent`, and image selection is routed through `handleFileChooser` from `onActivityResult`. These explicit forwarding requirements make the integration easy to inspect, but they also mean that missing an activity callback can leave navigation or upload behavior incomplete.

JitPack setup and the first Android load

The README places the library on JitPack. Add the repository to the Gradle project, then declare the dependency shown below. The documented dependency version is 1.2.1, while the listed releases also include 1.2.2 from 2023-01-28. Use the version selected for the application and verify it against the repository before publishing.

allprojects {
	repositories {
		...
		maven { url 'https://jitpack.io' }
	}
}

This repository declaration makes JitPack available to Gradle. The README does not document a separate SDK installation step or a required Android Studio version.

After adding the dependency, create the wrapper with the `with` builder and load a URL. The example expects a `container` parent and an `mUrl` value already defined by the hosting activity.

byWebView = ByWebView
        .with(this)
        .setWebParent(container, new LinearLayout.LayoutParams(-1, -1))
        .useWebProgress(ContextCompat.getColor(this, R.color.coloRed))
        .loadUrl(mUrl);

The progress color is passed through `ContextCompat.getColor`, and the WebView fills the parent according to the supplied layout parameters.

JavaScript bridges and ProGuard annotations

ByWebView documents two directions of JavaScript communication. Android code can call a JavaScript method through `getLoadJsHolder().quickCallJs`. It supports a no-argument call and a call with a string argument. JavaScript code can call Java through a named interface registered with `addJavascriptInterface`, such as `injectedObject`, whose `startFunction()` method is invoked from the page.

// 无参数调用
byWebView.getLoadJsHolder().quickCallJs("javacalljs");
// 传递参数调用
byWebView.getLoadJsHolder().quickCallJs("javacalljswithargs", "android传入到网页里的数据，有参");

Registering the bridge requires the host object and a JavaScript interface implementation.

ByWebView.with(this)
	.addJavascriptInterface("injectedObject", new MyJavascriptInterface(this))
	.loadUrl(mUrl);
window.injectedObject.startFunction()

The README warns that ProGuard can remove or alter the bridge unless annotation attributes and annotated members are kept. The documented rules preserve `*Annotation*`, `*JavascriptInterface*`, and class members annotated with `@android.webkit.JavascriptInterface`. This is a concrete integration risk because the page may appear to load while the bridge silently becomes unavailable after shrinking or obfuscation. The README does not describe a bridge authentication scheme, origin restrictions, or a policy for validating data received from JavaScript.

Uploads, errors, external apps, and full-screen video

File selection is handled through Android's activity-result path. The hosting activity must pass the result to ByWebView, as shown in the README.

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent intent) {
    byWebView.handleFileChooser(requestCode, resultCode, intent);
}

This design keeps file selection compatible with the platform activity lifecycle. It also makes integration conditional: the host must implement the callback and preserve the WebView reference.

Custom error handling is configured with `setErrorLayout`. The example uses a layout resource and a displayed message.

ByWebView.with(this)
	.setErrorLayout(R.layout.by_load_url_error,"无法打开网页")
	.loadUrl(mUrl);

Third-party link handling is policy-driven through `isOpenThirdApp` and `ByWebTools.handleThirdApp`. The callback can also intercept SSL errors with `onReceivedSslError`, but the README only says that returning `true` means the application handles the error itself. It does not prescribe a certificate validation policy, so an application must not treat the example as safe by default.

For video, `onHandleScreenOrientation(boolean isShow)` lets the host decide whether to handle orientation during full-screen playback. Returning `true` delegates that handling to the application; returning `false` leaves the default behavior in the example.

Lifecycle management, release age, and alternative architecture

Lifecycle handling is explicit rather than automatic. The host forwards pause, resume, and destruction to the wrapper.

@Override
protected void onPause() {
    super.onPause();
    byWebView.onPause();
}

@Override
protected void onResume() {
    super.onResume();
    byWebView.onResume();
}

@Override
protected void onDestroy() {
    byWebView.onDestroy();
    super.onDestroy();
}

Hardware back handling follows the same pattern.

@Override
public boolean onKeyDown(int keyCode, KeyEvent event) {
    if (byWebView.handleKeyEvent(keyCode, event)) {
        return true;
    } else {
        return super.onKeyDown(keyCode, event);
    }
}

The project is licensed under Apache-2.0. That license permits use and modification under its terms, but the README does not address dependency licenses for applications that embed the library. The repository is not archived, and the last push was on 2026-05-12. The latest listed release is 1.2.2 from 2023-01-28, while the installation snippet uses 1.2.1. That version mismatch should be resolved before adoption.

A real alternative is to use Android's WebView directly. Direct integration gives the application complete control over `WebViewClient`, `WebChromeClient`, settings, JavaScript interfaces, file chooser handling, SSL decisions, and lifecycle calls. ByWebView reduces repeated wiring for common scenarios, but it also introduces a wrapper whose exact behavior and update history must be verified. For a new application with unusual security requirements, custom rendering behavior, or no need for the documented conveniences, direct WebView code may be clearer.

Editorial conclusion

ByWebView fits Android developers who already use WebView and want documented examples for JavaScript calls, upload callbacks, lifecycle forwarding, and third-party link handling. It is a poor fit if you need a broad, actively maintained web platform abstraction or expect the README to document security policy, rollback, or modern dependency isolation. Verify the chosen ByWebView version, Android API compatibility, JavaScript bridge exposure, and SSL callback policy before adopting it; the repository is not archived, but its latest listed release is 1.2.2 from 2023-01-28 and the last push was on 2026-05-12.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. youlookwhat/ByWebView on GitHub