Please ignore the latest commit, it's just whitespace fixes.
The commit of interest is the penultimate one:
Fixed unit tests that were failing when run on windoze
Revert "Fixed unit tests that were failing when run on windoze"
This reverts commit 7307b5695020c5858b3554d19847925815ce3028.
Fixed tests to be platform independent
Add the ability to extract and cache album/track cover art from tags …
…on scan. Must be enabled from GUI (default is disabled) Also added a few constants for application folders and moved common utilities for cover art to single class
Split CoverArtUtils into CoverArt and CoverArtCache. Created CoverArt…
…Indexer and move some of the logic from DBCollectionManager to there.
Merge branch 'master' of git://github.com/rodnaph/sockso
Added tests for CoverArt and CoverArtCache
Fixing bad merge made by newbie. Fine: 10 lashes
Coverer plugin refactoring
Added more tests for RemoteCoverer plugin
Created ImageCache inteface for CoverArtCache
Bound CoverSearch interface to AmazonCoverSearch class
Refactored DefaultCoverer a bit
Fixing whitespace (s/tabs/spaces/g)
Oh and lots of whitespace changes... :-/
Further to using the Cache interface - you could extend this new TimedCache class...
With a FileCache implementation, and use that for the cover cache.
Have you looked into using a WeakHashMap instead of HashMap for the ObjectCache?
I'm trying to understand what your thinking is here for the refactor:
Rename CoverArtCache -> FileCache and extend TimedCache instead of implementing ImageCache?
So the TimedCache is an "in memory" cache, in that, the image data should not be cached on the file system anymore? Or do you mean to leave the file system cache alone and supplement it with a faster in memory cache that has an expiration?
I see the point of putting the images in memory, as reading from disk is expensive and it might make the cover art quite a bit snappier on the client side. Just trying to figure out how to separate file system caching and in memory caching...
No, sorry I should have explained a bit more. The TimedCache is an abstract class that just requires implementing readRaw() and writeRaw() for data storage. This is then extended by ObjectCache that uses a simple HashMap to provide an in-memory cache.
What you can do is create a another class called CoverArtCache that extends TimedCache, and just implements readRaw() and writeRaw() and what you can do here is read/write the images to/from the file system. So you get all the benefits of TimedCache, and the same interface via Cache. (i said FileCache to be more generic, but it might make sense for now to call it CoverArtCache)
Does that make sense?
I haven't heard of the WeakHashMap no - I'll take a look thanks!
OK, I thought you were trying to create a hybrid cache class for the coverart that read/writes to the file system and also keeps the images in memory...I was a bit confused how that would work :)
I would assume I need to extend CoverArt from CachedObject now? If I move the code from getCoverArt() to readRaw(), then call readRaw() from the body of getCoverArt(), since getCoverArt() returns a CoverArt, I can't covert a CachedObject (which readRaw() returns) to a CoverArt object, correct?
Trying to imagine what your idea was for implementing this correctly...
Nevermind, I just realized CachedObject.getValue() is for that very purpose.
Change CoverArtCache to extend from TimedCache
Should TimedCache.readRaw()/writeRaw() throw IOException's? The problem I'm running into is that the CoverArtCache needs to do IO to read/write images, but doing that could cause an IOException to be raised. If I implement this in the read/writeRaw ops, I can't re-throw it up the stack - the only option I see is returning a null CachedObject or an empty one. (see TODO's)
Ah yes I didn't think of Exception's - yes please just alter the interface so those methods throw Exceptions (because it might not just be IOExceptions that implementors need to throw).
Is that a good idea? Now methods of ObjectCache throw Exceptions unnecessarily (since it extends TimedCached which implements Cache interface) and require client code to catch them. I think maybe the Cache interface is a bit too generic for both the CoverArtCache (which throws IOExceptions) and an ObjectCache (which throws nothing).
Yeah don't worry about it, throwing exceptions is fine! :)
Added CacheException for Cache interface
I decided a CacheException class would be best rather than throw Exception everywhere. Let me know what you think.
What do you think about adding auth token functionality for mobile apps to the api (see soundcloud doc for example: http://developers.soundcloud.com/docs/api/authentication#authorization-code-flow)
Currently, the only way to do this is via a cookie, which is kinda awkward to program on android :\
Hmm... Not sure about token auth, maybe... but we can deal with that in a separate pull request.
Is this cache feature complete now then? I'll check it out later and pull it to master if it's done.
Yes, it's completed and all tests passed.
merged refactor to make cover cache use cache interface (fixes #101)
Ok I've merged this to master now, thanks!
Few things I noticed when merging though, firstly all the whitespace changes - I think these were introduced ages ago so maybe not to worry about now. But I had to manually unstage them all before commit (git reset -p). If your IDE keeps doing this then you can use interactive add to make sure they don't get committed (git add -i).
Also, I always make variables final (unless impossible), this just keeps me on top of reducing mutation as much as possible, and usually results in cleaner less buggy code I find.
Looking forward to your token auth pull request ;)
Arrrgh, I thought I fixed the whitespace issues!