Update API docs for for MBTiles (maybe) about mbxmapkit

[incanus]

If we ifdef the MBTiles solution and anything resulting from it, we should also ifdef the header documentation, otherwise we're going to get compile-time warnings with undefined methods anyway.

[incanus]

Sorry, to be clear: anything in the API should be documented, but if we are using ifdef for things, the docs should toggle similarly. This will get picked up by things like local runs of appledoc or the use of CocoaPods, which I think will require us to use subspecs for these various optional features.

Yeah, the doc comments I added to the header are inside the ifdef so if I'm understanding you correctly, I don't think that will be a problem.

My point was a little bit more along the lines of whether you want to remove the ifdef around MBXMapViewTileOverlay (i.e. de-couple it from the MBTiles stuff) [edit: I could have been a bit more clear about that]. That's necessary for #7 and anything else where somebody wants to hit MKTileOverlay properties from a view controller. The present arrangement (no MBXMapViewTileOverlay in the header) is hiding/breaking part of the MKMapKit api.

[incanus]

My point was a little bit more along the lines of whether you want to remove the ifdef around MBXMapViewTileOverlay (i.e. de-couple it from the MBTiles stuff). That's necessary for #7 and anything else where ...

Ok. We should probably either decide for/against that in the #3 MBTiles solution itself (on deck: #20) or break it into a separate issue ("expose MBXMapViewTileOverlay to public API because $reasons"), at which point we'd document it there. That lets us decide the merits of doing that change on its own terms and lets us iterate first on the MBTiles feature, then on a new API feature.

Okay cool, let's just worry about that later. There are enough hints in all these issues that anybody who cares badly enough should be able to figure out how to make it work for now.