contentView should be resized to fit within callout view

[MarkCSmith]

We are using a variable width contentView (sized to fit text labels and other content). When SMCalloutView resizes itself to fit within the parent view (e.g., MKMapKit), it should resize the contentView as well. Here is a patch for the private presentCalloutFromRect method that adjusts the contentView's width to fit (we did not try to use a dynamic height):

@@ -220,16 +220,25 @@ NSTimeInterval kSMCalloutViewRepositionDelayForUIScrollView = 1.0/3.0;
     [self rebuildSubviews];

     // apply title/subtitle (if present
     titleLabel.text = self.title;
     subtitleLabel.text = self.subtitle;

     // size the callout to fit the width constraint as best as possible
     self.$size = [self sizeThatFits:CGSizeMake(constrainedRect.size.width, self.calloutHeight)];
+   
+   // If we have a contentView, resize it to fit within the callout.
+   if (self.contentView)
+   {
+       CGFloat margin = self.innerContentMarginLeft + self.innerContentMarginRight;
+       CGRect r = self.contentView.frame;
+       r.size.width = self.$size.width - margin;
+       self.contentView.frame = r;
+   }

     // how much room do we have in the constraint box, both above and below our target rect?
     CGFloat topSpace = CGRectGetMinY(rect) - CGRectGetMinY(constrainedRect);
     CGFloat bottomSpace = CGRectGetMaxY(constrainedRect) - CGRectGetMaxY(rect);

     // we prefer to point our arrow down.
     SMCalloutArrowDirection bestDirection = SMCalloutArrowDirectionDown;

[nfarina]

Hello (many months later, sorry!). So the callout is designed to size itself to fit the content view if defined. That's pretty ingrained into the structure of the callout. I'm sure you found a solution or workaround by now, but I'd be curious to hear why you'd want your content view to be resized for you?

[MarkCSmith]

Sorry for the delayed response. The problem is that if the content is too wide to fit within the container view (as specified by constrainedToView in presentCalloutFromRect:...), then SMCalloutView resizes the callout to fit within the container view. When this happens, the content view needs to be resized as well.

[nfarina]

Interesting - so you're presenting a callout containing content that is too large to fit inside the constrainedToView without scrolling?

[MarkCSmith]

Yes, our content may be quite wide. For example, in our Clue Tracker app we use SMCalloutView to show custom callouts for letterboxes (which are similar to geocaches). The letterboxes have names, which are sometimes quite long. We don't actually allow scrolling inside the callout content view, but we do shrink font sizes and truncate labels if necessary. I think the iOS Maps app just constrains the content view to a fixed, maximum width which is guaranteed to fit on a 320 unit wide screen. But that means that long place names are truncated.

[nfarina]

Oh I think I finally see what you meant in your original comment - you're saying that you supply SMCalloutView with a particular contentView, which turns out to make the callout too large, so the callout shrinks itself, which then causes the contentView to - overflow the callout probably? So you're saying it would be nice if the contentView in this situation was resized to fit the newly-smaller size.

The only reason I'd be hesitant to do that would be that SMCalloutView uses contentView.frame.size as a "signal" to determine what the contentView's "desired" size is. If it then goes and changes the contentView size, then it's destroying that signal.

Perhaps you could simply resize the contentView yourself according to the constrained view when necessary?