Add file picker to move (or optionally, copy) a ZIM file into / out of the in-app ZIM directory in `/Android/media/org.kiwix.kiwixmobile`

[Jaifroid]

Depends on #3939. If that issue is completed, then I believe it opens up the possibility of a smooth workaround to Play Store restrictions on picking archives. Since we now know that app-scoped storage that is located in the Android/media directory (designed for file sharing) is accessible to on-phone apps, it should be possible to use a standard Android File Picker to move or copy a ZIM archive elsewhere on the phone into the media-based directory, and vice-versa (using a Save File picker).

The most important one would be moving/copying a file into the library, because users could always use the native File Explorer to move it out, though it would be good UX to offer both options.

This would allow users to download large ZIM archives outside the app, e.g. in a browser or torrenting app, or importing from PC to Android, and smoothly use the files in the app. The file picker would move the selected archive and refresh the library in order to display it to the user. It would be important for the file picker to have the capability of moving a file, if possible, rather than simply copying it, because in the case of, say, full English Wikipedia, the user could run into serious space limitations if the file were copied. It would need to be investigated whether Android file operations allow moving a picked file without copying (as opposed to copying then deleting the original).

[kelson42]

@Jaifroid Thank you for your proposal, we will assess once a few other issues are fully implemented.

[kelson42]

@Jaifroid If I get it right, we would have again a fikepicker, but (in case od PS version) instead of opening directly yhe ZIM file, it would first move it to the app public directory (either internal or external) depending of the configuration? @MohitMaliDeveloper Would that be feasible?

[Jaifroid]

Yes, it's a kind of workaround, but it seems like quite a smooth one. The idea is to have a standard file picker that allows the user to add an archive located in any user-accessible directory (e.g. Downloads, or any arbitrary location) and move it into the app's ZIM library. The key here is that the ZIM library would need to be located in the Android/media directory rather than in its current location (a private app-scoped storage). But we've already seen that that is a very small change, and has already been done as a test.

[MohitMaliFtechiz]

@Jaifroid If I get it right, we would have again a fikepicker, but (in case od PS version) instead of opening directly yhe ZIM file, it would first move it to the app public directory (either internal or external) depending of the configuration? @MohitMaliDeveloper Would that be feasible?

@kelson42 Yes this is feasible. We can move the files from any location to our public directory when selecting any file via filePicker we have a document file and we can move the document to any location https://developer.android.com/reference/android/provider/DocumentsContract#moveDocument(android.content.ContentResolver,%20android.net.Uri,%20android.net.Uri,%20android.net.Uri).

[Jaifroid]

@kelson42 Yes this is feasible. We can move the files from any location to our public directory when selecting any file via filePicker we have a document file and we can move the document to any location

@MohitMaliFtechiz And can we do the reverse -- i.e. can a user pick a file using the file picker from the app's public directory and move it out? This is less crucial of course, because a user could always use a File Manager to do that if they wished.

[MohitMaliFtechiz]

@Jaifroid Yes, it is possible to do it. But Currently, the moved file(outside the public app-specific folder) can not be read by the application until we implement https://github.com/openzim/libzim/issues/852. But moving the file is possible.

[kelson42]

@Jaifroid If I get it right, we would have again a fikepicker, but (in case od PS version) instead of opening directly yhe ZIM file, it would first move it to the app public directory (either internal or external) depending of the configuration? @MohitMaliDeveloper Would that be feasible?

@kelson42 Yes this is feasible. We can move the files from any location to our public directory when selecting any file via filePicker we have a document file and we can move the document to any location https://developer.android.com/reference/android/provider/DocumentsContract#moveDocument(android.content.ContentResolver,%20android.net.Uri,%20android.net.Uri,%20android.net.Uri).

So the worflow should be the following:

• Reintroduce the filepicker for nonPS version to pick (for ead) any ZIM file
• The filepicker continues to work like today for non PS version
• For the PS version, we should move the ZIM file to the chosen public storage first. Before that we need to ask the user to agree to that first.
• Last part is the same.

