search

bumptech / glide

An image loading and caching library for Android focused on smooth scrolling
https://bumptech.github.io/glide/
Other
34.68k stars 6.12k forks source link

Can the interface DiskCache#get(Key key) return InputStream? #821

Open codepackage opened 8 years ago

codepackage commented 8 years ago

My Project has encrypted files to get from diskcache, so use "DiskCache.get(Key key)", I can't read data from file.And I suggest we can change the return "File" with "InputStream".

TWiStErRob commented 8 years ago

See #735 for a workaround. @sjudd this is what I was asking here https://github.com/bumptech/glide/issues/735#issuecomment-156205995. I guess it got lost in notifications. If v4 is breaking APIs, it should break DiskCache as well so it becomes more flexible.

codepackage commented 8 years ago

Thanks for response.

TWiStErRob commented 8 years ago

A workaround is not a fix, let's see what @sjudd says, maybe it can be changed.

sjudd commented 8 years ago

Files offer more flexibility than InputStreams for efficient I/O, notably including memory mapping.

I believe the right answer here is to write a ModelLoader<File, InputStream> that provides InputStreams that do any necessary decryption and prepend it to the set of ModelLoaders. That should have essentially the same effect and should be relatively efficient, especially if you can add a header to the Files to indicate whether or not they are encrypted.

TWiStErRob commented 8 years ago

Is that mapping feature used by Glide? If at all I would imagine that a FileInputStream would do the memory mapping itself, so any other streams wrapped around it benefit. If this is true, using streams in DiskCache interface would benefit as well, and also allow for a wider range of implementations.

Also what about the case of #735 where both encrypt and decrypt is done in the cache? It's weird that we ended up replacing all the decoders and encoders to make the cache work as wanted. I would have imagined that if we want to change the cache behaviour, then we replace the cache...

The current implementation also doesn't allow for blob-like caches: 1 big file with custom storage, where individual file access is seeking in the big file and reading is reading from the seemed location. For example OBBs, so that cache read tries obb first and falls back to a folder LRU cache, writes always write to folder. I know this can be done by model loaders, but a choice would be nice.