Loading time of stickers

[suraj3486]

It takes very long time to load a folder containing sub folders

[rzhou1999]

Can I have some more info about the size of your sticker directory and how long it takes? What woosticker does on import is create a local copy of the data in it's internal folder (this gets rid of annoying permissions issues as well as the effects of unintended changes to the sticker state). Unfortunately this means that the speed of how fast stickers are imported is directly related to how fast your phone can copy files. Maybe this can be sped up by using more threads to do the copy (assuming the storage isn't the bottleneck)-- I'll see what I can do once I have some more time.

[rzhou1999]

Also, what android version are you on? Android 11 apparently screwed up some filesystem things.... https://old.reddit.com/r/androiddev/comments/kpn68k/android_11_very_slow_file_access_performance/

[suraj3486]

I m on custom rom of A11. As it makes its own data folder which means it is eating extra storage. I have around 1G.B stickers which means i have to give 1G.B more as i have to use this app? Please make it use only original stickers like uSticker which were not making any copy in data folder

[rzhou1999]

Willing to look into this but I'd also like some feedback on what edge cases should look like. Especially in terms of moving/deleting files, see the below link for an example of why using external storage can complicate things:

https://stackoverflow.com/questions/65333896/android-10-requesting-permissions-and-persistent-permission-on-a-content-uri

Additionally, using external storage would mean that I would have to use DocumentFile exclusively (which is apparently much slower than File). Right now what I think is happening is that there is a large 1 time cost to copy from external storage (using DocumentFile) but that gets amortized across subsequent uses of woosticker (which uses the faster File class) Changing the design would make it so there isn't a 1-time cost anymore, but regular usage may suggest (since the stickers need to be accessed using DocumentFile).

So ultimately I'd like to figure out a few things before I try sometime out (which also might take a while because this is a side project and I have other stuff going on right now):

1. How does UX work? Should the user still manually import stickers?
2. How does file deletion work? If a user deletes an image in an external directory, how does woosticker explain to the user that the sticker no longer exists?
3. Similarly, if a sticker gets moved from one folder to another, should it also get moved to a different "pack"? Or should it stay in it's original pack until it gets re-imported.
4. This means that woosticker would need persistent permissions to every file associated with the selected directory, as opposed to a one-time access to copy those files. Are people okay with allowing for basically permanent file access by woosticker?

[suraj3486]

Just put a warning that ( if u ever update these sticker folders than refesh it through app first than use it ) that is how earlier uSticker were working

[rzhou1999]

That doesn't fully address my concerns above-- notably, is a warning enough to explain to the user that a file they moved out of the stickers directory still exists in the stickerpack? Do people really want to give permanent file access to a tiny sticker keyboard? And, perhaps most importantly, would this even help performance issues given that everything would need to move to the pitifully slow SAF?

[suraj3486]

Than how about a refresh button in keyboard top bar. Which will recheck all its files from sources and gets modified on the spot

[maddes]

Willing to look into this but I'd also like some feedback on what edge cases should look like. Especially in terms of moving/deleting files, see the below link for an example of why using external storage can complicate things:

https://stackoverflow.com/questions/65333896/android-10-requesting-permissions-and-persistent-permission-on-a-content-uri

Additionally, using external storage would mean that I would have to use DocumentFile exclusively (which is apparently much slower than File). Right now what I think is happening is that there is a large 1 time cost to copy from external storage (using DocumentFile) but that gets amortized across subsequent uses of woosticker (which uses the faster File class) Changing the design would make it so there isn't a 1-time cost anymore, but regular usage may suggest (since the stickers need to be accessed using DocumentFile).

So ultimately I'd like to figure out a few things before I try sometime out (which also might take a while because this is a side project and I have other stuff going on right now):

1. How does UX work? Should the user still manually import stickers?
2. How does file deletion work? If a user deletes an image in an external directory, how does woosticker explain to the user that the sticker no longer exists?
3. Similarly, if a sticker gets moved from one folder to another, should it also get moved to a different "pack"? Or should it stay in it's original pack until it gets re-imported.
4. This means that woosticker would need persistent permissions to every file associated with the selected directory, as opposed to a one-time access to copy those files. Are people okay with allowing for basically permanent file access by woosticker?

I believe this should be addressed by:

1. Keep copying files.
2. Add even more cost to the 1-time operation by processing the files and reduce them to max 512x512, this should eliminate unnecessary img size (think people could just download high-res images from the internet and dump them on the external folder).
3. Add a "refresh" button on the icon folders bar (beginning or end, whichever), and provide some feedback on progress.