3 ms·
Author of said library here. I still work for Google, but I'm not on the Maps team anymore :) Agree that some of the functionality in the util library should b
by chrisbroadfoot 11y ago
Author of said library here. I still work for Google, but I'm not on the Maps team anymore :)
Agree that some of the functionality in the util library should be in the base library, or the util library linked to from the Maps documentation. For example, all of the spherical math stuff.
However, I'm not happy with how some of the API turned out. The clustering library is quite complex. I think it's fairly well designed, but overly flexible. I'd re-do quite a few things, given another chance. It's always hard to get those kinds of APIs right the first time. You don't get to re-do things like that once they're in the official SDK. That API needs to be supported approximately forever.
- mmg 11y agoIs there a reason why so much functionality is not exposed?
- chrisbroadfoot 11y agoNot sure what you mean specifically, but here's some of my thoughts (note that these do not represent those of the product team)... * Technical reasons. All calls to Android Maps API happen via an IPC (inter-process, not intra-process, actually), so they are generally slow. That could be bad for things that should be fast to compute like everything in SphericalUtil and PolyUtil. * It's hard to design a nice API for Clustering. Having it open-source means Google doesn't have to guarantee support for that API according to the ToS (iirc, >1 year) * Open source library code demonstrates use of the API. You could think of it as additional sample code. * There's some value in having open source code, generally. A lot of the stuff could be useful in other settings - for example, you could port a lot of the math code to other languages.