FrontApp LiveChat integration in android - Webview not get hide as per guide

  • 5 March 2024
  • 4 replies

Hello Front Support.


Can anybody answer my Question


Best answer by evano 14 March 2024, 19:03

View original

4 replies

Userlevel 2
Badge +5

Hi jamesai,

It looks like the shouldOverrideUrlLoading method that the example code Front LiveChat uses was deprecated in API level 24:,%20java.lang.String)

Does this only impact Android 14?  I would recommend also overriding the overloaded method shouldOverrideUrlLoading method with WebResourceRequest in its signature to test this:

override fun shouldOverrideUrlLoading (WebView view, 
                WebResourceRequest request): Boolean {
webView.visibility = View.INVISIBLE
openChatButton.visibility = View.VISIBLE
return false


Hi @evano, I have tried this also. Still the same result. 
This time I have tried running on real device and emulator. Real device Android version is 12. 

One more thing I have noticed window.FrontChat(‘show’, 1000) in setTimeout does not work reliable.

Its get failed to init the chat window and only white screen shows always when not init successfully. On Some devices its working with 2000 delay, some devices 3000


"<script>" +
"setTimeout(() => window.FrontChat('show'), 1000)" +
"</script>" +


Also I want the iOS equivalent guide. Is there any documentation available for this?

Also can we capture the event in our activity about the chat window show/close?

Userlevel 2
Badge +5

Regarding the original question:

In Step 8 of the, the handler is added to the code that will close the webview when the URL changes.  Your SO question focused on that method, and there is indeed a red herring about the API levels that took us some time to realize it's not the issue: what is updating the URL during the chat session?

When answering that question, we found the bug in our docs.  The docs say to pass a parameter to init called shouldMobileReloadOnClose.  Except that method doesn’t appear in our code.  It's a typo, and the proper method name is shouldMobileRefreshOnClose.  When we made that change, the webview properly refreshed, which called the handler, which hides the webview and brings back the button.

We’ve updated the documentation to correct this typo.

Regarding your other questions:

  • We don’t provide an iOS equivalent guide at this time.
  • There’s no method to track this through the SDK yet.  You can request this feature on our Ideas Portal: