[Question/Discussion] How to use SAF uriStrings to request a MediaStore scan?

[Shabinder]

Prior to migrating to SAF, I used to scan my mediaFile like below

MediaScannerConnection.scanFile (
                                applicationContext,
                                listOf(file.absolutePath).toTypedArray(), null, null
                            ) 

Now since the above approach only works with java.io.File Paths, and when using SAF we have content URI Strings, How to do a media scan on media files like mp3 using their URIs?

Apparently, Google Decided to not fix this issue: https://issuetracker.google.com/issues/129089149
So we devs are on our own again, f*** SAF!

[K1rakishou]

Honestly I have no idea because I have never had to work with MediaStore.

[Shabinder]

Honestly I have no idea because I have never had to work with MediaStore.

I am fed up (Your Repo' Name Literally tells the truth), just to write to external sdCard , I tried to migrate to SAF, I use File operation extensively in my App , and it has caused significant delays bcuz of such large number of operations.(Even after creating in-memory snapshots)

I am gonna revert back to java.io.File and will use dir in Internal Storage only, if user wants, he/she can copy files manually to externalSD .

I have been exploring SAF these past two days, and I can say even to achieve such simple tasks, they have been literal Hell.

Saying Final GoodByes to SAF, One cant use SAF when every minute there are 500's of File Operations going on.

Do you think SAF can be used in any way in such Apps with such extensive File Operations?

[K1rakishou]

Yeah, if you need to do lots of disk IO then SAF is very slow. Some people measured the performance and it's like 25-50 times slower than Java File API. (https://www.xda-developers.com/android-q-storage-access-framework-scoped-storage/)

To mitigate this issue (at least partially) I came up with the idea of making directory snapshots so you can then work with the in-memory directory structure which is faster and the regular SAF access. But it has it's own downsides, obviously, like any modification to the underlying files still have to use SAF (file/directory creation/deletion) which is slow. The other downside is that there may happen desynchronization between the in-memory snapshot and actual on-disk directory structure if it's somehow modified by something/someone else while (like you take a snapshot but the user decides to delete something manually).

Do you think SAF can be used in any way in such Apps with such extensive File Operations?

I actually use SAF in my own project, and there are lots of different file operations. So, yes, It's slow but it works

[Shabinder]

I just finished migrating back to jav.io.File, at least I learned about SAF and got some experience with your lib, in order to use it in my future apps.

Thanks for the help and of course for this amazing project!
👍