Map API
Nutiteq Maps Lib SDK enables developing advanced mobile mapping applications.Platforms: Android, RIM BlackBerry, Java ME (J2ME)
Download maps API SDK »
Access to native BB graphics
Hi all,
I'm evaluating this library for use in one of my BB apps. I'm trying to custom draw the labels, but I ran into the problem that the Graphic wrapper that is passed to the PlaceLabel.paint() is rather basic and does not give access to the native BlackBerry Graphics.
Furthermore, the MapComponent double buffers the paints on the BlackBerry (AFAIK this only wastes resources since the RIM API does some double-buffering of his own). Because of this I cannot simply paint the label on the MapComponent's Graphics (it will just get overdrawn by the map).
The way things stand right now the only way I can get around this is by decompiling the Graphics wrapper to make the native rim Graphics public or decompiling the MapComponent to make it not double buffer.
Neither of these solutions are really appealing for a library we're considering buying. Or am I forced to draw the label only with fillRect and drawString (with the default font).
Is there any solution I'm missing?
getNative() will indeed allow me to draw proper custom labels by overriding PlaceLabel.paint() and using the Graphics I receive from there. So it would solve the most important blocker.
Still there is no way to disable the double buffering, but that is a minor issue.
I am reluctant however to use something labeled "beta" for our application...
jaak, I ended up decompiling 3 or 4 more classes while trying to get our in-house map provider to work. I have the following questions:
- if I understand what you are saying, if we buy the licence for the library, we can obtain the source code for it so we can modify it easily for the purpose of our application? What restrictions, costs and limitations are associated with access to this code?
- As I mentioned above, we intend to use our own map provider, which is not in the official supported map providers list. Does nutiteq has any objections to that?
Yes, you'll get the source and you can modify it also. However, we do not encourage it as then updates will be quite painful, if not impossible. Source is useful to find samples of interface implementations. And if you'll fix some bug, improve performance or some other internal thing then we'd like to hear about it and possibly incorporate somehow it to the general library version. Then also updates will be possible.
Adding own map provider is kind of standard integration task for developers and there is public API for this, so in principle you should not need to modify any library source for it. There are also some code samples in the forum here (e.g. http://www.nutiteq.com/content/custom-map-source-local-area).
From our point of view you can use any map provider, then you should take care of the licensing part.
The library latest state (http://nutiteq.com/beta/lib has now method getNative(). Would this solve your case, or would the double buffering still be issue?
I'm sorry that the lib has lingered in the beta phase way too long. Your feedback about the latest (beta) RIM library would also help to get it as official release also.
For customers (and potential active contributors) we are also open to share the source package, so you should not need to think about decompilation option.
/JaakL