Configuration used: CodeRabbit UI
Review profile: CHILL

util/src/main/java/org/cryptomator/util/ThumbnailsOption.kt (1)

3-8: Add KDoc comments to improve code documentation.

While the enum is straightforward, adding KDoc comments would enhance its usability and maintainability. Consider adding a class-level comment explaining the purpose of this enum and brief comments for each constant to clarify their meanings.

Here's a suggested implementation with KDoc comments:

/**
 * Represents the various options for thumbnail generation and management in the application.
 */
enum class ThumbnailsOption {
    /** Never generate thumbnails. */
    NEVER,
    
    /** Generate thumbnails for read-only operations. */
    READONLY,
    
    /** Generate thumbnails on a per-file basis. */
    PER_FILE,
    
    /** Generate thumbnails on a per-folder basis. */
    PER_FOLDER
}

domain/src/main/java/org/cryptomator/domain/usecases/cloud/AssociateThumbnails.java (3)

18-22: LGTM: Constructor is well-implemented with a minor suggestion.

The constructor properly initializes the fields and follows the principle of dependency injection. The use of the @Parameter annotation on the list parameter is noted.

Consider adding a null check for the cloudContentRepository parameter to ensure it's not null, as it's a critical dependency:

 public AssociateThumbnails(CloudContentRepository cloudContentRepository, //
 		@Parameter List<CloudNode> list) {
+	if (cloudContentRepository == null) {
+		throw new IllegalArgumentException("cloudContentRepository must not be null");
+	}
 	this.cloudContentRepository = cloudContentRepository;
 	this.list = list;
 }

---

24-26: LGTM: Execute method is well-implemented with a minor suggestion.

The execute method is appropriately defined and follows good practices:

• It takes a ProgressAware<FileTransferState> parameter for progress tracking.
• It can throw a BackendException for error handling.
• It correctly delegates the work to the repository, adhering to the separation of concerns principle.

Consider adding a null check for the progressAware parameter to provide a clearer error message if it's null:

 public void execute(ProgressAware<FileTransferState> progressAware) throws BackendException {
+	if (progressAware == null) {
+		throw new IllegalArgumentException("progressAware must not be null");
+	}
 	cloudContentRepository.associateThumbnails(list, progressAware);
 }

---

1-27: Overall assessment: Well-implemented use case for thumbnail association.

This new AssociateThumbnails class is a well-structured implementation of the thumbnail association use case. It aligns with the PR objectives and follows good software engineering practices:

1. Clear separation of concerns
2. Dependency injection
3. Proper error handling
4. Use of custom annotations for better code organization

The suggested minor improvements (null checks) would further enhance the robustness of the code.

Consider adding unit tests for this class to ensure its behavior is correct, especially testing edge cases and error scenarios.

presentation/src/main/res/values/arrays.xml (2)

45-50: LGTM! Consider clarifying the "per folder" option.

The thumbnail_generation_entries array is well-structured and provides a good range of options for thumbnail generation. It follows the existing pattern in the file and uses string resources, which is great for localization.

Consider adding a comment or documentation to clarify that the "per folder" option (@string/thumbnail_generation_folder) is not yet implemented, as mentioned in the PR objectives. This will help prevent confusion for other developers or users.

---

45-57: Overall, good addition of thumbnail generation options.

The new thumbnail_generation_entries and thumbnail_generation_values arrays are well-structured and provide valuable configuration options for thumbnail generation in the application. They align with the PR objectives and follow the existing patterns in the file.

A few points to consider:

1. Clarify the status of the "per folder" option in comments or documentation.
2. Ensure consistency between the arrays and the actual implementation, especially regarding the "PER_FOLDER" option.
3. These changes will likely require corresponding updates in the application's settings UI and backend logic to handle the new options.

As you implement the logic for these new thumbnail generation options, consider the following:

