Inconsistency between initWithFrame and initWithCoder

[newmanw]

This may be intended, but an explanation on why would help me out tremulously.

When I init an MBXMapView from code:

    mapView = [[MBXMapView alloc] initWithFrame:self.view.frame];

I can see the default apple map, which is perfect cause at this point I have not added any tile overlays.

However if I add the MBXMapView in a storyboard the initWithCoder method is called. It then does:

    [self MBXMapView_commonSetupWithMapID:nil showDefaultBaseLayerMode:MBXMapViewShowDefaultBaseLayerNever];

The call uses 'MBXMapViewShowDefaultBaseLayerNever' which then adds a blank overlay on top of the apple maps.

Why is that the default behavior? If that is intended I guess I would argue that MBXMapView also overrides the initWithFrame method to execute the same code such that storyboard init and non-storyboard init both work the same.

Big question is why add a blank overlay by default?

[ghost]

Hi @newmanw, a few thoughts in response to your question...

First of all, if you want something that works pretty well and allows you to manipulate overlays, I'd recommend something like this in your view controller:

@interface MBXViewController ()
@property (nonatomic) MBXMapView *mapView;
@end

@implementation MBXViewController
- (void)viewDidLoad
{
    [super viewDidLoad];
    self.mapView = [[MBXMapView alloc] initWithFrame:self.view.bounds mapID:@"examples.map-pgygbwdm"];
    [self.view addSubview:self.mapView];
}
@end

if you use initWithFrame: rather than initWithFrame:mapID:, the initialization process for loading TileJSON for that mapID, and using it to configure a overlay layer, will not work.

That said, your question seems to be more about "Why is it doing what it's doing?". For that, the issue is that when creating an MKTileOverlay and adding it to an MKMapView, you need to know several things about how it should be initialized. In its current form, MBXMapKit includes a network call (fetch TileJSON based on a mapID) to determine that information about how to configure the overlay. Because the network call might take an unpredictable amount of time to complete, something needs to be shown on screen immediately when the MBXMapView is initialized. MBXMapKit's present solution is to add an empty placeholder layer (an MBXMapViewTileOverlay), then replace that layer once TileJSON is available to configure the real map for that mapID. Any differences between a storyboard and programatic initialization are probably accidental.

A key thing to understand is that the original design of MBXMapKit was intended to support a specific scenario which is somewhat more narrow than what an MKMapView generally allows. It was intended to give you an MBXMapView with a single MBXMapViewTileOverlay (a mapbox.com hosted map, specified by its mapID).

That said, things are changing. There's been some discussion about moving TileJSON initialization from MBXMapView down to MBXMapViewTileOverlay, and generally moving in the direction of removing some of the code which attempts to automate specific use cases. If you'd like to read up on that, and perhaps contribute some thoughts on what you'd like to see happen, I suggest you take a look at:

• The 0.2.0 and 0.3.0 milestones
• Issue https://github.com/mapbox/mbxmapkit/issues/36, "Reasons to reconsider async metadata loading design"
• Issue https://github.com/mapbox/mbxmapkit/issues/24, "Infinite failing TileJSON requests when app launches in airplane mode"
• Issue https://github.com/mapbox/mbxmapkit/issues/7, "add ability to toggle between overlay & Apple base"

[ghost]

I just checked up on how to set the mapID for an MBXMapView out of a storyboard. This is the example from the OS X demo app, but the same principle should apply on iOS (use an IBOutlet for your map view to set the mapID property):

@interface MBXAppDelegate ()
@property (nonatomic) IBOutlet MBXMapView *mapView;
@end

@implementation MBXAppDelegate
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
    self.mapView.mapID = @"examples.map-pgygbwdm";
}
@end

[newmanw]

First off let me say thanks for starting this project, and the quick response. I am writing a mobile app that will need to leverage online and offline maps so what you guys are starting seems perfect!

I will read up on 0.2.0 and 0.3.0. I can also try to help as much as possible, still a little green but hey I am going to use the lib so if I can help out in any way I would love to.

This type of functionality is exactly what I am looking for

• Issue #7, "add ability to toggle between overlay & Apple base"

Basically:

- (IBAction)setMapType:(UISegmentedControl *)sender {
    [_mapView removeOverlay:osmOverlay];

    switch (sender.selectedSegmentIndex) {
        case 0:
            [_mapView setMapType:MKMapTypeStandard];
            break;
        case 1:
            [_mapView setMapType:MKMapTypeSatellite];
            break;
        case 2:
            [_mapView setMapType:MKMapTypeHybrid];
            break;
        case 3:
            [_mapView addOverlay:osmOverlay level:MKOverlayLevelAboveLabels];
            break;
        default:
            break;
    }

}

I.E. why I was looking to just default to the apple map if no overlay is set. I could see how that might be different from what other people might want as well. But at least the capability to set some sort of behavior through storyboarding or the like.

Really looking for to this capability!!!

[ghost]

Okay, cool. I think I follow what you're up to. You might also have a look at the code for pull request #49, specifically at the tricks I used in toggleBetweenMapsDemo and toggle: to get a reference to the MBXMapViewTileOverlay layer and manipulate it.

One really useful thing you could do to help out is describe the use cases you have in mind. It can be pretty generic, but enough to get a sense of the general type of behavior you want your app to have with respect to changing layers around. Another thing that would be interesting is what you have in mind for working with markers (i.e. setting up markers on a mapbox.com map, adding your own which might only be displayed on top of an Apple map, or whatever).

[ghost]

If you decide you'd like to write up something about use cases, it would be cool if you could put that in a separate issue with "use case" or some such thing in the title. That way we could stick it in with the stuff for the 0.3.0 milestone.

[newmanw]

Markers is very next on my list of things. Ideally I would love to use one api to create my markers and have those markers overlayed on top of all map overlayers (apple, mapbox, osm, etc).

Saves me from having to create a bunch of MKMarkers to put on the map, then on toggle to MB map, I would have to create a bunch of MBMarkers.

I would lean towards some sort of MBMarker that 'extended' from MKMarker. Would be great to pull in some of the awesome stuff that was done in RM like clustering. Again just thoughts at this point.

[ghost]

Have you looked at all the marker code that we just committed yesterday? The current iOS sample app demonstrates how to add a marker manually in the view controller in addition to pulling in markers that you can edit as part of a map on mapbox.com.

[ghost]

@newmanw, it sounds like you have what you need, so I'll go ahead and close this now.

This type of functionality is exactly what I am looking for Issue #7, "add ability to toggle between overlay & Apple base"

[newmanw]

@wsnook agreed and thanks. This will come to light more when #7 is implemented. As such if you are toggling between apple and mbx, you may not want to add an empty mbx overlay by default.