I'm intending to use DiskLruCache to cache all Http Request from my application. Every request to a server will be cached for re-using.

It would be great if we can configure the absolute expiration for the cache, so after an amount of time, cache will be cleared automatically, in order to get fresh data, and then cache it.

This gives us the ability to work with File class and not only with InputStream. Since DiskLruCache is caching data in files it is useful to manipulate with File-s.

Example: I used this cache to store .mp4 files. Android MediaPlayer class doesn't work with InputStream so I used absolute path of File to start playback. But to get File from cache I've added this code.

Useful for HTTP caching and other cases.

For instance:

URL url = new URL("http://host/path");
String myKey = String.valueOf(url.hashCode()); // may be a negative integer

I have the cache put inside a subdirectory in the application cache directory. On devices with low internal storage (Nexus One for example) this will eventually lead to low storage situations where Android will just clear the whole cache directory, including subdirectories.

This gives this:

java.io.FileNotFoundException: /data/data/<package>/cache/images/-1944396650.0.tmp (No such file or directory)
at org.apache.harmony.luni.platform.OSFileSystem.open(Native Method)
at dalvik.system.BlockGuard$WrappedFileSystem.open(BlockGuard.java:232)
at java.io.FileOutputStream.<init>(FileOutputStream.java:94)
at java.io.FileOutputStream.<init>(FileOutputStream.java:66)
at <package>.DiskLruCache$Editor.newOutputStream(DiskLruCache.java:686)

It's thrown because the images directory is now gone. I though listening for ACTION_DEVICE_STORAGE_LOW could solve this but that is broadcasted after Android has cleared the directory.

If would be nice if it was possible to just reset the cache when the whole directory has gone missing or something.

This removes all synchronized statements in favor of a ReentrantReadWriteLock. This allows read operations to not block each other, but write operations to block everything (the way synchronized was working previously).

With the addition of a simple contains() method, it is now super cheap to check if an image exists in the cache.

Added unit tests for the new contains() method.

This PR removes all synchronized statements in favor of a ReentrantReadWriteLock. This allows read operations to not block each other, but write operations to block everything (the way synchronized was working previously).

With the addition of a simple contains() method, it is now super cheap to check if an image exists in the cache.

While trying to reduce garbage collections in a sample app, I noticed that this library allocates a couple of strings per request (once for the file name, and once to join the directory and the file name) which generates enough garbage to cause gcs to noticeably increase in frequency.

The largest strings I saw were around 300 characters so the memory overhead of holding on to the files for each entry is probably pretty small. Even with 5000 entries in memory at once the total overhead would be less than 3mb (300 characters * 2 bytes per character * 5000 entries). At the same time even with only a few items per row, scrolling a list could easily generate a couple of kB worth of garbage per row.

Hi!

I'm loading images in ListView from DiskLruCache. ListAdapter.getView() method creates AsyncTask which loads image from DiskLruCache. And there is very strange behavior - DiskLruCache.get() returns null on last one ListView element in bunch of lazy loaded ListView elements.

To simplify situation imagine loop:

for (i...) { SnapShot value = DiskLruCache.get("key"+i); }

For the last "i" value is null. A checked that on UI thread also, but still same result.

If it's not a bug but my mistake maybe someone would help me with issue?

Thanks!

P.S. DDMS shows that cache entry exist. Clearing and filling it again brings same result. P.P.S. It does not depend on items count. It could be different entry from time to time, but always last in bunch of get() calls

In order to always match an edit to a commit() or abort(), even in case of exceptions, it would be nice to be able to do this:

Editor e = cache.edit(key);
try {
  // edit values
  e.commit();
} finally {
  e.close(); // will abort(), unless the editor has already been committed or aborted
}

I can submit a pull request if preferred.

I have exported and uploaded test results. Maybe sth happen or OS security policy. But some tests show sth wrong for example;

DiskLruCache.Editor creator = cache.edit("k1"); creator.set(0, "A"); DiskLruCache.Editor updater = cache.edit("k1"); updater.set(0, "C"); DiskLruCache.Snapshot snapshot = cache.get("k1"); assertThat(snapshot.getString(0)).isEqualTo("C");

It was failed.

Maybe, You will check all test result...

testResults.pdf

Thanks.

This is a much faster way of checking if a given key exists in the cache.

In a demanding use-case, scrolling very quickly, where every item in a ListView must check to see if it's object's key exists in the DiskCache: Some basic profiling showed this method taking ~3ms vs using get( key ) taking on average ~70ms. I believe this is because get() is synchronized.

It should be safe to use contains() unsynchronized like this.

This addresses issue #54

I am developing an OpenHarmony application that uses the JavaScript language. Can you support the OpenHarmony JavaScript version? I am willing to participate in the development and look forward to reply.

I added cache entry creation time param to Snapshot. With this simple feature we can make expiration cache. Example: private Bitmap getExpired( String key, long expire, TimeUnit timeUnit ) { Bitmap bitmap = null; try ( DiskLruCache.Snapshot snapshot = mDiskCache.get( key ) ) { if ( snapshot == null ) return bitmap; long expiredTime = new Date().getTime() - timeUnit.toMillis( expire ); if ( expire > 0 && snapshot.getCreatedTime() < expiredTime ) return null; final InputStream in = snapshot.getInputStream( 0 ); if ( in != null ) { final BufferedInputStream buffIn = new BufferedInputStream( in, IO_BUFFER_SIZE ); bitmap = BitmapFactory.decodeStream( buffIn ); } } catch ( IOException e ) { e.printStackTrace(); } return bitmap; }

File#listFiles() will return null if the directory has been deleted. This scenario isn’t totally far fetched because it’s fairly common for Android developers to place their disk caches in the Android application cache directory. The cache directory can be cleared at any time by the system, including while the app is open, which in turn can cause unexpected IOExceptions when delete() is called.

See https://github.com/bumptech/glide/issues/2465 for additional context.

https://github.com/JakeWharton/DiskLruCache/blob/3e016356cfc7e5f9644a7a732fe0223e9742e024/src/main/java/com/jakewharton/disklrucache/DiskLruCache.java#L95

I came across an exception where my key length exceeded 64 characters, so I was browsing through the repo to figure out a reason for this cap on key length. It seems after the key length was increased, the newer jar never got deployed to maven/bintray.

It would be great if we can have a way to know the count of the entities and even better if we can have an iterator of the snapshots like the one in the OkHttp implementation.