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 openzim/libzim#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.

[kelson42]

Tested and does not work for me.

I have downloaded a ZIM file via Firefox and the tried to pick it up, but I get

I expect that:

• To propose me to relocate the file
• A preciser error message. What is exactly happening here? It can not be read? It can not be open? An other kind of error?

[MohitMaliFtechiz]

@kelson42 Is this issue same as you described here #3997?

[kelson42]

@MohitMaliFtechiz No, here I don't click on the "+"

[MohitMaliFtechiz]

@MohitMaliFtechiz No, here I don't click on the "+"

Okay, so you directly opening the zim file from fileManager instead of opening the file picker ("+" icon)?

[kelson42]

@MohitMaliFtechiz No, here I don't click on the "+"

Okay, so you directly opening the zim file from fileManager instead of opening the file picker ("+" icon)?

No, I open via the invitation (in Firefox) to open the file (I just have downloaded) via a third party app.

[MohitMaliFtechiz]

@kelson42 Okay i got it, Thanks for confirmation.

[kelson42]

Still fails with same symptoms

[MohitMaliFtechiz]

@kelson42 Can you please try with this APK https://drive.google.com/file/d/16uwwoKWdF00rwhvAvR5musunKse4bBwD/view?usp=sharing and let us know that the problem is fixed or not for you?

[Jaifroid]

@MohitMaliFtechiz I just installed this version on my Android, and tried it with the "move" option with a Ray Charles ZIM, and it worked fine!

I think some of the messaging when the app is first installed needs to be changed. It says that the app cannot open sideloaded ZIMs, whereas it should say that the app cannot directly open them but can copy them into its storage. It might be worth saying also that the location of the storage can be changed to a microSD card if the system has one (this would be important for people wanting to import very large ZIMs), though I suppose the message has to be kept short enough that people won't just ignore it...

[Jaifroid]

Did you consider adding an export function (the reverse of this import function)? If not, perhaps the in-app usage info could simply say that to export a ZIM file, users will need to use the system File explorer (the directory is accessible, I checked).

[MohitMaliFtechiz]

@MohitMaliFtechiz I just installed this version on my Android, and tried it with the "move" option with a Ray Charles ZIM, and it worked fine!

@Jaifroid Thank you for your testing and feedback.

I think some of the messaging when the app is first installed needs to be changed. It says that the app cannot open sideloaded ZIMs, whereas it should say that the app cannot directly open them but can copy them into its storage. It might be worth saying also that the location of the storage can be changed to a microSD card if the system has one (this would be important for people wanting to import very large ZIMs), though I suppose the message has to be kept short enough that people won't just ignore it...

Thank you for your valuable suggestion. It sounds good to me and will be very helpful for users 😊.

[kelson42]

I think some of the messaging when the app is first installed needs to be changed.

Once working flowless, I believe we should just remove it... This is simply too complex and not that much useful anymore to be worth having one IMHO.

[kelson42]

@kelson42 Can you please try with this APK https://drive.google.com/file/d/16uwwoKWdF00rwhvAvR5musunKse4bBwD/view?usp=sharing and let us know that the problem is fixed or not for you?

Now Kiwix is not even listed in the list of programs I can open the zim with.

[Jaifroid]

@kelson42 My guess is that you can't open the ZIM that way, i.e. from the File System or from a notification. You have to use the provided picker within the app, because this is a specialized function that only that picker evokes. Also, first please check that the file exists in your file system at a known location (e.g. Downloads) before trying to pick it in the app. Usually this will be the default location for downloads in your specific browser.

The picker itself (in-app) works as described for me. Adding Kiwix as a share target and trying to use the shared file to copy it into the media storage would be an additional feature (and probably a lot harder to code for, maybe a separate PR). JMHO of course.

[kelson42]

@Jaifroid @MohitMaliFtechiz Indeed, sorry, I have mixed-up the scenario with #3997. But it does not work either with the +.

[MohitMaliFtechiz]

Now Kiwix is not even listed in the list of programs I can open the zim with.

@kelson42 We have not changed anything for showing the Kiwix in the suggestion list(This APK only contains this PR changes #4006). It's strange that you do not see Kiwix in the suggestion list.

Can you please provide details about your device? Most of the bugs you are facing on this tablet.

[kelson42]

@MohitMaliFtechiz Samsung Galaxy Tab S9 FE SM-X510

[Jaifroid]

@kelson42 I'm not sure I understand why it's not working for you when it's working fine for me. FYI this is what worked for me, step-by-step:

1. Uninstall all previous (or current) versions of Kiwix, including any APK installation.
2. Install the new test APK.
3. Open the app and go through the onboarding, and give it any permissions it asks for.
4. Ensure you have a ZIM archive available on your device and accessible in a pickable location. Ensure you can see it in your device's file manager (often just called "Files"). Easiest for testing might be to place the ZIM in Downloads or Media (can be in a subfolder under an accessible directory). I tested with a ZIM I had just downloaded into Downloads.
5. Go to the Library in-app, click the blue + button (if a dialogue pops up with some info, accept it), and navigate to the location of the ZIM you want to add to the app's storage. You should be able to see the ZIM and click on it.
6. Answer the dialogue box asking whether you want to COPY or MOVE the file. I chose MOVE.
7. After it has moved the ZIM into its storage, it refreshes the library for you, and you should be able to see it int the Library and open it.

[MohitMaliFtechiz]

@Jaifroid Kelson was facing the issue on the Samsung tablet which we have fixed in the #4006 for the PS version(Now it started working in the kelson's tablet). This is a real issue on the tablets for that issue I have opened an issue #4008.

[Jaifroid]

Ah, that's good to know. That's a really tricky thing! Good you managed to find the cause and fix it, because I think this feature is something of a "game changer" for users of Kiwix from the Play Store.