Tile Provider Refactoring

[GoogleCodeExporter]

Hi, I've had some time to burn, so I did some refactoring to the tile
provider / tile caching layer. I've attached a diff against the current svn
head and a plain java test project I've used to test my classes. I hope you
can make use of it.

Non-exhaustive list of changes:
* add slf4j for logging (needed this to cut android-runtime dependencies -
please install http://www.slf4j.org/android/slf4j-android-1.5.8.jar into lib)
* tile loading is not a service anymore, runs in main process
* database dropped
* fixed OpenStreetMapTile's hashCode()/equals()
* some fixes to OpenStreetMapTilesOverlay

Original issue reported on code.google.com by nicolas....@gmail.com on 22 Apr 2010 at 3:21

Attachments:

• osm-patch.txt
• osm-test.zip

[GoogleCodeExporter]

Hi Nicolas

I'm glad someone's got some time :-)  I haven't tried your code yet but the 
changes you described sound like things I've 
been thinking about doing.  It also ties in with issue 41, and especially with 
issue 43.  May I suggest that you ask the 
project owner to make you a committer and make a new branch for issue 43 and 
make these changes there.

A couple of comments:
1. You've done a lot of format changes, especially whitespace, which makes it 
difficult to compare versions.
2. You seem to have an unlimited tile cache and provider queues, which will 
cause all the memory problems that I 
"resolved" in issue 9 among others.

Neil

Original comment by neilboyd on 23 Apr 2010 at 10:58

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Hi Neil,

thanks for your comments. Sorry about the whitespace changes. When doing the 
diffs,
I'd noticed that as well but then it was too late :-( I've changed my eclipse
settings for this project now. 

Re 2.) The bitmap tile cache does have a limit, but it's fairly simple and will 
clear
the whole cache once the size threshold is reached. I didn't quite get your 
better
approach with LinkedHashMap until now, but it should be no problem to revert to 
that.

What would remain now is the issue with the queue. Like you, I originally 
thought
using ExecutorService would be the way to go until I found out about the 
absence of
BlockingDeque. Do you think dropping in the concurrent backport lib
(http://backport-jsr166.sourceforge.net/) would be an option?

Thanks,
  Nicolas

Original comment by nicolas....@gmail.com on 23 Apr 2010 at 1:57

[GoogleCodeExporter]

The idea with the queues is that the most recently accessed should be the first 
out 
when getting, and the least recently accessed should be the first to drop off 
the end 
when putting.  There's no need to check whether an item already exists because 
you 
always put, but if it already exists then it just moves up the queue.

Remember that performance and memory usage are ultimately what makes this app 
usable or 
not.

Original comment by neilboyd on 23 Apr 2010 at 3:22

[GoogleCodeExporter]

Bits of this are done and bits are obsolete now.

Original comment by neilboyd on 11 Oct 2010 at 5:41

• Changed state: WontFix