fix(activity): persist source-type + save-to flags across process death#255
Open
NadeemIqbal wants to merge 1 commit into
Open
fix(activity): persist source-type + save-to flags across process death#255NadeemIqbal wants to merge 1 commit into
NadeemIqbal wants to merge 1 commit into
Conversation
PdfViewerActivity routes between URL-download and local-file rendering based on isPDFFromPath, a var in the companion object. The same pattern gates SAVE_TO_DOWNLOADS for the download menu. Both are set as side effects of launchPdfFromUrl / launchPdfFromPath and were never written to the intent, so when Android killed the process and restored the activity, the statics reset to their declared defaults (false / true) while the intent's FILE_URL extra still held the original path. Result: a local file path (set via launchPdfFromPath) was treated as a URL on restore and rejected by PdfDownloader with "Invalid URL Scheme: <path>. Expected HTTP or HTTPS." SAVE_TO_DOWNLOADS had the same bug silently — the download destination flipped after restore. Fix: - Persist both flags as new intent extras (IS_FROM_PATH, SAVE_TO_DOWNLOADS_KEY) in launchPdfFromUrl / launchPdfFromPath - Re-derive both statics from the intent in extractIntentExtras() so state restoration restores correct routing - Existing static writes kept for back-compat with any caller that reads the companion fields directly No public API change. Callers that don't go through the launchPdfFromX helpers (custom Intent) fall back to the static's current value, so behaviour is unchanged for them. Closes afreakyelf#219.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Thank you for contributing to this project. This is your first pull request and we are so glad to have you onboard. We will review the request and get back to you soon. We love your contributions! Join our Discord community here to discuss this PR or ask questions.
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
1 participant
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.
PdfViewerActivity routes between URL-download and local-file rendering based on isPDFFromPath, a var in the companion object. The same pattern gates SAVE_TO_DOWNLOADS for the download menu. Both are set as side effects of launchPdfFromUrl / launchPdfFromPath and were never written to the intent, so when Android killed the process and restored the activity, the statics reset to their declared defaults (false / true) while the intent's FILE_URL extra still held the original path.
Result: a local file path (set via launchPdfFromPath) was treated as a URL on restore and rejected by PdfDownloader with "Invalid URL Scheme: . Expected HTTP or HTTPS." SAVE_TO_DOWNLOADS had the same bug silently — the download destination flipped after restore.
Fix:
No public API change. Callers that don't go through the launchPdfFromX helpers (custom Intent) fall back to the static's current value, so behaviour is unchanged for them.
Closes #219.