• Ensure that the option selected by the user is properly persisted and retrieved.
• Implement appropriate logic in the thumbnail generation process to respect these settings.
• Update the UI to reflect the chosen option and possibly disable the "PER_FOLDER" option if it's not yet implemented.
• Consider adding unit tests to verify that the thumbnail generation behavior correctly follows the selected option.

domain/src/main/java/org/cryptomator/domain/repository/CloudContentRepository.kt (2)

98-101: LGTM: New method associateThumbnails added

The new method associateThumbnails is well-structured and consistent with the interface's style. It aligns with the PR objectives of implementing thumbnail functionality.

Consider adding KDoc comments to describe the method's purpose, parameters, and potential exceptions. For example:

/**
 * Associates thumbnails with a list of cloud nodes.
 *
 * @param list The list of cloud nodes to associate thumbnails with.
 * @param progressAware An object to track the progress of the thumbnail association process.
 * @throws BackendException if there's an error during the thumbnail association process.
 */
@Throws(BackendException::class)
fun associateThumbnails(list: List<NodeType>, progressAware: ProgressAware<FileTransferState>) {
    // default implementation
}

---

Line range hint 1-102: Summary: Thumbnail support added to CloudContentRepository interface

The changes to CloudContentRepository.kt are minimal and focused, adding support for thumbnail functionality as outlined in the PR objectives. The new associateThumbnails method provides a clear extension point for implementing thumbnail association in concrete classes. The interface remains flexible and consistent with its existing design.

As the thumbnail functionality is implemented, consider the following architectural points:

1. Ensure that concrete implementations of this interface handle potential errors gracefully, especially when dealing with different file types (e.g., SVG files as mentioned in the PR comments).
2. Consider adding a method to retrieve thumbnails, which might be useful for UI components that display file listings with thumbnails.
3. As the thumbnail feature evolves, you might want to add methods for managing the thumbnail cache (e.g., clearing, updating, or checking cache status) in this interface or a related one.

data/src/main/java/org/cryptomator/data/cloud/crypto/CryptoCloudContentRepository.kt (2)

99-102: LGTM: New method associateThumbnails implemented correctly.

The new method is well-implemented and aligns with the PR objectives for thumbnail functionality. It correctly delegates the call to the cryptoImpl instance and uses ProgressAware for tracking progress.

Consider adding a KDoc comment to describe the purpose of this method and its parameters. For example:

/**
 * Associates thumbnails with a list of CryptoNode objects.
 *
 * @param list The list of CryptoNode objects to associate thumbnails with.
 * @param progressAware A ProgressAware object to track the progress of the operation.
 * @throws BackendException if there's an error during the thumbnail association process.
 */
@Throws(BackendException::class)
override fun associateThumbnails(list: List<CryptoNode>, progressAware: ProgressAware<FileTransferState>) {
    cryptoImpl.associateThumbnails(list, progressAware)
}

This documentation will improve code readability and maintainability.

---

Line range hint 1-140: Summary: Thumbnail functionality successfully implemented.

The changes in this file effectively implement the thumbnail functionality as described in the PR objectives. The new associateThumbnails method is well-integrated into the existing CryptoCloudContentRepository class, following the established patterns and coding style.

Key points:

1. The new import and method are correctly placed and implemented.
2. The changes are minimal and focused, reducing the risk of unintended side effects.
3. The use of ProgressAware allows for tracking the progress of thumbnail association, which is beneficial for user experience.

These changes contribute to the overall goal of providing thumbnail support for both local and remote cloud storage in the Cryptomator Android application.

As the thumbnail functionality evolves, consider the following architectural points:

1. Ensure that the cryptoImpl implementations (e.g., CryptoImplVaultFormat8, CryptoImplVaultFormat7, etc.) have consistent implementations of the associateThumbnails method.
2. Monitor the performance impact of thumbnail generation and association, especially for large folders or slow network connections.
3. Consider implementing caching strategies to optimize thumbnail retrieval in future iterations.

