grgcombs
commented
13 years ago Yep, here's what's happening....
I can successfully resize my example table view frame (with=700.f for example), however, because CLCascadeView assumes any pushed views will have the same width as it's stored pageWidth, the stacking offsets are wrong and much of the content of the wider table view is off screen and won't bounce or snap to show the full view upon dragging.
Sure, I could go in and set the cascade view's pageWidth property to 700.f, but that means any other view controllers I push will need to have that width too.
This seems awfully limiting to me. Many times I need to push a new view controller onto the cascading page stack, and the new view controller has different width requirements. In the context of a UISplitViewController, my initial view is the master table view and it's typically set at 320.f pixels iPad devices (same on iPhones too, in a tab bar though). However, any subsequent selections in that table will result pushing various other view controllers with different widths than it's parent ... The initial master view might be a simple list of names (320.f wide) , the newly pushed "detail" might be 650 wide, (or 500, 700, etc) on iPad, depending on the context (an in-app web browser, a twitter feed, another table view of addresses, etc).
To me, it seems like it makes more sense to first check to see if the incoming view controller has a frame size preference before making assumptions about the new view's width. As for the sliding, bouncing, and snapping animations, they would also need to make adjustments based on the alternate size ... if a new view is supposed to be 700px wide, and you're in portrait orientation, it would need to allow the user to snap that view further to the left to view the whole 700 pixels at a time, perhaps leaving only the icon exposed in the CLSplitCascadeViewController. Then, if they want to slide that back to the right to see the parent views underneath, then they can do so.
Does this make any sense? I'll include some screenshots of my vision below ... It's hard to tell because it's not animated, but it might give a better indication of the variable widths I'm referring to...
emilwojtaszek
Am I correct in deducing that the framework assumes each of the pushed cascade views will have the same frame/bounds width? Playing around with the new example, I'm trying to get the table view to push with semi-random widths, to test the drawing and hit testing, but I must be doing it wrong (or setting it in the wrong place). I thought I'd post this question to seek some clarification on page view widths.