[Jaifroid]

@Jaifroid Yes, it is possible to do it. But Currently, the moved file(outside the public app-specific folder) can not be read by the application until we implement openzim/libzim#852. But moving the file is possible.

OK, well that's not urgent at all. I'd focus on the first case, i.e. being able to move a picked file into the public ZIM library in shared Media.

[Jaifroid]

@kelson42 It seems to me it could be the "same" picker, but would be coded a bit differently for the non-PS app and the PS app (in the latter case, there is the intermediate stage of moving the file into the library). But the way you describe it sounds correct to me. A one-time permission should be sufficient (rather than asking each time).

[kelson42]

@MohitMaliFtechiz The touchy part is the moving part, because if we are "unlucky" the file has to move from one storage (internal for example) to an other (external for example). This implies:

• Testing if this is possible at all: enough size, filesystem supported, etc...
• we need to make the user wait during the copy of the file. With a spinner, with a progress bar?
• What happen of for some reason something goes wromg during the move/copy?

[MohitMaliFtechiz]

So the worflow should be the following:

• Reintroduce the filepicker for nonPS version to pick (for ead) any ZIM file
• The filepicker continues to work like today for non PS version
• For the PS version, we should move the ZIM file to the chosen public storage first. Before that we need to ask the user to agree to that first.
• Last part is the same.

@kelson42 For this we will show a dialog at first click on the file picker that it will move the files to the public directory(It is the case to inform the user about the functionality in PS version).

@MohitMaliFtechiz The touchy part is the moving part, because if we are "unlucky" the file has to move from one storage (internal for example) to an other (external for example). This implies:

This should be based on the configuration. e.g. if the user selects the "internal storage" from the setting, and he tries to move the file from "sd card" so the file should be move/copy in the internal storage's public directory?

Testing if this is possible at all: enough size, filesystem supported, etc...

Yes, this should be properly tested and we will add the test cases for this scenario.

we need to make the user wait during the copy of the file. With a spinner, with a progress bar?

We have very big files so the spinner is not good enough because the user would not know how much time is left to copy/move. We should show a progress bar here so that users can easily track the progress of the move/copy.

What happen of for some reason something goes wromg during the move/copy?

In this case, we will show the proper error to the user so that they can try to move/copy again(as most of the file managers show when there is some error in copying/moving the files).

[kelson42]

So the worflow should be the following:

• Reintroduce the filepicker for nonPS version to pick (for ead) any ZIM file

• The filepicker continues to work like today for non PS version

• For the PS version, we should move the ZIM file to the chosen public storage first. Before that we need to ask the user to agree to that first.

• Last part is the same.

@kelson42 For this we will show a dialog at first click on the file picker that it will move the files to the public directory(It is the case to inform the user about the functionality in PS version).

Yes, but after the user has chosen a file to open.

@MohitMaliFtechiz The touchy part is the moving part, because if we are "unlucky" the file has to move from one storage (internal for example) to an other (external for example). This implies:

This should be based on the configuration. e.g. if the user selects the "internal storage" from the setting, and he tries to move the file from "sd card" so the file should be move/copy in the internal storage's public directory?

Yes, and this operation can be very long and as such user needs to be kept informed and we need to foreseen an interruption. You will need to implement a robust move/copy solution (with visual feedabck).

Testing if this is possible at all: enough size, filesystem supported, etc...

Yes, this should be properly tested and we will add the test cases for this scenario.

we need to make the user wait during the copy of the file. With a spinner, with a progress bar?

Progressbar seems better.

We have very big files so the spinner is not good enough because the user would not know how much time is left to copy/move. We should show a progress bar here so that users can easily track the progress of the move/copy.

What happen of for some reason something goes wromg during the move/copy?

In this case, we will show the proper error to the user so that they can try to move/copy again(as most of the file managers show when there is some error in copying/moving the files).

yes, and target temporary file should be removed.