Rewrite: AndroidGraphicFactory getCanvas

[emux]

Hi Thilo,

Could you please add a public static getCanvas method to AndroidGraphicFactory which returns the android.graphics.Canvas of an org.mapsforge.map.android.graphics.AndroidCanvas ?
Something similar to AndroidGraphicFactory.getBitmap method (which now is not public?).
This is quite useful in classes that we want to override its draw method which uses now the org.mapsforge.core.graphics.Canvas, in order to use the original android.graphics.Canvas for custom drawing or feed the canvas to methods that use the android.graphics.Canvas.

Thanks!

[Thilo Mühlberg]

Makes sense, I just changed that with Git revision 916f57f5d0d6.

Greetings,
Thilo

> --
> You received this message because you are subscribed to the Google
> Groups "mapsforge-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mapsforge-de...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[emux]

Thanks Thilo!

Could you please make public also the AndroidGraphicFactory.getPaint ?
I want to use Polyline with a paintStroke and the org.mapsforge.map.android.graphics.AndroidPaint parameter does not meet my needs, it lacks methods.
For example I don't want the Cap and Join that are in AndroidPaint's constructor, but only the 1st has set method.
So I prefer getting the original android.graphics.Paint and modify it as wish.

A question about the graphics classes.
Why you choose to have custom graphics classes and use them at mapsforge draw and other methods?
And why encapsulation of original android.graphics class and not extending it, so we can have all original class functionality?
Now it is difficult to use graphics methods that are not yet implemented by yours.

Regards.

[Thilo Mühlberg]

The idea of the graphic interfaces and the AndroidGraphicFactory is to
separate the mapsforge-map library from the underlying 2D graphic layer.
With this additional abstraction layer the map rendering and the code
for displaying layers etc. can be used not only on Android but also on
other platforms. It also greatly simplifies writing unit tests.

There is already an implementation for AWT/Swing and a demo application
called MapViewer which runs on standard desktop PCs (Windows, Linux, …).

Greetings,
Thilo

[emux]

I understand your point. I have already checked the SwingMapViewer.

But why encapsulation of original classes and not extending it?

[Thilo Mühlberg]

Because the graphics API does not necessarily equals the Android 2D API.
When I started to write the wrapper classes I had an adapter in mind
which delegates calls freely to the native implementation.

I still don't see the big advantage of extending the original classes.
Maybe it makes casting easier, but normally you should not have to do
this. If a certain method or feature is missing in the graphics
interfaces we should rather add it there than recommend casting objects
all the time. Would also be interesting to know if extending the
original classes significantly changes the drawing performance.

Best regards,
Thilo

> > an email to mapsforge-de...@googlegroups.com <javascript:>.

> > For more options, visit https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.

[emux]

Hi Thilo,

Just for flexibility it would be very convenient to have all AndroidGraphicFactory's get methods as public, so we can get original android graphic classes from the mapsforge ones.

Regards.

[deve...@gmail.com]

Hi Thilo,

Is there any chance to to have all AndroidGraphicFactory's get methods as public?
So we can get original android graphic classes from the mapsforge ones and use them directly.

Also can you add the Paint.measureText(String text) method to AndroidPaint?
As it give different results from the Paint.getTextBounds which is used in AndroidPaint.getTextWidth

Best regards.

[Thilo Mühlberg]

Hi,

I am against making Android-specific classes or methods public. This
would break the idea of an independent graphic layer between the
rendering application and the low level drawing implementation. The
current visibility modifiers have been chosen purposely.

Adding missing stuff is fine as long it fits into the concept. If a
certain method is needed, it should rather be added to the interface and
implemented in the AWT graphics adapter too. This is a small overhead
but it allows shared code between Android and desktop Java. Can you
describe what exactly is missing for your use case?

Regarding your second question:
I just read
http://stackoverflow.com/questions/7549182/android-paint-measuretext-vs-gettextbounds
to learn the difference between these two methods. The Android API is
pretty confusing here as the documentation does not mention this. Let's
try to avoid copying that design flaw into our graphics API and rather
have two clearly distinct methods or one method which takes a second
parameter. Which solution would you prefer?

Greetings,
Thilo

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mapsforge-dev/333e970d-2e73-422a-9660-7122b5f513df%40googlegroups.com.

[deve...@gmail.com]

Hi Thilo,

I need to get the width of a text and saw that the measureText and getTextBounds results are different (working with both branches master+rewrite).
Searching for answers I have also read the article you wrote about and also the: http://stackoverflow.com/a/14766372

You mean two clearly distinct methods using measureText and getTextBounds ?
Yes that would be nice.

Regards.