Make osmdroid usable as a library about osmdroid HOT 19 CLOSED

Neil, thanks for creating the issue, I'll add some background on my need and 
what I intend to try to contribute.

I am going to try to port osmdroid to blackberry's java APIs so I can use it in 
a product I am developing. I've taken a 
look at Blackberry's APIs, it's Java but with differences. From a quick browser 
I saw the following differences : there 
is no equivalent to Activities and Services, no Handlers, drawing is done 
differently and network connections are handled 
with a specific API.
I would rather participate in a code refactoring of osmdroid rather than fork 
the project so this is the ideal issue to 
discuss this.

I haven't looked at the latest trunk line nor the patches so maybe some of what 
I will write below has already been done, 
please give me some feedback.
The line of attack I was intending to follow was to isolate all generic code 
(tile calculations, caching, etc) from the 
Android specific classes and have the Android classes delegate calls to methods 
on those generic classes. Then I would be 
able to build Blackberry classes to delegate to those same generic classes.
In some cases it might make sense to use inheritence such as for file IO in the 
tile caching subsystem or when creating 
strings.

Regarding R constants and resources, the way I've been doing in my project 
where I have an SDK that needs to display 
strings is to define each string constant in an RPoxy interface and have each 
application using the SDK JAR provide the 
RPoxy interface to the activities, services, etc by subclassing my SDK classes 
and instantiating that class during 
construction. The SDK classes all have an abstract getRProxy() method... you 
get the idea.
Since Android allows any file name in the strings directory, I provide a 
complete strings file that contains everything 
that's needed (same for layouts, etc). I also provide a default RProxyImpl 
class that refers to those constants. If 
RProxyImpl is positionned in the package used in the manifest, no import is 
required for R and it works out of the box.
I'll have to dive into the blackberry SDK to see how this would need to be 
modified : I'd probably have RProxy return 
strings rather than ints..
Nicolas is going to give me write access and I'd like to do this on a branch so 
others can test the changes before they 
get merged into trunk.

Your thoughts ?  Please note this is a proposed solution to a totally different 
problem than sharing the cache across 
installed apps.

That would mean having these projects:

1. a pure Java (not Android) library for the common parts
2. an Android library for the Android library parts (views etc) - uses common 
library
3. the same for Blackberry (were you intending to make this a part of osmdroid?)
4. the current OpenStreetMapViewer project - uses 1 and 2 (lots of code moved 
out)

Anyone else using osmdroid would do the same kind of stuff that 4 does (or 
using 1 and 3 for Blackberry).

Yeah, that's the way I see it. Anyone else want to chip in on the discussion ?
Do you anticipate any problems with this line of attack ?

And how about putting the whole tile provider stuff into 1 instead of having a 
separate service?

@watcherFR may I suggest that you ask the project owner to make you a committer 
and 
make these changes in a branch.

See also issue 45.

I have created a branch for this issue.

My plan is the following:
1. create empty projects for the jars
2. gradually move code from OpenStreetMapViewer into the new projects *without 
changing anything*
3. later think about changes such as those suggested in issue 45.

If it goes well up to step 2, that would probably be a good time to merge back 
into 
trunk.

Done step 1 in revision 148

@neilboyd, been caught up with something else. Won't be able to work on it as 
soon as I thought.
Anyway, do you want me to put my changes into the branch mentioned in comment 6 
of this issue or another 
one ?

I've moved some more code into the jars, up as far as revision 157.

It also includes a simple resource provider, but having just re-read comment 1 
above I could do it better.

*BUT* I'm at the point where the service is interfering. The service uses a 
generated interface, and it's quite well 
embedded into the overlays and thus the main map view.

I think it might be better to "prepare" the trunk by removing the service and 
the database, and a little bit of re-
organising within the packages so that it becomes more obvious which package 
belongs in which jar. We could also do 
the resource proxy beforehand. And then we can start again with extracting it 
into jars.

I think this is a great idea!
Maybe this is an opportunity to make this library something that is a drop-in
replacement for Google Maps. There are many apps that use the Google Maps API 
and
they might want to switch to osmdroid for licensing/feature reasons so it'd be 
great
to make this easy.

I have a new plan ;-)

1. Get rid of the database.
2. Get rid of the service.
3. Make *one* new project for OpenStreetMapView library and the supporting 
classes.
4. Split out into two libraries (one Android and one generic).

I'll do each of steps 1 to 3 on it's own branch. I'll try and do each one 
quickly to avoid diverging the code. 
(When I say quickly I don't mean soon - I mean when I have time I'll do it in 
one big chunk).

I'm not too bothered about step 4 - perhaps someone else could do it.

I've done point 1 from the previous comment. This is the same as issue 41.

I made a bit of a mess of the branch so I'll make a new one.

I've removed the service and I'm ready to merge this back into trunk.

It's not actually removed, I've just made it optional - if the service exists 
then it'll use it, otherwise 
it won't.

I didn't do any real measurements, but my impression is that the non-service 
version is much quicker.

I'd appreciate some people looking at it. My plan is to merge it into trunk at 
the beginning on next week.

It's the branch issue-43-no-service.

Maybe something interesting with the latest Android SDK:
http://developer.android.com/guide/developing/other-ide.html#libraryProject

Thanks for that suggestion. This might be partly useful but my aim is still to 
make a 
jar. Perhaps I can make a library project but make a jar rather than use it the 
way 
it's intended. Doing it as a regular library project would be a good second 
best in 
case the jar doesn't work out.

I've merged in the change to allow the tile provider to run without being in a 
service.

And made a new branch for the real work of this issue.

Revision 194.

I think I'm ready to merge the jar version back into trunk.

This is the branch issue-43-jar.

I'll probably merge it in early next week.

This is now merged into trunk with revision 225.

This issue is now resolved.

Further work regarding making osmdroid useable for non-Android platforms has 
been moved to issue 62.