You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@dstillman
I’ve made collections sort correctly for most cases, except for the cases where the collection name contains numbers. Those collections are also sorted, but differently than on iOS.
Look at this side by side comparison:
iOS_1:
Android_1:
iOS_2:
Android_2:
On iOS this sorting logic is used:
return lCollection.name.compare(rCollection.name, options: [.numeric], locale: Locale.autoupdatingCurrent) == .orderedAscending
Basically iOS is using a built-in sdk function for this. Specifically this “.numeric” sort option, which treats numbers in a string in a special way.
We do not have something similar to this on Android, as a result numbers are getting treated the same way as other characters, hence the difference in the sorting result.
We would have to develop a custom sorting logic. All of the advice I can find on stackoverflow basically says that we will need to detect numbers in a string and treat them “as numbers” during sorting and not just as string characters.
But to do this we will either need to know the exact positionings of those numbers in string, so we could find them and convert them from chars to numbers.
Or patterns those numbers may follow in a string so we could use a regexp.
But the problem is that numbers in the collection name can appear in completely random positions. We could use some guesswork and maybe replace those numbers with special characters before sorting, and then play with it until we get the result similar to iOS, but this will take extra time.
Unless we can quickly figure out how iOS does it under the hood I suggest we keep current sorting and address it after release.
No description provided.
The text was updated successfully, but these errors were encountered: