Open JustFanta01 opened 6 months ago
This update enhances Cryptomator's functionality for managing image files by implementing thumbnail caching and management. It introduces new methods for associating thumbnails with cloud files, improves cache handling during file operations, and integrates user preferences for thumbnail generation. The changes also include enhancements to the user interface for better interaction with visible cloud file nodes.
File Path | Changes Summary |
---|---|
.../crypto/CryptoImplDecorator.kt |
Enhanced thumbnail caching, added methods for cache management, and introduced thumbnail generation logic. |
.../presentation/presenter/BrowseFilesPresenter.kt |
Added methods for managing thumbnail associations and downloads, updated constructor to include new use case. |
.../presentation/ui/fragment/BrowseFilesFragment.kt |
Implemented functionality for fast scrolling and managing visible nodes in the RecyclerView. |
CryptoFile
class.🐇✨
A hop and a skip in the code so neat,
Thumbnails cache and files so sweet.
With every change, a better flow,
Cryptomator's charm, now on the show!
🌟📁🌟
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
@JustFanta01 Not a review, but a general suggestion: ~For caching you use https://github.com/JakeWharton/DiskLruCache, which is unmaintained since 8 yrs.~ Consider using https://github.com/ben-manes/caffeine instead, which is a modern and quite good caching library.
Edit: my bad, this was the wrong dependency.
Thank you so much for this contribution :heart:, will have a closer look to it on Monday!
Consider using https://github.com/ben-manes/caffeine instead, which is a modern and quite good caching library.
@infeo can you please explain in detail why we should switch from DiskLruCache to Caffeine?
@SailReal I withdraw my suggestion^^ First, i thought this was an outdated, unmaintained dependency, but i was wrong. Second, the project already uses this dependency and then it is good practice to use what's already there. And third, the dependency targets Android, so i guess it is also "optimized" for the OS in some way.
Regarding Caffeine: It uses a different algorithm with a statistically higher hit rate. See also https://github.com/ben-manes/caffeine/wiki/Efficiency.
Also there is a bug if you use an svg-file, then BitmapFactory.decodeStream(thumbnailReader, null, options)
returns null
, thumbnailBitmap
is then null
(I think we shouldn't even call ThumbnailUtils.extractThumbnail
if it is null) and then it crashes when we write to it in thumbnailWriter.write(buff.array(), 0, buff.remaining())
because we didn't even create the file we want to write into
org.cryptomator.domain.exception.FatalBackendException: java.io.IOException: Pipe closed
at org.cryptomator.data.cloud.crypto.CryptoImplDecorator.read(CryptoImplDecorator.kt:422)
at org.cryptomator.data.cloud.crypto.CryptoCloudContentRepository.read(CryptoCloudContentRepository.kt:95)
at org.cryptomator.data.cloud.crypto.CryptoCloudContentRepository.read(CryptoCloudContentRepository.kt:21)
at org.cryptomator.data.repository.DispatchingCloudContentRepository.read(DispatchingCloudContentRepository.kt:160)
at org.cryptomator.domain.usecases.cloud.DownloadFiles.execute(DownloadFiles.java:32)
at org.cryptomator.domain.usecases.cloud.DownloadFilesUseCase$Launcher$2.subscribe(DownloadFilesUseCase.java:99)
at io.reactivex.internal.operators.flowable.FlowableFromPublisher.subscribeActual(FlowableFromPublisher.java:29)
at io.reactivex.Flowable.subscribe(Flowable.java:14935)
at io.reactivex.Flowable.subscribe(Flowable.java:14882)
at io.reactivex.internal.operators.flowable.FlowableSubscribeOn$SubscribeOnSubscriber.run(FlowableSubscribeOn.java:82)
at io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker$BooleanRunnable.run(ExecutorScheduler.java:288)
at io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker.run(ExecutorScheduler.java:253)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:920)
Caused by: java.io.IOException: Pipe closed
at java.io.PipedInputStream.checkStateForReceive(PipedInputStream.java:263)
at java.io.PipedInputStream.awaitSpace(PipedInputStream.java:271)
at java.io.PipedInputStream.receive(PipedInputStream.java:234)
at java.io.PipedOutputStream.write(PipedOutputStream.java:149)
at org.cryptomator.data.cloud.crypto.CryptoImplDecorator.read(CryptoImplDecorator.kt:398)
at org.cryptomator.data.cloud.crypto.CryptoCloudContentRepository.read(CryptoCloudContentRepository.kt:95)
at org.cryptomator.data.cloud.crypto.CryptoCloudContentRepository.read(CryptoCloudContentRepository.kt:21)
at org.cryptomator.data.repository.DispatchingCloudContentRepository.read(DispatchingCloudContentRepository.kt:160)
at org.cryptomator.domain.usecases.cloud.DownloadFiles.execute(DownloadFiles.java:32)
at org.cryptomator.domain.usecases.cloud.DownloadFilesUseCase$Launcher$2.subscribe(DownloadFilesUseCase.java:99)
at io.reactivex.internal.operators.flowable.FlowableFromPublisher.subscribeActual(FlowableFromPublisher.java:29)
at io.reactivex.Flowable.subscribe(Flowable.java:14935)
at io.reactivex.Flowable.subscribe(Flowable.java:14882)
at io.reactivex.internal.operators.flowable.FlowableSubscribeOn$SubscribeOnSubscriber.run(FlowableSubscribeOn.java:82)
at io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker$BooleanRunnable.run(ExecutorScheduler.java:288)
at io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker.run(ExecutorScheduler.java:253)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:920)
ErrorCode: F1D9:OBF0
In this case, the file can not be opened anymore.
Please also test it with further other file types.
Hello guys 👋 This is our proposal for implementing thumbnail support [/issues/41] Me, @WheelyMcBones and @taglioIsCoding have made the following changes.
We have implemented a uniform solution that works both for local and the remote clouds, this solution exploits the DiskLruCache in the CryptoImplDecorator and in the CryptoImplVaultFormat(Pre)7. We have decided these two location because we have access to all necessary informations: the decrypted image and the cloud type.
In cache we save a thumbnail when someone reads an image file and retrieve it from the same cache during the listing process. Thumbnails are stored as decrypted files in cache and, unlike other files in the /decrypted folder, these are persistent until the cache is deleted. We added the attribute ".thumbnail" in the CryptoFile pointing to the file in the disk cache and the CloudFileModel wraps it around. We also added the Preference in the Settings for when it is supposed to generate the thumbnails. Finally we got rid of the full duplication of the image by elaborating the thumbnail in stream with an ad-hoc Thread pool.