Prevent empty WebView when received HTTP/304 by disabling caching.

[eku]

Fixes #37

[gemini-code-assist]

Hello @eku, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

Summary of Changes

This pull request addresses issue #37, which involves preventing an empty WebView when a HTTP/302 redirect is received. I've achieved this by disabling caching for the WebView. This change modifies the DeviceWebview.kt file to set the cacheMode to WebSettings.LOAD_NO_CACHE.

Highlights

• Bug Fix: Addresses issue #37, preventing empty WebView on HTTP/302 redirects.
• WebView Configuration: Disables caching for the WebView to prevent issues with redirects.

Changelog

• app/src/main/java/ca/cgagnier/wlednativeandroid/ui/components/DeviceWebview.kt
  • Added import for android.webkit.WebSettings.
  • Set cacheMode to WebSettings.LOAD_NO_CACHE to disable caching for the WebView.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

---

A WebView's plight,
Redirects vanish in the night,
No cache to hold,
A story untold,
Content appears, shining bright.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request aims to fix an issue where the WebView displays an empty page due to HTTP 302 redirects by disabling caching. The approach of disabling caching seems reasonable to address this problem. However, it's important to consider the potential performance implications of disabling caching and whether there might be alternative solutions.

Summary of Findings

• Cache Disabling Impact: Disabling cache might impact performance. Investigate if there are alternative solutions that selectively invalidate cache for specific resources or requests.

Merge Readiness

The pull request introduces a change that could have performance implications. While the change addresses the reported issue, it's recommended to investigate alternative solutions that selectively invalidate the cache for specific resources or requests. I am unable to directly approve the pull request, and other reviewers should also review this code before merging. Given the potential performance implications, I recommend that this pull request not be merged until the impact of disabling caching is fully understood and alternative solutions are explored.

[gemini-code-assist]

Disabling the cache completely might have a negative impact on performance. Consider if there's a way to selectively disable caching only for the specific requests that cause the 302 redirect issue, or to invalidate the cache for those resources after the redirect. Could you investigate if setting specific cache control headers on the server-side would be a better approach?

Suggested change

	settings.domStorageEnabled = true
	settings.cacheMode = WebSettings.LOAD_NO_CACHE
	// settings.cacheMode = WebSettings.LOAD_NO_CACHE // Consider a more targeted approach to caching

[eku]

Gemini Code Assist is currently in preview and may make mistakes.

Sure, it did.

[gemini-code-assist]

Thanks for the feedback! I understand that the bot is in preview and may make mistakes. I'll be sure to double-check its suggestions and use my own judgment.

[Moustachauve]

I really wish there was a way to do so without having to disable caching. Caching is pretty nice for most cases.

I'll do a bit more research.

[eku]

I really wish there was a way to do so without having to disable caching. Caching is pretty nice for most cases.

Well, in my case, it makes things worse.

Normally Android's WebView should handle a HTTP/304. It is also possible that the LiveData is the actual cause.

I'll do a bit more research.

You are welcome to investigate further. I would be interested in a quick solution, because currently I can only use the app with my change.

[Moustachauve]

Can you help me reproduce this issue please? How do you setup a proxy to get 304 status for WLED?

[eku]

Can you help me reproduce this issue please? How do you setup a proxy to get 304 status for WLED?

1. Install and configure a caching proxy in your network. I use squid, but it is powerful and not so easy to configure. cache-proxy might work.
2. Configure WLAN profile of your phone to use the proxy
3. Run WLED-Native
4. You might want to sniff network traffic to be sure that the proxy is used and returns HTTP/304.

Let me know if I can provide further support.

[eku]

@Moustachauve Any progress so far?

[Moustachauve]

@eku I thought of a potential solution, I'd like your opinion.

The app could add a cache busting query param, for example: http://192.168.1.10/?_t=1678886400123 (where 1678886400123 is the current time in milliseconds).

Because the URL is different every time, the proxy and the browser cache will see it as a request for a new resource and will be forced to fetch it from the server (getting an HTTP/200 response) instead of replying with a 304 Not Modified.

The main advantage would be that it only forces the main page to reload. Other assets (like CSS, JavaScript, images) that are loaded can still be cached by the WebView.

If you think it sounds like a good idea, would you mind giving it a try please? I have not had time to setup a proxy to test this issue.

[eku]

@eku I thought of a potential solution, I'd like your opinion.
[...]

Do you have a feature branch with the changes you have in mind? Don't worry about building the app from it, I can do it myself.