🤔 Does This Project Support @JavascriptInterface-like Annotations for JS-Native Communication?

[strange-qwq]

I noticed the documentation mentions JS-Native interaction only through window.kmpJsBridge.callNative. While the JsBridge name is configurable, it appears restricted to using the callNative method pattern.

In Android projects, we use @JavascriptInterface annotations to expose native methods directly to JS. ​​Does this project support similar annotation-driven approaches?​​

Though JS function mapping could be a workaround, ​​is there a zero-configuration solution that preserves existing frontend code?​​ I'm looking for a way to achieve bidirectional communication without rewriting existing JS invocation logic.

[guyaumetremblay]

@KevinnZou You talk about a customization of the method name here: #80 (reply in thread)

Is it still planned ?

[Alox1d]

In the 2.0.3 bridge API, registration is through IJsMessageHandler; there isn't an annotation processor that exports arbitrary Kotlin methods as JavaScript methods. Changing the bridge's object name changes its namespace, not the callNative dispatch protocol. The bridge implementation shows that distinction.

If your existing frontend API is callback-based, a small compatibility layer can preserve its call sites. For example, to retain Native.greet(message, onResult):

window.Native = window.Native || {};
window.Native.greet = function (message, onResult) {
  window.kmpJsBridge.callNative(
    "Greet",
    JSON.stringify({ message }),
    onResult
  );
};

Register a Kotlin handler whose methodName() is "Greet", and pass that bridge to WebView. Load this adapter before the existing frontend invokes Native.greet, and invoke it only once the native bridge is available. The communication guide documents the JSON string parameters and response callback.

One limitation matters: an existing synchronous call such as const value = Native.getValue() cannot keep that return-value contract through this asynchronous bridge. Those callers need a callback/Promise adaptation. So this can preserve suitable frontend APIs, but it isn't a zero-configuration replacement for every @JavascriptInterface method.