Comments (19)
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.
Original comment by [email protected]
on 16 Apr 2010 at 7:29
from osmdroid.
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).
Original comment by neilboyd
on 17 Apr 2010 at 8:07
from osmdroid.
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 ?
Original comment by [email protected]
on 18 Apr 2010 at 9:27
from osmdroid.
And how about putting the whole tile provider stuff into 1 instead of having a
separate service?
Original comment by neilboyd
on 19 Apr 2010 at 5:07
from osmdroid.
@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.
Original comment by neilboyd
on 23 Apr 2010 at 10:53
from osmdroid.
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.
Original comment by neilboyd
on 29 Apr 2010 at 7:24
- Changed state: Started
from osmdroid.
Done step 1 in revision 148
Original comment by neilboyd
on 29 Apr 2010 at 8:59
from osmdroid.
@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 ?
Original comment by [email protected]
on 2 May 2010 at 9:36
from osmdroid.
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.
Original comment by neilboyd
on 4 May 2010 at 9:17
from osmdroid.
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.
Original comment by [email protected]
on 11 May 2010 at 12:25
from osmdroid.
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.
Original comment by neilboyd
on 11 May 2010 at 3:07
- Added labels: Priority-High
- Removed labels: Priority-Medium
from osmdroid.
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.
Original comment by neilboyd
on 12 May 2010 at 8:35
from osmdroid.
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.
Original comment by neilboyd
on 21 May 2010 at 10:22
from osmdroid.
Maybe something interesting with the latest Android SDK:
http://developer.android.com/guide/developing/other-ide.html#libraryProject
Original comment by [email protected]
on 21 May 2010 at 12:23
from osmdroid.
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.
Original comment by neilboyd
on 21 May 2010 at 1:28
from osmdroid.
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.
Original comment by neilboyd
on 25 May 2010 at 12:11
from osmdroid.
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.
Original comment by neilboyd
on 10 Jun 2010 at 11:27
from osmdroid.
This is now merged into trunk with revision 225.
Original comment by neilboyd
on 18 Jun 2010 at 1:28
from osmdroid.
This issue is now resolved.
Further work regarding making osmdroid useable for non-Android platforms has
been moved to issue 62.
Original comment by neilboyd
on 18 Jun 2010 at 1:33
- Changed state: Fixed
from osmdroid.
Related Issues (20)
- Offline Map simply does not work! HOT 3
- BoundingBoxE6 contains method has unexpected behaivour HOT 2
- Add ability ta change MyLocationNewOverlay icons HOT 1
- Low memory exception
- Transparent MBTiles
- Path Overlay drawn incorrect
- minimap rotating error HOT 1
- Issue loading previously created tiles from MapquestOSM folder
- NullPointerException during in Projection.toPixel() from MapController.animateTo() HOT 5
- I can't display any map, only empty squares HOT 2
- image layout HOT 1
- incomplete map is shown HOT 1
- Constantly loading offline tiles HOT 2
- MyLocationNewOverlay memory leak on using enableMyLocation HOT 4
- empty tiles download
- Delete selected area cache.
- [deleted issue]
- no HOT 1
- Default image tiles in place for null maptiles because there is no tile for that zoom level .
- NullPointer exception while try to draw a quite big polygon
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from osmdroid.