Use scrolling UITextView for captions

[cdzombak]

closes #45

Still todo

• Fix shadow view position: layer's bounds after last -layoutSubviews call to the caption view have the wrong height. This applies to iOS 8 only.
• Resolve Auto Layout warnings printed on presentation. This applies to iOS 9 only.
• Consider pinning the text view to full width and using contentInset or textContainerInset instead of horizontal padding.

[cdzombak]

See if we can allow panning the page VC left/right over a scrolling caption view.

This is going to require more though to complete in a clean way, keeping the rest of the library away from knowing about caption views (since they're replaceable).

[grantjbutler]

Should this be [self.captionView conformsToProtocol:@protocol(NYTPhotoCaptionViewLayoutWidthHinting)]?

[cdzombak]

I'm not sure. Here are some arguments for and against changing to conformsToProtocol:

for

• the current code carries implicit knowledge of what's in the NYTPhotoCaptionViewLayoutWidthHinting protocol, spilled across 2 lines (though a change to the protocol would still cause a compiler warning)
• we should check exactly what we're casting to, before casting

against

• what we really care about is whether we can set preferredMaxLayoutWidth, and with this approach certain classes (UILabel) get correct behavior for free. (the cast is practically a detail to satisfy the compiler, though a change to the protocol would still cause a compiler warning)
• conformsToProtocol: requires a global runtime lock; respondsToSelector: does not
• even if we check that it conforms to the protocol, the code still carries implicit knowledge about what methods are in the protocol because we still have to cast before sending the message

[grantjbutler]

I asked because I assumed that was the point of adding the protocol in the first place. If you're just interested in the caption view responding to setPreferredMaxLayoutWidth:, what's the point of the protocol? You could just as easily cast to id and use the method, not the property, to silence any compiler warnings.

[cdzombak]

If you're just interested in the caption view responding to setPreferredMaxLayoutWidth:, what's the point of the protocol?

So that I have something to cast to on the next line: (id<NYTPhotoCaptionViewLayoutWidthHinting>)

[grantjbutler]

I updated my comment with this line after you posted yours:

You could just as easily cast to id and use the method, not the property, to silence any compiler warnings.

[cdzombak]

That's really the best answer for "why check respondsToSelector: instead of conformsToProtocol:?" Just that the former requires the runtime lock while doing 60fps UI work.

[grantjbutler]

Whereas respondsToSelector: doesn't lock anything:

respondsToSelector: itself doesn't lock anything, but lookUpImpOrForward (which is called by lookUpImpOrNil) does get a runtime lock.

[cdzombak]

respondsToSelector: itself doesn't lock anything, but lookUpImpOrForward (which is called by lookUpImpOrNil) does get a runtime lock.

well, I'll be! the comment on that function doesn't include a note about locking…I guess I should send a PR :)

[grantjbutler]

That said, would something like that be considered an implementation detail if it's not mentioned in any documentation apart from the source code?

[cdzombak]

This is all implementation detail! And I think I am sufficiently convinced not to micro-optimize this for now (though I suspect that this cache lookup will almost always succeed); see 162e0ba

[steve-matthews]

just curious as to why not just make these static ints an enum.

[cdzombak]

¯_(ツ)_/¯ they were static ints before, and slowly we've added a few more special cases.

[cdzombak]

I've resolved merge conflicts in 5d1a27d

[cdzombak]

I've resolved merge conflicts in 0cd6a1e

[cdzombak]

✨