Provide way of only unregister specific instance of WebView

[JohannesPtaszyk]

Hello,

we are currently facing an issue while having multiple WebViews on different Screens inside our compose app.
It might occur sometimes, that we navigate through the app and call unregister() on the AdjustBridge, to clean up the WebView when leaving a screen. But in some cases it occurs that a new WebView was already active and registered at that point, so we should not unregister the new instance, but as the unregister is called slightly after the new one was registered, we have a fuckup.

It would be great if we could either have support for registering and unregistering multiple WebView instances OR if we could pass a WebView instance to the unrigster() (Maybe just an overload which takes the parameter) and then only execute the unregister code, if the instance is the same one as the currently attached one.

[shashanksu]

Hi @JohannesPtaszyk

Sorry for the late reply.

AdjustBridge support one WebView at a time. And hence it would require a cycle of register and unregister before injecting another WebView. This needs to be maintained at app level.
We can think of supporting multiple WebViews at a time in future, but not at the moment.

Please let me know if you have any more concerns.

Thank you.

[JohannesPtaszyk]

Hey, there is no way of properly handling this, when transitioning from one screen with a web view to another one.

We need a way to deregister and register explicit instances.

Right now it can happen that transition leads to errors and keeping the wrong instance registered for example while using compose with navigation component.

So we need a solution from your side.
Either letting us check, which instance is currently registered or letting us register multiple instances and explicitly deregistering instances.

Right now, your implementation limits us in a way, that we can never unregister properly and therfor your bridge will forever hold the instance of the web view that was last registered, which leads to the issue that the system cannot properly clean up that instance from memory.

This is still a concern.

Sorry for the late reply :)

[shashanksu]

Hi @JohannesPtaszyk ,

there is no way of properly handling this, when transitioning from one screen with a web view to another one.

While transitioning from current screen, wouldn't it be possible for you to unregister the webview by calling AdjustBridge.unregister() in the current screen? And after transition to new screen, register the corresponding webview by calling AdjustBridge.register(..).

The overall idea is, before registering a new webbiew, the old registered webview should be unregistered. So if you can explain a bit more, it would be helpful for us to understand why it is technically not possible to maintain a sequence of register and unregister instance for a webview?

Thanks

[JohannesPtaszyk]

Transition with compose navigation leas to first showing the new screen and registering the new web view and then calling onDispose in the effect which unregisters.
So no, it does not work that way in compose world.
Definitely need changes from you, so we can pass explicit instance of web view to unregister, so we do not accidentally unregister the newly registered web view.
It's would be easy to just create an override function which takes the instance and only unregistered if it matches or create multi web view support.

[shashanksu]

Thanks for sharing more context. So in order to overcome the limitation that onDispose brings, I see two options here to try:

1. Call AdjustBridge.unregister manually during screen navigation using a callback or state to detect the navigation event in the current screen, rather than relying on onDispose.
2. Alternatively, try setting a webView of the new screen in the same instance by calling AdjustBridge.setWebView(webView)

Please let us know the outcome, thanks.

[JohannesPtaszyk]

Hey,

While 1. could be an option, it is not ideal.
We would couple navigation code to the web view implementation, which does not allow for decoupling and clean code.

Option 2. Is what we are doing leading to you holding a Referenz to the last shown web view all day, so it can not be cleaned up by GC.

So both options are not clean.
Could you please provide added functionality to prevent this, as I described above. It's a fairly easy to implement solution and gives proper controll to your users.

[shashanksu]

Hi @JohannesPtaszyk ,

Passing explicit instance of webview to unregister API won't help, till it support multiple webviews in the same webbridge instance.
We'll discuss internally if multiple webviews support can be prioritised. But for now, those are the only possible options I shared earlier.

Please let me know if there are any other concerns, otherwise we can close the issue.

Thanks

[JohannesPtaszyk]

Sorry, but that's not really a true statement, if you check the already registered instance if it matches the passed one and only remove if it does, it would already help.
Or am I missing something?

Thanks a lot! ☺️

[shashanksu]

The solution you are suggesting would make sense with multiple webviews support. With single webview support, unregister method simply meant to unregister the webView that webbridge instance currently holding. For your custom requirement, best would be to have it handled in the app.

[JohannesPtaszyk]

That is not true. If you would provide an override that takes an instance and only unregister the current on, if it matches, then we would be able to solve the issue on our side already, even without having support for multiple instances.

Because flow would be like this if we navigate from screen with WebView to another one with WebView:

1. Open Screen A
2. Register WebView A
3. Navigate to Screen B
4. Register WebView B
5. OnDispose is called and we try to unregister WebView A
6. Override would not unregister WebView A, because B is already registered.

Flow if we navigate from WebView Screen to full native screen:

1. Open Screen A
2. Register WebView
3. Navigate to Screen B
4. OnDispose is called and we try to unregister WebView
5. Unregister WebView A is done properly

[JohannesPtaszyk]

Hey, are there any updates on this? 🫠

[JohannesPtaszyk]

Hey, we are still facing this issue and its causing WebViews to be in memory unnecessarily.
Are there any plans to look into this? Should we propose something more detailed?

[shashanksu]

Hi @JohannesPtaszyk , Thanks for your patience. Yes, it would be helpful if you can share a detailed proposal.