Identify network timeout strategies

[xmattjus]

💬 Questions and Help

Hi, first of all thank you for your efforts with this much needed fork!

I opened this issue to identify any available strategy regarding setting a network timeout while downloading an image OR what could be the best plan of action to implement such a feature.

As far as I understand, most suggests to wrap CachedNetworkImage into a FutureBuilder with the future property set to Future.delayed(Duration(seconds: X)). Doing so requires custom State logic to be implemented to take action on future completion whether the CachedNetworkImage finished downloading the image or not in the meantime. Also this method does not close the http connection to the server, leading to (possibly) unexpected behaviour.

Another solution is to set the connectionTimeout property of the http client and then use that client with CacheManager. This solution correctly closes the http connection to the server on timeout, but is set globally per http client (all requests coming from this client will have the same timeout value which could not be optimal). Also, the Android cronet_http library does not expose a connection timeout property at all (dart-lang/http#1186).

Relevant issues:

• Configure load timeout for image provider Baseflow/flutter_cached_network_image#465
• Add Timeout Support for CachedNetworkImage Requests Baseflow/flutter_cached_network_image#1001

What do you think could be the best way to tackle this problem?

Feel free to convert this issue into a discussion as you see fit.

Thanks,
Matteo

[Erengun]

Looking at the best approach for the API, I'd add timeout parameters to both DefaultCacheManager and the image widgets as per-request overrides, then apply them in the download logic. But given that CacheManager is already injectable and users can create custom instances, We should focus on what makes the most sense architecturally. The platform interface constraint is a real blocker here modifying BaseCacheManager would ripple through the entire codebase. Do we need per-image timeout flexibility or if a single configurable timeout at the cache manager level would suffice for our use case.

[Erengun]

Valid issue. Before looking at PRs, we need to decide on a few things:

1. Scope: CacheManager level (clean, no breaking changes) vs Widget level (massive breaking changes across packages). I lean toward CacheManager.
2. Strategy: Connection + Inactivity timeout? A total download timeout will just kill slow connections.
3. Web: This won't work with HtmlImage. Do we just document this limitation, or change the default render method for web entirely?
4. Defaults: null to preserve current behavior, or enforce a default (e.g., 30s)?

Thoughts?

[xmattjus]

1. Given the current library architecture, I'm with you on implementing this on the CacheManager level. Some work has already been done in this PR: Add timeout parameter for downloading Baseflow/flutter_cache_manager#482. This however will mean forking flutter_cache_manager which will increase the maintenance burden.
2. Regarding the timeout strategy, most web frameworks give their users the ability to set a connection timeout (i.e. the time it takes to establish a connection to a server) and a request timeout (i.e. the time it takes for the server to give back a response). If two different timeout parameters are to be implemented, I would prefer a ConnectionParameters class to be added to the CacheManager interface to set those.
3. I'm not familiar with HtmlImage so I'm not sure about this one. However it's not uncommon for properties of a Flutter core class to have no effect on Flutter Web. This wouldn't be any different.
4. Preserving the current behavior is key, so ConnectionParameters (or however you would like to call it) must be nullable.

A more "sane" alternative to forcing a somewhat opinionated take on connection timeouts would be to rewrite CacheManager to uncouple the "http/image download process" to the "write to cache" one, giving at the same time the users the possibility to customize each process entirely (which in turn would simplify the implementation of exponential backoff and other advanced retry strategies). Maybe in the future? 😁

Matteo

[Erengun]

I think we should even decouple the cache manager itself. People don't have to add hive as dependency just to use its custom cache manager at the end. Maybe we can convert this to a bigger issue to decouple cache manager itself to have more control over architecture too.