Skip to content

Add NetworkFirst CachePolicy #3233

Open
@JeroenBakker-wbd

Description

@JeroenBakker-wbd

Use case

Currently Apollo iOS and Apollo Kotlin have different Cache policies, on iOS there is:

  /// Return data from the cache if available, else fetch results from the server.
  case returnCacheDataElseFetch
  ///  Always fetch results from the server.
  case fetchIgnoringCacheData
  ///  Always fetch results from the server, and don't store these in the cache.
  case fetchIgnoringCacheCompletely
  /// Return data from the cache if available, else return an error.
  case returnCacheDataDontFetch
  /// Return data from the cache if available, and always fetch results from the server.
  case returnCacheDataAndFetch

and on Kotlin there are:

  // (Default) Check the cache, then only use the network if data isn't present
  .fetchPolicy(FetchPolicy.CacheFirst)

  // Check the cache and never use the network, even if data isn't present
  .fetchPolicy(FetchPolicy.CacheOnly)

  // Always use the network, then check the cache if network fails
  .fetchPolicy(FetchPolicy.NetworkFirst)

  // Always use the network and never check the cache, even if network fails
  .fetchPolicy(FetchPolicy.NetworkOnly)

We currently have a UseCase where we would like to have an iOS equivalent of NetworkFirst but only for 1 of our request. Which makes implementing this in an Interceptor a bit overkill. (Which was recommended in #1520). Currently we have implemented this iOS by calling fetchIgnoringCacheData first and then returnCacheDataDontFetch if the first one fails.

Describe the solution you'd like

Would be nice to have feature parity across mobile by supplying the same cache policies on both platforms, which makes collaboration also easier as we will be implementing our features the same way. Currently we have logic differences as this use case is not supported on iOS by cache policy. But vice versa also applies for some iOS policies which are not on Kotlin (like fetchIgnoringCacheData ).

It could also be possible to change Kotlin to match iOS, as these are all specific to request rather than responses and the recommended way would be to use the ErrorInterceptor as described in #1520.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions