Allow choosing a custom directory for local backups #302
+25
−49
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.
Pull request (PR) checklist
Please check if your pull request fulfills the following requirements:
What's changed?
As discussed in #268, we'd like to make incremental improvements to the backup & export functionality, ultimately leading to the implementation of automated, scheduled backups (hopefully in the cloud as well as locally).
The first step towards this goal should be to offer the user the option to choose a custom directory when making a manual backup.
This doesn't close the above issue, it just contributes to it.
Couple of things to note:
Removal of
getDownloadPath()
Since we're now allowing the user to choose where to save the exports, both
.exportDatabaseFile()
and.exportSpreadsheet()
methods take the path as an argument and no longer need to figure it out by themselves. Therefore, I think we will no longer need thegetDownloadPath()
function and I've deleted it.This has the added benefit of removing the need to find a valid cross-platform "default" path, which is not trivial and introduces a few problems (e.g.: only the
/Downloads
directory truly works across platforms, but for some reason Android'sFilePicker()
dialogue does NOT allow the user to select it... which can be confusing).Of course let me know if you prefer to keep it.
New names
I have taken the liberty of renaming a couple of symbols in a way that I think will make more sense once we start implementing the rest of features:
downloadDatabaseFile()
->exportDatabaseFile()
downloadPath
->exportPath
Of course feel free to revert that if you disagree.
Does this PR close any GitHub issues? (do not delete)