I have a loadView call that basically places one view at the top (like a header) and one at the bottom (like a footer). It's possible via a passed in parameter to not have a header or a footer, to hide them later, or to resize the view. I have all this working, but it's very susceptible to breaking because the views can go in various places of various sizes and all must be manually set to the correct size or they will not use up all the space. I want one in between the two of them that automatically resizes to fill whatever space is not taken by the others.
loadView doesn't seem to be able to obtain the size of its parent's frame (or where it's being fit in, exactly), nor do I see an obvious way to just put the center view at a certain position and have its width and height automatically adapted.
Any ideas?
If I'm not explaining myself well enough and you know Java Swing, think BorderLayout with a BorderLayout.NORTH, BorderLayout.SOUTH, and BorderLayout.CENTER component.
loadView isn't a good place for this. You really want to use viewWillAppear instead. Setting autoresizeMask to have fixed borders should do what you want without having to worry about calculating layout, and it's best to do this all in IB rather than doing manual layout all the time.
Related
Is it possible to set height of super view relying on summarized height and padding between its child elements using auto layout?
Basically I'm trying to fill subviews with text from remote server, views are changing height dynamically, but their superview (or container view in other words) is static.
See -intrinsicContentSize and -invalidateIntrinsicContentSize. I believe this alone will get you there in simple cases. As I understand it, other things (including superviews with constrained distance from edges of a subview) will be moved to accommodate a view that claims a minimum size that would break those other constraints (keeping your view visible, for example).
I'd love it if others would chime in to validate/invalidate/correct me here. I'm still wrapping my own head around the many details specific to Autolayout in practice.
For a simple example lets say I have a UITextView with a Button underneath it. These two controls are siblings both embedded in a parent UIView.
I now change the text within the UITextView and resize it accordingly. Is there a way to make the button automatically move to have the same relative distance to the bottom of the UITextView? This may seem trivial for this case, but I will have a longer hierarchy with multiple UITextViews that change and it would be nice not to have to calculate the height of every object manually.
One way to approach this would be with a table view: if you place each of your text views within its own table view cell, the table view will automatically calculate its total height from individual calls to its delegate’s -tableView:heightForRowAtIndexPath: method and lay itself out accordingly. Whenever the height of one of your text views needs to change, you can call -reloadData on the table view to make it lay itself out again. A disadvantage of this approach is that it’s really difficult to animate the height changes; if that’s essential to the effect you’re going for, I’m afraid you’re stuck with doing the entire layout manually.
Try the autoresizingMask property of UIView.
All I see is a list (which looks like a rolodex), how do I make this like the combo box option?
I haven't tried this, so I can't say that it will 100% work, but ths is what I would attempt to do:
Extend UIPickerView and initially give it only enough height for one row
In the new class, intercept touchesBegan: so that if the control is in the 1 row mode it will first expand to the full height (using an animation of course). I would probably NOT pass touches on to the super class in this mode
If the control is already in the full height mode, let the touch pass on through to the super class.
Add some other communication with other components on the screen so that when the user touches them, the extended UIPickerView shrinks back to it's 1 line height form, with more animation.
To make all of that work you probably need all your controls in a scroll view that does proper auto layout so that as you change the frame size of the UIPickerView thingie the other controls move around appropriately.
I agree with Henrik that this is very non-Apple however. It seems the prescribed Apple implementation would involve a tableview cell with a disclosure button that takes you to another screen containing the picker. I know the Apple HUI guidelines don't cover all cases, but it seems they probably cover this one.
I have a view (UIScrollView), which loads some data, and displays various things from it in various subviews. So I have approx 10 subviews (UIImageView, UILabel) and I need to place them programatically considering their unpredictable contents (i.e. different height/width for the UILabels depending on the text property).
From what I've read, there is no layout framework for Cocoa-touch.
What is the best way to do this?
From what I can tell, I should put the contents in the views, then start calculating coordinates based on their frames after calling their sizeToFit methods.
This approach is very error-prone. Is there really no other way?
You are right, there are no automatic layout managers. Subclassing UIScrollView and overriding layoutSubviews is probably the right way to implement your custom algorithm. You can then call setNeedsLayout to do the layout.
Layout in Cocoa is typically done with auto-resizing (using autoresizingMask). You start with your view at some hard-coded initial size, say 200x200; place your subviews onto this view and set the autoresizing flags accordingly. This view is then free to be resized to its actual size, as determined by its parent view/window. The process is the same whether you use Interface Builder or whether you do it programmatically.
If you need a vertical stack of views you can use a table view.
If you want more complicated layout you need to implement it yourself, by overriding layoutSubviews.
I'm not aware of any automatic layout managers or the like.
So, I think you'll have to calculate the desired positions and sizes and update the frames of your subviews manually.
EDIT: I found this question where Brad Larson points to an example of a custom layout manager. HTH
You can use Interface Builder to create a view and then drag and drop elements into it.
I have a problem, I can't solve properly.
In short: I want to create a single view (say: UIImageView) out of multiple subviews - i.e. it consists out of multiple ImageViews and TextViews. The thing is, I want to sort of 'render' them to be a single View.
Say, I take an image, add some description below, add a title above, and maybe another little image at the bottom. I want this whole thing to be a single UIImage to make it sort of 'listen' to one (e.g.) swiping gesture, which I cant tell to bring the new image to display.
Does anyone know the best way to achieve this? So far my results were fairly poor.
Any hints are welcome!
This is definitely possible. You seem to know about views and subviews, but should also read up on the "UIResponder" class and the "responder chain". The master view that you want to contain them all won't be a UIImageView, though, because that exists to just show an image. You can make all the ones you talk about subviews (addSubview: or in Interface Builder) of a plain UIView that you subclass yourself (say, MyContainerView), which then itself handles the gestures. If you want to take advantage of free scrolling on swipe, you could instead put your container view into a UIScrollView, which has its own set of semantics that you can leverage. For this latter, you should check out Apple's sample code for scroll views (don't have a link handy but should be easy to find) which embeds multiple image views in a scroll view.