Re: UIScrollView question
On Jul 26, 2014, at 22:19 , Luther Baker lutherba...@gmail.com wrote: Are you hoping that when the keyboard comes up -- it shortens the parent view you are referring to? No, it’s more complicated than that, but I think it’s the *question* that’s complicated, more than the answer. First you have to decide what you actually want to happen when the keyboard is up. You have 4 views, you said, 3 of which I assume are short (maybe about 1 line high each), and the last of which takes up the rest of the screen normally. So, when the text view becomes first responder and brings up the keyboard, do you want all of them to keep their original sizes, but just scroll what doesn’t fit off the top of the screen? Or do you want to have the top 3 views to keep their original sizes, and the text view to get smaller according to how much space is left by the keyboard? Or something else? If you don’t need to change the scroll view’s size (if “yes” to the first question — which I think is what you originally described as the goal), then setting the content and scroll indicator insets (along with scrolling the current insertion point onto the screen) ought to be all you need. You don’t actually need to resize anything. If you need to change the scroll view’s size, then any auto layout constraints *inside* the scroll view should keep your text view at a suitable size, and you shouldn’t need to muck about with the layout inside the scroll view manually. The problem then becomes one of getting the scroll view itself sized correctly. If the scroll view itself is subject to auto layout constraints relative to its own ancestors and siblings, I guess you’ll have to update its height-controlling constraint, *or* override its superview’s ‘layoutSubviews’ to set its frame directly after auto layout has had at it. If the scroll view is not subject to auto layout constraints, then you can just resize it directly. That’s a lot of if’s… ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UIScrollView question
Thanks Quincey, First of all, you've got a good idea of what I'm trying to do - so for my first question about how to make the text view fill the remaining space, I think you're of the mindset that I'll need to manually calculate that distance and set an internal height constraint on the text view. That answer then drives the answer to the second question about what to do when the keyboard comes up. In my case, I want to *both* scroll the view up *AND* shrink the text view's height (since the previously mentioned remaining space in the view is most likely not going to equal the area left above the keyboard). It sounds like you're leaning toward adjusting the internal height constraint on the text view. Now, I consider those manual calculations very similar to what I'd have to do were I laying the scroll view out via frames --- (overriding layoutSubviews, etc). And in that regard, I think that in this scenario, using frames would be slightly more literal for roughly the same amount of work for roughly the same calculations. ie: frames might be more readable and quickly grokkable later on. This technical note https://developer.apple.com/library/ios/technotes/tn2154/_index.html seems to imply that either approach is fine. My brief exploration here was to make sure there wasn't some OTHER way to setup AutoLayout for this scenario --- the scroll view is the wrench in this equation since it auto sizes its content view and consequently, cannot tell the text view how large to be. In this case, I really don't want the scroll view auto sizing its content view but I do want the scrolling animation and dismissal behavior. Seems like I'll need to create something manually then. Maybe a non scroll view parent, an affine transform and a pan gesture recognizer would simplify the layout sizing logic and get me closer to the behavior I want. In the end, I'm just looking for the simplest way to implement the resulting effect. Many thank! On Sun, Jul 27, 2014 at 1:12 AM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Jul 26, 2014, at 22:19 , Luther Baker lutherba...@gmail.com wrote: Are you hoping that when the keyboard comes up -- it shortens the parent view you are referring to? No, it’s more complicated than that, but I think it’s the *question* that’s complicated, more than the answer. First you have to decide what you actually want to happen when the keyboard is up. You have 4 views, you said, 3 of which I assume are short (maybe about 1 line high each), and the last of which takes up the rest of the screen normally. So, when the text view becomes first responder and brings up the keyboard, do you want all of them to keep their original sizes, but just scroll what doesn’t fit off the top of the screen? Or do you want to have the top 3 views to keep their original sizes, and the text view to get smaller according to how much space is left by the keyboard? Or something else? If you don’t need to change the scroll view’s size (if “yes” to the first question — which I think is what you originally described as the goal), then setting the content and scroll indicator insets (along with scrolling the current insertion point onto the screen) ought to be all you need. You don’t actually need to resize anything. If you need to change the scroll view’s size, then any auto layout constraints *inside* the scroll view should keep your text view at a suitable size, and you shouldn’t need to muck about with the layout inside the scroll view manually. The problem then becomes one of getting the scroll view itself sized correctly. If the scroll view itself is subject to auto layout constraints relative to its own ancestors and siblings, I guess you’ll have to update its height-controlling constraint, *or* override its superview’s ‘layoutSubviews’ to set its frame directly after auto layout has had at it. If the scroll view is not subject to auto layout constraints, then you can just resize it directly. That’s a lot of if’s… ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
UIScrollView question
I have a pretty good frames based background but I'd like to consider an iPhone screen done with AutoLayout on a UIScrollView such that the bottom UITextView grows vertically to fill the vertical space remaining from the text view to the bottom of the device. UIScrollView parent [Label] [TextField] [Label] [TextView] So basically, without calculating and then setting the height explicitly, how should the TextView be directed to vertically grow to fill the lower, visible part UIScrollView? Extra Credit: When the user taps into the UITextView, the - keyboard comes up (free) - the scroll view offset programmatically scrolls up = keyboard height (keyboard notifications) - the text view grows/shrinks to perfectly fill the area between the keyboard top and the navigationbar bottom - remember, this has to work on iPhone4 and 5. I'm not sure how to manage that last step without digging in and getting/setting some direct frame calculations which leads me to wonder if, in this case, using AutoLayout would be like pushing a square peg into a round hole. Thanks in advance for any input, -Luther If it isn't already clear, the scroll view isn't really a key player until the user actually taps into the text view in which case it simply tries to bring the text view into focus while still allowing someone to, while in the focus state, either scroll back up to the top text field and enter text there or scroll to simply resign any existing focus. Better ideas ... or different perspectives are welcome. I could imagine affine changes or gesture recognizer based solutions for this effect before but was thinking that leveraging the scroll view would be a natural. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UIScrollView question
On Jul 26, 2014, at 20:58 , Luther Baker lutherba...@gmail.com wrote: I have a pretty good frames based background but I'd like to consider an iPhone screen done with AutoLayout on a UIScrollView such that the bottom UITextView grows vertically to fill the vertical space remaining from the text view to the bottom of the device. UIScrollView parent [Label] [TextField] [Label] [TextView] So basically, without calculating and then setting the height explicitly, how should the TextView be directed to vertically grow to fill the lower, visible part UIScrollView? Isn’t the answer to this here: https://developer.apple.com/library/ios/documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/KeyboardManagement/KeyboardManagement.html (especially the code fragment at the end)? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UIScrollView question
On Jul 26, 2014, at 21:09 , Quincey Morris quinceymor...@rivergatesoftware.com wrote: Isn’t the answer to this … Sorry, I quoted the wrong thing. I meant, isn’t the answer to the stuff about the keyboard in that documentation? Is the scroll view there only to deal with the case of the keyboard appearing? In that case, won’t a “bottom space to superview” constraint do the right thing, or (if scroll views are one of those cases where the obvious thing doesn’t work) can’t you add a height constraint to the text view at viewWillAppear time? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UIScrollView question
Yep - I'm good with the keyboard part (ie: I can tell how much of the screen will disappear) ... won’t a “bottom space to superview” Are you hoping that when the keyboard comes up -- it shortens the parent view you are referring to? To date, that has not been my experience. The keyboard just shows up on top of all the children views. If I went that route I think I'd still have to calculate the change and set a new height constraint ... which is getting into framesy land (which is OK, but not why I'm explicitly trying to explore). Also, in viewWillAppear, how shall I determine how large to make the text view? Are you thinking get the height of the parent view and then subtract the heights of all the children views and then set that constraint on the text view? If so, that feels like frames code dressed up in AutoLayout clothing. Thanks, -Luther On Sat, Jul 26, 2014 at 11:17 PM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Jul 26, 2014, at 21:09 , Quincey Morris quinceymor...@rivergatesoftware.com wrote: Isn’t the answer to this … Sorry, I quoted the wrong thing. I meant, isn’t the answer to the stuff about the keyboard in that documentation? Is the scroll view there only to deal with the case of the keyboard appearing? In that case, won’t a “bottom space to superview” constraint do the right thing, or (if scroll views are one of those cases where the obvious thing doesn’t work) can’t you add a height constraint to the text view at viewWillAppear time? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
