Launch with high quality API

[ljbade]

As @bleege mentioned in #2002 the JavaDoc work was starting to creep scope to include fixing various problems with the API I was noticing.

This ticket will allow us to track this separately.

This includes areas such as:

• annotations and null checks, int range checks (eg don't just pass on negative int when C++ expects unsigned ints)
• functions/classes exposed as "public" that should remain private (eg the functions that were only exposed for InfoWindow to hook into) - Use single package for SDK #2538 plays a role in this
• functions that don't follow a clear logical pattern (eg Organise annotations function definitions #2539)

Releasing our first major version on Android means we want the "existing" feature set's API to be high quality if we stick to semver. If we can hit this in time for 2.1.0 then we will avoid the need to jump to 3.0.0 as our next release so we can fixup the API.

@bleege @tobrun

[ljbade]

Something I picked up last night, MapView exposes a few internal methods as public because it directly implements LocationListener and CompassView.CompassDelegate. Instead these should be refactored to be private inner classes like all the other internal listeners we have for touch events etc.

[ljbade]

I have also realised we should be more ruthless at removing dead/commented out code, and TODOs from master. We can always revive old code again easily thanks to git history.

[ljbade]

onSizeChanged is public. Make protected and @Override

[ljbade]

Inner class ConnectivityReceiver is package private. Make private

[ljbade]

Noticed that Google are very careful to mark functions final. I wonder why if the class is already final. Found some references that final functions get optimised more...

[ljbade]

getAnnotationsInBounds only returns markers. Perhaps rename? or configure to support the type of annotation like the underlying C++ function.

[ljbade]

These were fixed.