2

I'm having some inconsistencies modifying the Breadcrumb example, to have the CrumbPathView subclassed from MKOverlayPathView (like it's supposed to) rather than subclassed from MKOverlayView.

Trouble is, the docs are limited in stating the difference in how these 2 should be implemented. For a subclass of MKOverlayPathView it's advised to use:

- createPath
- applyStrokePropertiesToContext:atZoomScale:
- strokePath:inContext:

But is this in place of drawMapRect, or in addition to? It doesn't seem like much point if it's in addition to, because both would be used for similar implementations. But using it instead of drawMapRect, leaves the line choppy and broken.

Struggling to find any real world examples of subclassing MKOverlayPathView too...is there any point?

UPDATE - modified code from drawMapRect, to what should work:

- (void)createPath
{
    CrumbPath *crumbs = (CrumbPath *)(self.overlay);

    CGMutablePathRef newPath = [self createPathForPoints:crumbs.points
                                    pointCount:crumbs.pointCount];

    if (newPath != nil) {
        CGPathAddPath(newPath, NULL, self.path);        
        [self setPath:newPath];
    }

    CGPathRelease(newPath);
}


- (void)applyStrokePropertiesToContext:(CGContextRef)context atZoomScale:(MKZoomScale)zoomScale
{
    CGContextSetStrokeColorWithColor(context, [[UIColor greenColor] CGColor]);

    CGFloat lineWidth = MKRoadWidthAtZoomScale(zoomScale);
    CGContextSetLineWidth(context, lineWidth);

    CGContextSetLineJoin(context, kCGLineJoinRound);
    CGContextSetLineCap(context, kCGLineCapRound);
}


- (void)strokePath:(CGPathRef)path inContext:(CGContextRef)context
{
    CGContextAddPath(context, path);
    CGContextStrokePath(context);

    [self setPath:path];
}

This draws an initial line, but fails to continue the line...it doesn't add the path. I've confirmed that applyStrokePropertiesToContext and strokePath are getting called, upon every new location.

Here's a screenshot of the broken line that results (it draws for createPath, but not after that):

Breadcrumb example with createPath instead of drawMapRect

Here's a screenshot of the "choppy" path that happens when drawMapRect is included with createPath:

Broken map path

PostCodeism
  • 1,070
  • 1
  • 12
  • 20

1 Answers1

0

Without having seen more of your code I'm guessing, but here goes.

I suspect the path is being broken into segments, A->B, C->D, E->F rather than a path with points A,B,C,D, E and F. To be sure of that we'd need to see what is happening to self.overlay and whether it is being reset at any point.

In strokePath you set self.path to be the one that is being stroked. I doubt that is a good idea since the stroking could happen at any time just like viewForAnnotations.

As for the choppiness it may be a side effect or a poor bounds calculation on Apple's part. If your like ends near the boundary of a tile that Apple uses to cover the map it would probably only prompt the map to draw the one the line is within. But your stroke width extends into a neighbouring tile that hasn't been draw. I'm guessing again but you could test this out by moving the point that is just north of the W in "Queen St W" a fraction south, or by increasing the stroke width and see if the cut off line stays in the same place geographically.

Craig
  • 8,093
  • 8
  • 42
  • 74