Java Development

[DIegoR]

Thanks, Jinchang! Now the code runs fast enought. I have marked your post as accepted answer. Thanks to all contributors to this thread too as your comments helped me to put the code in a comprehensible state.

The corrected code can be found on my public CVS

[agrant_ga]

Just my late 2c in case you want to poke it a few more times (I've not actually profiled any of these for your code, they're just guesses): 

1) Arrays.add() I think is now hidden or deprecated.  The best option would be to use a Vector instance instead of the array "contacts1dimArray", presized to a reasonable length (based on sample data), then before the Arrays.sort(), create a new array of known vector.size() then use vector.copyInto( newarray ).

2) Perhaps better yet, use RIM's SimpleSortingVector, try setting .setSort(false) before the populating loop then call .resort() after it's populated. 

3) If profiling says the array.add is still fast (even though it is hidden), perhaps take a look at RIM's 

net.rim.device.api.util.StringComparator instead of writing your own StringComparator - and probably cache the comparator as a class-level final static anyway since it should be relatively small for its memory footprint. 

4) Minor - Avoid doing name instanceof String when you add name to the array (or vector as I mention above) since you know it's a string and just check for null directly, eg ( name == null ) ? nullcodestuff : nonnullcodestuff.  If name was an object and you're about to cast it to a String, then instanceof is great. 

[DIegoR]

Thanks for your input agrant_ga!

Even though my app screen is now coming up faster than the e-mail itself, there are a few thing from your list that are still worth changing.

- use net.rim.device.api.util.Straightforward - standard realization and also locale-aware.

- name instanceof String vs. name == null, I just misunderstood the recommendation from the optimization post, so instanceof is probably totally unnecessary here indeed.

Arrays.sort - I have looked it up and did not find it deprecated even in 6.0.0 API

http://www.blackberry.com/developers/docs/6.0.0api/net/rim/device/api/util/Arrays.html

[agrant_ga]

Right on the Arrays.sort( obj, cmp ), but I mean take a look at replacing Arrays.add( arr, obj ).

Arrays.add() was hidden in the api around 4.2, not sure why.

The main reason I'd suggest a Vector or SimpleSortingVector instance is to remove the unnecessary garbage collection of temporary arrays.  

If the array contacts1dimArray is mutated more than a few times via Arrays.add(), there are probably excess objects being created.  The javadoc (for older versions of the api where Arrays.add is still in the javadoc) implies a new array of size x+1 is created, old contents copied, and the old array is discarded - so if there are a bunch of addresses and/or names, there are a lot of temporary arrays being created then discarded ... 

On the other hand, a vector type creates a backing array (default size 7 or whatever you presize it to) then only create a new backing array it once that original size is exceeded (the new backing array size is doubled).  So Vector or SimpleSortingVector should (!) result in significantly fewer temporary objects being created, especially if the item count is large. 

At least that's my theory, I personally avoid using stuff not exposed in the javadocs for the api level I'm targetting ... 

Regardless, hope this helps!