Offline Cache about algoliasearch-client-swift HOT 9 CLOSED

@stephencroberts The cache behavior is already similar to the "return cache data else load" policy; cf. the Index.search() method: if cached data is available, it will always be returned without calling the API. Also, remember that you can adjust the cache expiration delay when you call enableSearchCache().

However, if I understand your question correctly, what you would like is maybe two separate things:

• Space-bound rather than expiration-based cache eviction? E.g. some kind of LRU mechanism with a maximum object count/size limit.
• Cache persistence on disk, so that if the app is killed, cached results are still available?

Also, maybe it's worth to point out that the cache is, well, just a cache: it will work when the exact same query is issued... but fail to retrieve any results for similar queries. You might be interested in knowing that we are currently working on a new offline mode for the mobile API clients, which will provide real offline search capability by mirroring part of the online indices locally. This will require a dedicated (and separately licensed) SDK. I can't provide any ETA yet for the final release, but a beta version should be available soon for testing. Would you be interested?

from algoliasearch-client-swift.

From what I've seen, the current cache behavior isn't really like "return cache data else load" in 2 ways:

1. It doesn't returned cached data if the device is offline -- it throws a "The Internet connection appears to be offline" error, even if the cache is still valid.
2. It doesn't return expired cache.

Also, from my experience, NSURLCache is already persistent -- the cache persists after the app is killed or the device is rebooted, and I believe it's essentially space-bound as well since the memory and disk caches both have capacity limits.

For other parts of my app, I use AFNetworking and check to see if the network is available (using their reachability manager) -- if it is offline, I can set NSURLRequestReturnCacheDataElseLoad in the request to pull from cache, even expired cache, otherwise I use the cache defaults (which adheres to the response headers).

I haven't looked at your code yet -- do you use NSURLCache or is it custom?

I'm aware this method only caches the same exact requests which works great for my current use-case. I read about the offline mode you guys are working on -- very cool. I would be interested in that as well at some point, but definitely not my main concern right now.

from algoliasearch-client-swift.

I'm positive that if non-expired data exists in the cache for the exact same query, then the cache result is used without even attempting a network request. I just confirmed it on a sample project to make sure. :)

So what you are observing is rather intriguing, and definitely not normal. Are you sure it's not a side effect of your own logic with AFNetworking? Also, which version of the pod are you using? (Latest version is 3.1.) Can you provide sample code that reproduces this behavior?

We don't use NSURLCache, at least not explicitly (we do use NSURLSession for requests, which in turn uses whatever default caching policy is in place). Our custom cache is built on top of NSCache, which sits purely in memory.

from algoliasearch-client-swift.

Ah, that explains it. The use-case I'm most interested in is persistent cache, thus my tests of restarting the app with valid cache only gives me the "no connection" error. I can confirm that when I leave the app open and turn off the network, cached data is returned until it expires.

Would you consider building your cache on top of NSURLCache to take advantage of on-disk as well as in-memory caching already built in?

from algoliasearch-client-swift.

The primary goal of the cache was to address a very specific, yet common, use case: the user pressing the backspace key. :) With the cache, we can provide previous results immediately without waiting for the network, thus improving the user experience. We hadn't really any longer-term usage in mind.

As already stated, the current cache is not an NSURLCache but an NSCache, and the two are not interchangeable. So I'm afraid we cannot build it "on top of NSURLCache" without a major refactoring.

That said, maybe we should allow the user to provide an NSURLSession during client initialization, or let her customize the network caching policy somehow. Not sure this would provide real added value compared to just setting the global cache via NSURLCache.setSharedURLCache().

from algoliasearch-client-swift.

Yeah that makes sense. Are you saying I should be able to achieve the behavior I'm looking for by using NSURLCache.setSharedURLCache()? I've tried subclassing NSURLCache, setting the sharedURLCache, and overriding storeCachedResponse() and cachedResponseForRequest() without any luck.

from algoliasearch-client-swift.

Yes... and no. :) In theory, you should be able to set a custom NSURLCache at the global level and the API client should use it. But I just realized that, in the end, it wouldn't work anyway because the API sends cache-suppression headers in its responses:

Cache-Control: no-cache

So you would have to really hack the cache to make it ignore cache control headers... which I don't recommend.

from algoliasearch-client-swift.

Ah, that explains why it's not working.

Thanks for engaging in the conversation with me. It's definitely not a high-priority issue for me right now, but I would love to see you guys put some thought into it and maybe add some support in the future. Keep up the good work -- Algolia is probably the most enjoyable service I've worked with as a developer.

from algoliasearch-client-swift.

Thank you! We appreciate. :)

I am not sure there's room between a short-term, volatile cache (to address the backspace key) as it is now and a long-term, persistent cache as we will have in the offline mode, but we'll definitely give that a second thought. Thanks for you input.

from algoliasearch-client-swift.