Reading custom files on storage card for android sdk 30

Question

I have an app that creates custom files that are shown in a gallery. They are not images or other standard media files. Because the files are large, I ask users for access to a folder in which the files will be stored.

So far so good.

Reading those files or file info via DocumentFile is so much slower than via File. Operations like

DocumentsContract.findDocumentPath()
documentFile.isFile()
documentFile.getName()

take up to 15ms each, which accumulates to a large time when reading a large number of files.

What's the best way to handle this? Is there another way to do this? I don't want the files to be in internal app memory or users might lose their work when they uninstall the app.

Thanks in advance! This is stressing me out a lot.

Gabe Sechan · Answer 1 · 2021-10-06T21:28:22.220

0

Do it asynchronously. Do you need to get all of that data immediately? Probably not. So do it on a thread/in a coroutine, and just program your app to not display the data if you do not yet have it (and refresh itself when you do).

In addition, even if you do need it up front- do you need it for all files up front? In a gallery, you can make do with just the ones that are immediately displayed, and the next few which might be. So only fetch that, and get the others when you need them (or when its likely you'll need them soon). Treat it like fetching results from a web API- you don't fetch every post ever made, you fetch a few dozen, then you fetch a few dozen more when they're getting close to the bottom

edited Oct 06 '21 at 21:28

answered Oct 06 '21 at 21:23

Gabe Sechan

90,003
9
87
127

Thanks for your comment. I do read the data asynchronously but it still looks bad when it isnt available for a long time – erinys Oct 06 '21 at 21:28
i just saw your edit. i use an array adapter to display the gallery. it reads the large part of the data only when visible, like you suggested. but even just reading basic info to create the list for the adapter takes time. – erinys Oct 06 '21 at 21:30

score 0 · Answer 2 · answered Oct 06 '21 at 21:46

In the end, DocumentFile is a wrapper around other APIs, a wrapper that is designed to provide a convenient, File-ish API for developers to use. It is not designed for bulk use. If you want to try to get more speed, you can look at the source code to DocumentFile and related classes used in its implementation, such as DocumentContract19, and work at a lower level.

For example, getName() winds up using this queryForString() method to do the real work. Making a query using ContentResolver adds IPC overhead, so if there are other values that you need that you can get in that same query, you could do the query yourself. For example, isFile() also winds up doing a query, so you could combine those two requests into one and cut the overall time in half (roughly).

score 0 · Answer 3 · answered Oct 06 '21 at 22:01

0

Do not use DocumentFile class.

Only use DocumentsContract functions.

Its about twenty times as fast as DocumentFile and nearly as fast as classic file operations

answered Oct 06 '21 at 22:01

blackapps

8,011
2
11
25

thanks for your comment. i have found DocumentsContract also to be slowish for example DocumentsContract.findDocumentPath in order to read a subfolder. maybe it's just this function that is slow? – erinys Oct 06 '21 at 22:08
I have never seen and hence never used that function. Dont know. – blackapps Oct 06 '21 at 22:10
fair enough :) are you maybe aware of another function that can read subfolders (path components) from a uri? – erinys Oct 06 '21 at 22:27
As i said: you can do all with DocumentsContract. Like listing, creating, deleting and such. – blackapps Oct 07 '21 at 05:43
i use DocumentsContract.findDocumentPath. that is quite slow. – erinys Oct 08 '21 at 00:27
Then do not use it. – blackapps Oct 08 '21 at 06:32

Reading custom files on storage card for android sdk 30

3 Answers3