Speed up the search process for available file names in findUniqueFilename

If the user-chosen file name is occupied by an existing file, the app sequentially tries to find an available file name by trying suffixes _1, _2, etc. When there are hundreds of these numbered files, it will be unbearably slow. It already does for Test.jpg on the Beta Commons. I believe the same thing happens when the user uploads a lot of files under the same name.

Proposed solution:

Change the file name pattern from <user-given title>_<number>.jpg to <user-given title>_<short hash>.jpg when the user-chosen file name is unavailable. It should extend to a longer hash when collisions repeat. When that’s not enough (let’s say 3 consecutive collisions on random generation), we could add another 4, and repeat.

Steps to reproduce:

Build betaDebug and try uploading a file under the name Test. It will take a longer time (> 1 min in my WiFi environment) than it should.

Commons app version:

latest master

(Note: the task description has been rewritten based on feedback below.)

[madhurgupta10]

@whym I can still work on the issue 😃

[maskaravivek]

I like the second approach but would like to suggest some modification in the upload flow.

Background context about current flow:

If the user chooses a title that already exists, we show a warning dialog informing the user that the title already exists and asking whether he wants to proceed or not.

If the user clicks on No > he stays on the same page and he can manually edit the title.

If the user clicks on Yes > he proceeds further and once the upload is queued, he would discover the actual title that was assigned to his upload.

It might surprise the user to see 1, 2, 3 etc (or based on the new discussion some hash) appended to the title. Will it be more fruitful to show the final title to the user(ie. on the upload screen itself) before he proceeds further. Seeing an unaesthetic title might encourage the user to actually update the title to something more meaningful.