well the problem I found was not dealing with a boolean, but checking that
boolean in several classes and methods, which can be a problem when adding
new code if you miss to add that check again.
Also, the option of extending a map is too complicated. So I finally added
your patch to SVN but moved all checks to Repository class. In this way both
RepositoryFiller or RepositoryLoader are not aware of how artist or genre
names are stored.
Also added a call to refresh repository (and device repository) after a
preferences change. You can view method applicationStateChanged in
RepositoryHandler and DeviceHandler.
I will add also the same behavior, not only for artists and genres but also
Thanks a lot for your work.
2011/9/3 Jan-Martin Ziem <jmziem@...>
> Hey Alex
> Testing a simple boolean isn't such a big thing and it seemed to be ok to
> If you extend the generic hashmap, you need to hold the repository in both
> maps, right? That's a huge mem consumption.
> The case sensitive/insensitive feature is transparent to all the rest,
> because it's "hidden" within the repository code.
> The only "overhead" of calls by checking the case sensitive flag occurs
> while updating the repository, just to change the keys. With a profiler
> i didn't take any real notice of these additional calls against the
> original code. Ok, it's difficult to detect that with an i7.
> Maybe it's not the best solution, esp. in search workflow - i didn't
> profiled the search against the old code.
> Why do you think, that external requests has to check the sensitiveness?
> The standard process of an request to repository is handled
> by the repo itself, isn't it?
> I really enjoy the feature of case insensitive flag, but if you think it
> should be done another way, give me a tip how to solve that issue
> without much memory overhead and cpu time.
> Best regards,
> *From:* Alex Aranda <alex@...>
> *Sent:* Saturday, September 03, 2011 11:56 AM
> *To:* Jan-Martin Ziem <jmziem@...>
> *Cc:* aTunes-Developers@...
> *Subject:* Re: [aTunes-Developers] fix for feature request 2383183
> I reviewed your patch and see a problem with it: each time you need access
> to a repository structure you have to test if case sensitive is enabled or
> disabled. That is a maintenance problem given the amount of calls all around
> the code to that methods.
> I think one better solution would be to encapsulate that check, maybe
> creating a class extending HashMap, maybe something like
> public class CaseSensitiveHashMap<T> extends HashMap<String, T>
> and making case sensitive transparent to rest of source code.
> @alex_aranda <http://twitter.com/alex_aranda>
> 2011/8/3 Jan-Martin Ziem <jmziem@...>
>> please validate the patch.
>> Main behavior: a new flag was introduced to support (or disable, which is
>> default) case sensitive keys in repository structures of artists and genres.
>> All accessors where updated (repositoryloader, repositoryfiller etc.) and
>> the navigator preference panel was updated with one checkbox.
>> After switching the checkbox, a repository rebuild/update is required -
>> this is currently not done automaticly.
>> All changes are documented and easy to understand.
>> best regards,
>> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
>> The must-attend event for mobile developers. Connect with experts.
>> Get tools for creating Super Apps. See the latest technologies.
>> Sessions, hands-on labs, demos & much more. Register early & save!
>> aTunes-Developers mailing list