Refactoring work to be done during merge

[GoogleCodeExporter]

The plan to integrate the new modular tile architecture branch is to create a 
new namespace in the trunk and combine parts from the current namespace and the 
branch to make sure we have the latest from each. This gives us a window of 
opportunity to implement some refactoring tasks.

The ideas that have been thrown around by Neil and me:

1. Changing namespace from "org.andnav" to "org.osmdroid"
2. Changing parameter prefixes from "a" to "p" 
3. Removing "OpenStreetMap" prefixes on all files - do we want to replace it 
with "OSM", or drop the prefix altogether?
4. Any desire to bump up the API requirements? According to the source, 1.6 
would give us native zoom controls.
5. Should we consider making osmdroid an Android library instead of a JAR? With 
the latest SDK, Android libraries appear to be more functional.

Comments? Additional refactoring requests?

Original issue reported on code.google.com by kurtzm...@gmail.com on 31 Dec 2010 at 1:55

• Blocking: #112

[GoogleCodeExporter]

Regarding point 3, I think we should drop it altogether, except in some cases 
keep "Map", for example MapView.

I don't see any benefit in doing 4 and 5 yet.  1.5 is still fairly well used.  
Perhaps you should make separate issues for these.

A couple of others thing we could consider are:

6. Make it more consistent with Google Maps
7. Use 100 line width
8. Use final wherever possible, especially parameters