data/src/main/java/org/cryptomator/data/repository/DispatchingCloudContentRepository.kt (1)

168-180: Good implementation, but consider adding documentation and a safety check.

The associateThumbnails method is well-implemented and follows the existing patterns in the class. However, there are a couple of suggestions for improvement:

1. Add KDoc documentation to explain the purpose of the method and its parameters.
2. Consider adding a check to ensure all nodes in the list belong to the same cloud, as the current implementation assumes this is the case.

Here's a suggested implementation with these improvements:

/**
 * Associates thumbnails with the given list of CloudNodes.
 *
 * @param list The list of CloudNodes to associate thumbnails with.
 * @param progressAware A ProgressAware object to track the file transfer state.
 * @throws IllegalArgumentException if the list contains nodes from different clouds.
 * @throws IllegalStateException if the cloud is null for any node.
 * @throws AuthenticationException if there's an authentication error.
 */
@Throws(BackendException::class)
override fun associateThumbnails(list: List<CloudNode>, progressAware: ProgressAware<FileTransferState>) {
    if (list.isEmpty()) {
        return
    }
    
    val cloud = list[0].cloud ?: throw IllegalStateException("Cloud shouldn't be null")
    
    // Ensure all nodes belong to the same cloud
    if (list.any { it.cloud != cloud }) {
        throw IllegalArgumentException("All nodes must belong to the same cloud")
    }
    
    try {
        networkConnectionCheck.assertConnectionIsPresent(cloud)
        delegateFor(list[0]).associateThumbnails(list, progressAware)
    } catch (e: AuthenticationException) {
        delegates.remove(cloud)
        throw e
    }
}

This implementation adds documentation, ensures all nodes belong to the same cloud, and simplifies the null check for the cloud.

data/src/main/java/org/cryptomator/data/cloud/crypto/CryptoImplVaultFormatPre7.kt (3)

131-131: Approve with suggestion: Consider logging unexpected null values.

The addition of .filterNotNull() is a good defensive programming practice that aligns with Kotlin's null safety features. It prevents potential null pointer exceptions in the code that consumes this list.

However, if null values are not expected in this list, their presence might indicate an underlying issue that should be addressed.

Consider adding logging for unexpected null values before filtering them out. This can help in identifying and addressing the root cause of null values. For example:

.map { node ->
    ciphertextToCleartextNode(cryptoFolder, dirId, node)
}.toList().onEach { if (it == null) Timber.w("Unexpected null value in list for folder: ${cryptoFolder.name}") }.filterNotNull()

---

229-229: Approve with suggestion: Add error handling for cache renaming.

The addition of renameFileInCache(source, target) is a good step to maintain consistency between the file system and the cache during move operations. This aligns with the thumbnail caching functionality mentioned in the PR objectives.

However, it's important to ensure that the move operation remains robust even if the cache renaming fails.

Consider adding error handling for the cache renaming operation. This will ensure that the move operation completes successfully even if there's an issue with updating the cache. For example:

try {
    renameFileInCache(source, target)
} catch (e: Exception) {
    Timber.e(e, "Failed to rename file in cache during move operation. Source: ${source.name}, Target: ${target.name}")
    // Optionally, you might want to invalidate the cache entry if renaming fails
    // invalidateCacheEntry(source)
}

---

250-258: Approve with suggestions: Add error handling and consider potential race conditions.

The addition of cache deletion logic when deleting a CryptoFile is a good improvement. It ensures that the cache remains consistent with the actual file system, preventing potential issues with stale cached data.

However, there are a few points to consider:

1. Error Handling: Add try-catch block to handle potential exceptions during cache deletion.
2. Race Conditions: Consider potential race conditions where the cache entry might be accessed while being deleted.
3. Logging: Add logging for cache deletion operations for better traceability.

Here's a suggested implementation addressing these points:

