Taking advantage of HTTP caching #26
Description
I wanted to point out that the app currently does not appear to take advantage of standard HTTP caching mechanisms such as ETag and If-Modified-Since / Last-Modified headers when fetching images.
For image providers that support these headers, conditional requests would be extremely beneficial:
- Providers can signal when an image has not changed via 304 Not Modified
- Bandwidth usage is significantly reduced
- Battery and data usage on the device are improved
- Servers are hit less aggressively, especially with frequent refresh intervals
This is particularly relevant in my use case: my image provider updates at unpredictable times. I need to poll regularly to detect changes, but without conditional requests, the app re-downloads the full image every time even when nothing has changed.
Ideally, the app would:
- Persist ETag and/or Last-Modified values per remote
- Send If-None-Match and/or If-Modified-Since on subsequent requests
- Skip image processing and wallpaper updates when a 304 Not Modified response is returned
This would be fully backward-compatible, since providers that don’t support caching headers would behave exactly as they do now.
If this is something you’d be open to, I’d be happy to implement this optimization