BTW does anyone know a good way of moving in svn?  If you move a file in 
Eclipse it counts as a delete/add in svn, which is not good (it loses the 
history).  If you move in the repository browser (or the command line) then you 
have to do one file at a time with an immediate commit and then fix the compile 
errors as a separate commit.
(I could answer my own question with this: 
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-rename.html but 
I'll ask anyway).

Original comment by neilboyd on 31 Dec 2010 at 7:32

[GoogleCodeExporter]

Perhaps we should also do issue 62 now.
Or if not, then cancel that issue and rename the project and the jar to remove 
the -android suffix.

Original comment by neilboyd on 31 Dec 2010 at 9:28

[GoogleCodeExporter]

Point 1: underlines the fact that this project is independent of AndNav.

Point 2: Sounds useful - is this a pattern recommended by Google or just a 
"best-practise"?

Regarding Point 3 and 6: It depends on how you define osmdroid. If its only 
focus is (and will be) OSM there is no need to use a OSM related prefix. If you 
see osmdroid as a general map abstraction including a OSM implementation you 
will need to keep the prefix (at least in cases like OpenStreetMapView). I'm 
pointing out this second point of view since most app developers will not be 
able to rely completely on OSM even though they personally favor it over Google 
Maps. Currently every of them has to develop an integration layer on top of 
osmdroid/Google Maps. I like and use the proxy classes of of the 
open-gpstracker project representing this integration layer. It should be worth 
considering to include them into the osmdroid project if we agree to the 
broader focus of osmdroid.

9. Add more comments: This is a framework and it is likely that developers not 
familiar with osmdroid internals will sometimes have to debug into the code. 
Besides, the comments will preserve whatever knowledge you have acquired about 
this domain.

Reading SVN move: With SmartSVN (Java) can move files/folders without loosing 
their history.

Original comment by camueller28 on 31 Dec 2010 at 10:16

[GoogleCodeExporter]

I would cancel issue 62, keep a strong Android focus but include the 
integration layer described in comment 3. This would be most beneficial for a 
lot of developers.

Original comment by camueller28 on 31 Dec 2010 at 10:19

[GoogleCodeExporter]

There was a discussion about making a wrapper a while ago:
https://groups.google.com/d/msg/osmdroid/kOzmu7uwtBM/iQXBrqckef4J
I'm still in favour of this. It could be done now or later. I guess we should 
make an issue for it. The idea is that we add interfaces for common classes, 
and then make a new project that wraps Google Maps up in these interfaces.
However, I don't see that it invalidates the need to remove the OSM prefix. If 
osmdroid and Google both have a MapView class that's not a problem. Users will 
only use the IMapView interface.
The project name already includes "osm" in it, and I think the intention is to 
keep it for OSM only.

The changes Marc has been making in the branch include a lot of improvements to 
the documentation, so this will also be merged in.  Of course there's always 
room for more.

Original comment by neilboyd on 31 Dec 2010 at 10:42

[GoogleCodeExporter]

It's an interesting point - this branch has made the project tile-provider 
independent (actually, it's always been that way), so it's not as tied to OSM, 
but I think the project will continue to be heavily associated with and 
typically used with OSM. That being said, I agree with Neil that we should drop 
the OSM prefixes. It's adds clutter.

The abstraction layer should be a separate ticket. It sounds like a great idea!

Original comment by kurtzm...@gmail.com on 1 Jan 2011 at 3:41

[GoogleCodeExporter]

Updated list of tasks:
1. Changing namespace from "org.andnav" to "org.osmdroid"
2. Changing parameter prefixes from "a" to "p" 
3. Removing "OpenStreetMap" prefixes on all files (except in some cases keep 
"Map", for example MapView)
4. Use "Eclipse" code formatting settings, but change code and comments line 
width to 100
5. Use final wherever possible, especially parameters

Original comment by kurtzm...@gmail.com on 1 Jan 2011 at 3:43

[GoogleCodeExporter]

Number 3 should try to keep naming in-line with Google Maps naming as described 
in:
http://groups.google.com/group/osmdroid/browse_thread/thread/d3d4f3f278657427

Original comment by kurtzm...@gmail.com on 1 Jan 2011 at 6:30

[GoogleCodeExporter]

1: I agree
2: If you see a need for parameter prefixes at all, go ahead.
3: Please remove those class prefixes. I agree with Neil that "MapView" is a 
good name.
4: If a good move, better done as separate commit
5: If a good move, better done as separate commit
6: I really agree
7: Agreed
8: If you care to :)

Regarding moving in svn, I recommend using the command line which results in 
copy+rm.
http://svnbook.red-bean.com/en/1.1/re18.html
Moving a whole directory works for me. You should also be able to do multiple 
moves in a single commit as long as they regard separate files. Fixing the 
package names is better done as a subsequent, separate commit to appease svn 
and for clarity. I can do it for you if you give me the details.

Original comment by andpet@gmail.com on 1 Jan 2011 at 10:29

[GoogleCodeExporter]

Current Status:
1. Done! The merge is complete, and in the trunk under a new namespace. The old 
API is still there for the time being. We'll likely keep it until *everything* 
is done.
2. Pending
3. Pending
4. Pending
5. Pending

Original comment by kurtzm...@gmail.com on 2 Jan 2011 at 4:06

[GoogleCodeExporter]

Current Status:
1. Done! The merge is complete, and in the trunk under a new namespace. The old 
API is still there for the time being. We'll likely keep it until *everything* 
is done.
2. Pending (might not be possible to automate - can anyone confirm?)
3. Pending
4. Done! Formatting settings XML file added to trunk
5. Done! Clean-up settings XML file added to trunk

Original comment by kurtzm...@gmail.com on 2 Jan 2011 at 10:26

[GoogleCodeExporter]

Current Status:
1. Done! The merge is complete, and in the trunk under a new namespace. The old 
API is still there for the time being. We'll likely keep it until *everything* 
is done.
2. Pending (might not be possible to automate - can anyone confirm?)
3. Done!
4. Done! Formatting settings XML file added to trunk
5. Done! Clean-up settings XML file added to trunk

Original comment by kurtzm...@gmail.com on 2 Jan 2011 at 11:42

[GoogleCodeExporter]

#2 will not get done - sorry, it's all got to be done field-by-field :)  feel 
free to pick a class or a package and lend a hand!

Otherwise - this ticket is toast!

Original comment by kurtzm...@gmail.com on 4 Jan 2011 at 3:48

• Changed state: Fixed

[GoogleCodeExporter]

The abstraction layer is issue 131.

Original comment by neilboyd on 4 Jan 2011 at 6:12