fix: refresh the Files tab after extracting an archive#459
Closed
MiMoHo wants to merge 1 commit into
Closed
Conversation
When a ZIP is opened from the Files tab, its contents are shown in DecompressActivity, which is launched via an implicit ACTION_VIEW intent rather than startActivityForResult. On successful extraction the activity only toasted and finished, so MainActivity had no way to learn that new content was written and its onResume never re-read the current directory. The extracted folder therefore only appeared after a manual swipe-to-refresh. DecompressActivity now records the extracted folder path in a plain-String companion field (no Activity reference, so no leak) and MainActivity consumes it on resume, navigating the Files tab into the freshly extracted folder. Both the write and read happen on the main thread, so no synchronization is needed. Closes FossifyOrg#194
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Type of change(s)
What changed and why
When a ZIP is opened from the Files tab, its contents are shown in
DecompressActivity, which is launched via an implicitACTION_VIEWintent (registered forapplication/zipin the manifest) rather thanstartActivityForResult. On successful extraction the activity only calledtoast(R.string.decompression_successful)andfinish(), soMainActivityhad no way to learn that new content had been written.MainActivity.onResume()never re-reads the current directory andItemsFragment.onResume()only updates colors/fastscroller/breadcrumb, so the extracted folder only appeared after a manual swipe-to-refresh.DecompressActivitynow records the extracted folder path in a plain-Stringcompanion field (extractedFolderPath) on successful extraction. Unlike closed PR #273'scompanion object var onDecompressFinished: ((String) -> Unit)?, this holds noActivity/lambda reference, so it cannot leakMainActivity.MainActivity.onResume()consumes and clears the field, callingopenPath(path, forceRefresh = true)to navigate the Files tab into the freshly extracted folder. Both the write and the read happen on the main thread (runOnUiThread/onResume), so no@Volatile/synchronization is required.Note: the other decompress entry point (long-press a ZIP -> CAB decompress icon ->
ItemsAdapter.decompressSelection) already refreshes vialistener?.refreshFragment()and is unaffected by this change.Tests performed
detekt,lint, unit tests and the build all pass locally (CI-equivalent).DecompressActivityrecords the extracted folder path andMainActivityopens/refreshes that path on return, so the Files tab updates without a manual pull-to-refresh.Closes the following issue(s)
Checklist
CHANGELOG.md(if applicable).Coded with Opus 4.8 ultracode.