val cacheKey = generateCacheKey(node)
node.cloudFile.cloud?.type()?.let { cloudType ->
    getLruCacheFor(cloudType)?.let { diskCache ->
        try {
            diskCache.edit(cacheKey)?.let { editor ->
                editor.abort()  // Prevent further access to this cache entry
                diskCache.remove(cacheKey)
                Timber.d("Successfully deleted cache entry for file: ${node.name}")
            }
        } catch (e: Exception) {
            Timber.e(e, "Failed to delete cache entry for file: ${node.name}")
        }
    }
}

This implementation uses the edit() and abort() methods to prevent race conditions, adds error handling, and includes logging for better traceability.

util/src/main/java/org/cryptomator/util/SharedPreferencesHandler.kt (2)

164-172: LGTM! Consider using an enum for better type safety.

The generateThumbnails() method is well-implemented and correctly handles different thumbnail generation options. It provides a good default value and uses Kotlin's when expression effectively.

To improve type safety and readability, consider defining an enum for the thumbnail generation options:

enum class ThumbnailGenerationOption(val value: String) {
    NEVER("NEVER"),
    READONLY("READONLY"),
    PER_FILE("PER_FILE"),
    PER_FOLDER("PER_FOLDER");

    companion object {
        fun fromString(value: String): ThumbnailGenerationOption = 
            values().find { it.value == value } ?: NEVER
    }
}

Then, update the generateThumbnails() method:

fun generateThumbnails(): ThumbnailsOption {
    val option = defaultSharedPreferences.getValue(THUMBNAIL_GENERATION, ThumbnailGenerationOption.NEVER.value)
    return ThumbnailGenerationOption.fromString(option).toThumbnailsOption()
}

private fun ThumbnailGenerationOption.toThumbnailsOption(): ThumbnailsOption {
    return when (this) {
        ThumbnailGenerationOption.NEVER -> ThumbnailsOption.NEVER
        ThumbnailGenerationOption.READONLY -> ThumbnailsOption.READONLY
        ThumbnailGenerationOption.PER_FILE -> ThumbnailsOption.PER_FILE
        ThumbnailGenerationOption.PER_FOLDER -> ThumbnailsOption.PER_FOLDER
    }
}

This approach provides better type safety and makes it easier to add or modify options in the future.

---

164-172: Thumbnail-related changes are well-integrated.

The new generateThumbnails() method and THUMBNAIL_GENERATION constant are seamlessly integrated into the SharedPreferencesHandler class. They follow the existing patterns and conventions, maintaining consistency with the rest of the codebase.

To further improve the implementation, consider adding a method to set the thumbnail generation option:

fun setThumbnailGeneration(option: ThumbnailsOption) {
    defaultSharedPreferences.setValue(THUMBNAIL_GENERATION, option.name)
}

This would provide a convenient way to update the thumbnail generation setting and ensure type safety when setting the value.

Also applies to: 331-331

presentation/src/main/java/org/cryptomator/presentation/ui/fragment/SettingsFragment.kt (2)

341-341: Consider using a resource string for the thumbnail generation preference key

The addition of the THUMBNAIL_GENERATION constant is good for managing the thumbnail generation preference. However, to improve consistency and maintainability, consider using a resource string for the preference key instead of a hardcoded string.

Here's a suggested improvement:

1. Add a new string resource in your strings.xml file:

<string name="pref_key_thumbnail_generation" translatable="false">thumbnailGeneration</string>

2. Update the constant in the SettingsFragment:

private const val THUMBNAIL_GENERATION = R.string.pref_key_thumbnail_generation

3. Update the usage in useLruChangedListener:

findPreference<ListPreference>(getString(THUMBNAIL_GENERATION))?.let { preference ->
    // ... existing code ...
}

This approach ensures consistency across the app and makes it easier to update the key if needed in the future.

---

Line range hint 1-341: Summary of SettingsFragment changes

The changes to the SettingsFragment implement the thumbnail generation preference as described in the PR objectives. The new functionality is logically tied to the LRU cache setting, which is appropriate. However, there are several areas where the implementation can be improved:

1. The setupThumbnailGeneration method is still missing and should be implemented to properly initialize the thumbnail generation preference.
2. The handling of the LRU cache and thumbnail generation settings in useLruChangedListener can be refactored for better organization and error handling.
3. Consider using a resource string for the THUMBNAIL_GENERATION constant to improve maintainability and consistency.

These improvements will enhance the overall quality and robustness of the implementation. Please address these points in your next iteration.

To further improve the code:

1. Consider extracting the thumbnail generation logic into a separate class or helper methods to keep the SettingsFragment focused on UI-related tasks.
2. Implement proper error handling for cases where preferences might not be found.
3. Ensure that the state of the thumbnail generation preference is properly persisted and restored across app restarts.
4. Add unit tests for the new functionality to ensure its correctness and prevent regressions.

data/src/main/java/org/cryptomator/data/cloud/crypto/CryptoImplVaultFormat7.kt (1)

452-460: Good addition of cache cleanup during file deletion.

The new code ensures that the cache is updated when a file is deleted, maintaining consistency between the cache and the file system. This is a valuable improvement to prevent stale cache entries.

Consider adding error handling for potential exceptions during cache operations to improve robustness.

