Allow subview layering to be changed

[joe-trellick]

I wanted to change the layering of the subviews so that the second subview was behind the first subview (in my case, I have a UI element in the first subview that deliberately oversteps bounds for effect). However, simply sending the second subview to the back of contentView changed the iteration order during the layout process, causing the subviews to be visually reordered.

This change uses a mutable array to track the subview addition order distinctly from the layering order, and allows bringSubviewToFront: and sendSubviewToBack: to work as callers would expect.

[ole]

@joehughes I do see the need for this, but I am not sure your pull request is the way to go here. I definitely don't want to run into a situation where we slowly add a large part of the UIView public interface to this class. Perhaps it would be better to expose the contentView as a public readonly property so that users of the class could access the subviews that way?

[joe-trellick]

Fair enough; I was considering that approach, but I was debating whether exposing that implementation detail was as elegant as using the existing UIView API. (Because it might create a temptation to add/remove views from the contentView without the OLEContainerScrollView knowing.) However, if you're generally happy with the main approach of keeping the vertical ordering in an array that's distinct from the subview (layering) ordering, I'll change this PR to expose the contentView you suggest.

[ole]

@joehughes I apologize (again) for not replying earlier. Iʼm really sorry that I am managing this so badly. But I do have a plan now that I think should work well (and also be future-proof):

• Expose the contentView as a public readonly property.
• Go with your solution with regards of the subviewsInLayoutOrder array.
• Get rid of the addSubviewToContainer: and removeSubviewFromContainer: methods. Instead, users of the class can use the standard UIView APIs (addSubview:, removeFromSuperview, etc.) to add their views to the content view. Internally, we can implement didAddSubview: and willRemoveSubview: to monitor when views get added or removed and do the right thing. The downside is that contentView must be a custom UIView subclass to implement these methods, but thatʼs an implementation detail that does not have to be exposed to the outside?

What do you think? Will you make the contentView property public and remove the methods you added? Then I will merge the pull request and do the rest.

[joe-trellick]

Thanks @ole, I took a crack at the design you suggested (see the updated pull request). Now the exposed interface is just adding and removing views from the contentView directly. It's a little bit ugly internally because I put the UIView subclass in the same file to give it "protected" access to the now-renamed didAddSubviewToContainer: and willRemoveSubviewFromContainer: methods. If you'd prefer to have them in separate files with those methods exposed by a separate category header, let me know (I'm finding this an interesting exercise).

[ole]

Thanks @joehughes.