Case insensitive ordering

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open Album or Artist list
2. XBMC Remote will first show capital letters
3. XBMC Remote will then list lowercase letters

What is the expected output? What do you see instead?
XBMC Remote should list the elements case insensitive. 'a' and 'A' should
be equal instead of 'a' coming after 'Z'.

What version of the product are you using? On what operating system?
0.5.2 on Android 1.5

Please provide any additional information below.
XBMC pre-9.10r23658

Original issue reported on code.google.com by codename...@gmail.com on 12 Oct 2009 at 10:33

[GoogleCodeExporter]

Will look into that hope ORDER BY lower(name) is not too expensive on XBMC's 
side.

Original comment by phree...@gmail.com on 13 Oct 2009 at 11:00

• Changed state: Accepted

[GoogleCodeExporter]

In stead of having XBMC do the ordering (I'm thinking slow Xboxes here) you 
could skip 
the "ORDER BY..." in the sql, and refactor e.g. Album to implement 
"Comparable<Album>" 
with something like:
int compareTo(Album a){
 return this.name.compareToIgnoreCase(a.name);
}
and then let Android do the sorting by calling "Collections.sort" on the raw 
list 
returned from the http sql query.
Sample code attached (SortTest.java).

Just a thought, really - I have no idea what impact it would have on the 
application's 
performance on an android phone...

:O) Mikkle

Original comment by mukkenb...@gmail.com on 20 Oct 2009 at 9:58

Attachments:

• SortTest.java

[GoogleCodeExporter]

Well, IMHO the Android device will always be the slowest node. Letting Java do 
the
sorting compared to some probably pretty well optimized SQLite algorithm 
doesn't seem
a smart thing to do. 

Maybe using an Xbox it could speed up, but I honestly doubt it. Of course we'd 
have
to benchmark but that's my assumption. 

Original comment by phree...@gmail.com on 22 Oct 2009 at 11:30

[GoogleCodeExporter]

Original comment by till.ess...@googlemail.com on 23 Oct 2009 at 2:54

[GoogleCodeExporter]

The good thing about sorting it in Java is that you can do other sortings 
easily on
the client side without having to request a refresh each time you want to 
change the
sorting order. The network traffic that is required for that would always be 
slower
than sorting a list in memory.

So my suggestion: change the code as the OP suggested but don't remove the 
"order by"
in the sql statement and have the default sorting in the "order by". The server 
side
sorting will be a lot faster indeed since Java sorts objects by calling a 
function on
each object and uses a quicksort algorithm to sort the return values. Worst 
case is
O(n^2). I haven't looked at how sqlite does the sorting but I'm pretty sure 
it's not
quicksort ^^

Original comment by opdenk...@gmail.com on 28 Oct 2009 at 10:38

[GoogleCodeExporter]

Haven't looked into it, but sorting through Java is pretty pointless if the case
insensitive ordering is meant to be the default. So why get a unsorted or 
semisorted
list and then sort it in Java when you can receive a fully sorted list from the
sqlite database?
Even though when thinking about asynchronously filling the album list (got some
OutOfMemoryExceptions) you can't sort it without having the complete list.

Even when talking about runtime it is log2(n) for quicksort, not n^2 ;)
Plus if the name is indexed in sqlite the search will always be quicker.

Original comment by till.ess...@googlemail.com on 28 Oct 2009 at 10:55