Consider wrapping the cache operations in a try-catch block to handle potential exceptions:

 val cacheKey = generateCacheKey(node)
 node.cloudFile.cloud?.type()?.let { cloudType ->
   getLruCacheFor(cloudType)?.let { diskCache ->
-    if (diskCache[cacheKey] != null) {
-      diskCache.delete(cacheKey)
+    try {
+      if (diskCache[cacheKey] != null) {
+        diskCache.delete(cacheKey)
+      }
+    } catch (e: Exception) {
+      Timber.tag("CryptoFs").e(e, "Failed to delete cache entry for %s", cacheKey)
     }
   }
 }

presentation/src/main/java/org/cryptomator/presentation/ui/fragment/BrowseFilesFragment.kt (1)

89-89: Remove unnecessary @Override annotations in Kotlin

The @Override annotation is not used in Kotlin when overriding methods; instead, the override keyword is sufficient. You can remove these annotations to clean up the code.

Apply this diff:

 private val onFastScrollStateChangeListener = object : OnFastScrollStateChangeListener {
-    @Override
     override fun onFastScrollStop() {
         thumbnailsForVisibleNodes()
     }

-    @Override
     override fun onFastScrollStart() {
     }
 }

 private val onScrollListener = object : RecyclerView.OnScrollListener() {
-    @Override
     override fun onScrollStateChanged(recyclerView: RecyclerView, newState: Int) {
         super.onScrollStateChanged(recyclerView, newState)
         if (newState == SCROLL_STATE_IDLE) {

Also applies to: 94-94, 100-100

Configuration used: CodeRabbit UI
Review profile: CHILL

presentation/src/main/java/org/cryptomator/presentation/ui/fragment/BrowseFilesFragment.kt (1)

89-98: Remove empty onFastScrollStart method

The onFastScrollStart method is empty and can be safely removed. This will simplify the code without affecting functionality.

Apply this diff to remove the empty method:

 private val onFastScrollStateChangeListener = object : OnFastScrollStateChangeListener {
     @Override
     override fun onFastScrollStop() {
         thumbnailsForVisibleNodes()
     }

-    @Override
-    override fun onFastScrollStart() {
-    }
 }

🧰 Tools

🪛 detekt

[warning] 96-97: This empty block of code can be removed.

(detekt.empty-blocks.EmptyFunctionBlock)

data/src/main/java/org/cryptomator/data/cloud/crypto/CryptoImplDecorator.kt (2)

Line range hint 387-440: Improve error handling in thumbnail generation process.

The modifications to the read method for incorporating thumbnail generation are generally good. However, there's a potential issue with error handling:

1. If an exception occurs during the file reading process, the thumbnailWriter and thumbnailReader might not be properly closed.
2. The futureThumbnail.get() call could potentially block indefinitely if there's an issue with the thumbnail generation thread.

Consider wrapping the thumbnail-related operations in a try-catch block and ensure proper resource cleanup in case of exceptions. Also, consider adding a timeout to the futureThumbnail.get() call to prevent potential deadlocks.

Here's a suggested improvement:

 try {
     // ... existing code ...
 } catch (e: IOException) {
+    closeQuietly(thumbnailWriter)
+    closeQuietly(thumbnailReader)
     throw FatalBackendException(e)
 } finally {
     if (genThumbnail) {
-        futureThumbnail.get()
+        try {
+            futureThumbnail.get(30, TimeUnit.SECONDS)
+        } catch (e: Exception) {
+            Timber.e(e, "Error generating thumbnail")
+        }
     }
 }

---

Line range hint 1-683: Summary: Good implementation with room for improvement in error handling and resource management.

The changes to CryptoImplDecorator.kt successfully implement thumbnail generation and caching functionality. The code is generally well-structured and efficient. However, there are several areas where improvements can be made:

1. Error handling: Enhance exception handling in the read method and startThumbnailGeneratorThread to provide more specific error messages and ensure proper resource cleanup.
2. Resource management: Ensure that all resources (especially InputStreams and temporary files) are properly closed or deleted, even in error scenarios.
3. Consistency: Use explicit locales in string formatting to ensure consistent behavior across different devices.
4. Logging: Improve logging to aid in debugging and monitoring, particularly for the closeQuietly method.

Addressing these points will enhance the robustness and maintainability of the code. Overall, the implementation is a solid foundation for the new thumbnail functionality.

🧰 Tools

🪛 detekt

[warning] 449-449: The caught exception is swallowed. The original exception could be lost.

(detekt.exceptions.SwallowedException)

---

[warning] 482-482: String.format("%s-%d", cryptoFile.cloudFile.cloud?.id() ?: "common", cryptoFile.path.hashCode()) uses implicitly default locale for string formatting.

(detekt.potential-bugs.ImplicitDefaultLocale)

presentation/src/main/java/org/cryptomator/presentation/presenter/BrowseFilesPresenter.kt (2)

164-178: New method thumbnailsForVisibleNodes: Looks good with a minor suggestion.

The method correctly implements the logic for identifying visible nodes that need thumbnails and initiates the thumbnail generation process. It appropriately checks user preferences before proceeding.

Consider using filter instead of forEach for a more functional approach:

val toDownload = visibleCloudNodes.filter { node ->
    node is CloudFileModel && isImageMediaType(node.name) && node.thumbnail == null
}

This would make the code more concise and potentially more efficient.

---

290-312: New method associateThumbnails: Good implementation with a suggestion for optimization.

The method correctly implements the logic for associating thumbnails with cloud nodes, including proper checks for user preferences. However, there's a potential performance optimization in the thumbnail generation part:

images.take(10).filter { img -> img.thumbnail == null }.let { firstImagesWithoutThumbnails ->
    if (firstImagesWithoutThumbnails.isNotEmpty()) {
        thumbnailsForVisibleNodes(firstImagesWithoutThumbnails)
    }
}

This code first takes 10 images and then filters them. It would be more efficient to filter first and then take up to 10 images:

images.filter { img -> img.thumbnail == null }.take(10).let { firstImagesWithoutThumbnails ->
    if (firstImagesWithoutThumbnails.isNotEmpty()) {
        thumbnailsForVisibleNodes(firstImagesWithoutThumbnails)
    }
}

This ensures that we're only processing up to 10 images that actually need thumbnails, potentially reducing unnecessary work.

Configuration used: CodeRabbit UI
Review profile: CHILL