I am curious if it is possible to configure collection view items to have variable/dynamic sizes from right inside storyboard?
With the introduction of adaptive layouts and the storyboard preview mode, it seems counterintuitive to me that we should be restricted to hardcoding collection view item sizes. It also makes it a little more challenging to use the preview mode to debug your constraints.
See the below screenshot for an example. In the screenshot I have a collection view displayed on 3 different phone sizes. In my case I want each collection view item to be the entire size of the screen. I've set the collection view background to red and the background of the first cell to be blue (the second one has a white background). My collection view has constraints that pin it to the borders of the screen and you can see that it scales properly. However, my collection view items remain the size that they were hardcoded in storyboard (320 x 600).
I can manually increase the cell size to match iPhone 6's screen and you can see that my constraints within the collection view scale nicely but now the preview mode looks messed up for the 4in and 5.5in sizes:
FYI I know how to adjust collection view item sizes programmatically using the UICollectionViewDelegateFlowLayout and I am also aware of the super awesome new estimatedItemSize property for adaptive layouts so if necessary I can do this in code. The issue I am trying to solve is that you cannot simultaneously preview a collection view in storyboard for more than just one size.
In my dream world I could attach constraints to the size of a collection view item...can it become reality?
Related
If a Table View Controller is created using Interface Builder, on iPhone X the lowest visible cell will be obscured by the home screen indicator, and the cell's corners clipped by the curved screen, by default - see screenshot below.
If I use a View Controller and insert a Table View, then set it up by hand, I can use the bottom layout guide with the table view, to ensure this obscuring and clipping behavior doesn't happen, i.e., by not allowing the table view to extend into the curved part of the screen.
I'm upgrading a few legacy apps, and I'd prefer not to have to convert the existing Table View Controllers into View Controllers if possible. How can I make Table View Controllers created with Interface Builder behave?
According to the Apple docs, by using the standard interface elements this shouldn't be a problem.
Inset essential content to prevent clipping. In general, content
should be centered and symmetrically inset so it looks great in any
orientation and isn't clipped by corners or the device's sensor
housing, or obscured by the indicator for accessing the Home screen.
For best results, use standard, system-provided interface elements and
Auto Layout to construct your interface. All apps should adhere to the
safe area and layout margins defined by UIKit, which ensure
appropriate insetting based on the device and context.
If you enabled automaticallyAdjustsScrollViewInsets, table view will be upon home indicator when you scroll to bottom. I think this is what Apple wants, take advantage of the full screen at the same time every elements can be interacted.
If you want cells never obscured or clipped in UITableViewController. I suggest you use plain style table view, set contentInset to make section footer hovered under home indicator. I tried this, It worked but looked ugly. Like this:
In the end, I converted the Table View Controllers into View Controllers and added a bottom alignment constraint to the Table View
I used to be able to do this:
UIButton *bigBottomBtn=[[UIButton alloc]initWithFrame:CGRectMake(0, self.view.frame.size.height-60, self.view.frame.size.width, 60)];
I also used to be able to just drag a button onto a storyboard and add a constraint that would hold it to the bottom of the parent.
What is going on with Xcode, Autolayout and Apple for that matter....is my Xcode not working properly? Have I missed a major memo? is Apple just going downhill fast?
Your button-creating code used to work (and still does) if self.view's frame was correct at the time you created the button. Note that the view doesn't necessarily come out of the xib or storyboard with the correct frame; the xib/storyboard contains the view at some design size which might not match the current device. This wasn't as much of a problem when all iPhones had 3.5 inch screens, but became a pretty common problem with the advent of the iPhone 5's 4 inch screen.
The view isn't guaranteed to have its correct frame until its superview's layoutSubviews returns, so if for example you're creating bigBottomBtn in viewDidLoad, that's too early. Many questions on stackoverflow cover this problem. You either need to set the autoresizingMask of the button, or implement layoutSubviews or viewDidLayoutSubviews to update the button's frame, or turn off translatesAutoresizingMaskIntoConstraints and install constraints. Note too that your view can change size if you support rotation, slide over or split view multitasking, or if your view can be the detail view of a UISplitViewController, so it's a bad idea to try to guess the correct frame of the button based on the device's screen size at the moment the button is created.
Note that storyboards now by default use a design size of 600x600, which isn't the size of any device. This is probably because if Apple chose some device's size (say, the iPhone 5's 320x568) as the default, and you happened to use a device of that size as your primary (or only) test device, you could easily forget to think about what your app will look like at other sizes. However, you can explicitly set the design size to some device's size if you want:
I usually use “iPhone 3.5-inch” if I don't specifically need something bigger, because it lets me get the most scenes on the screen simultaneously (and produces the smallest screen shots for stackoverflow).
As for “I also used to be able to just drag a button onto a storyboard and add a constraint that would hold it to the bottom of the parent”, I have good news: you still can. Example:
However, you do need to be careful if you have filled your root view with a table view as appears to be the case in your screen shots. You need to drag the button to the document outline in that case, because if you drop it on the table view, Xcode will assume you want it to be the table view header:
Trying to pin a table view header to the bottom of the screen would be folly.
As for the Editor > Align menu, I have found that the items can be mysteriously inactive, which is frustrating.
Note, though, that only the “Horizontally in Container” and “Vertically in Container” will work (when they work at all) with a single view selected. To use the other items in the menu, you need to have at least two views selected, because the other items align the selected views with each other by setting their frames:
If you only have one view selected, Xcode doesn't know what other view you might want to align it to.
Those menu items are perhaps useful in the springs'n'struts model, but they don't add constraints, and under autolayout you probably want constraints to enforce the alignment at run time.
As far as I know, those menu items have never added constraints, but I'm not going to reinstall Xcode 6 to verify that, because there's a convenient popover that will add constraints corresponding to all of those menu items:
In xcode you always need to add buttons according to its visibility. As you said you need to show button on top of tableView and it should be aligned to bottom. For that You just need to arrange the order of items. as shown in the image below.Provide the layout for the button.
I am designing a table view in which I have a custom cell in which I am trying to design a few views and sub views. I have placed my views as per the following hierarchy and constraints -
And here is my main story board -
I have given my table view cell's content view as orange colour and I have placed a view with yellow colour. I have pinged it to the content view of the cell. My storyboard is of the size 600*600 freeform(Size class - wAny hAny). When I run my app in ipad, it keeps a space as shown below between the cell's content view and its subview even on pinning the subview to all sides of content view-
So,what might be my problem and what mistake am I making? Thanks.
I think the problem is because of the sizing classes (like in the image).
if your app is universal (for both iPhone and iPad) make sure you choose it like the screenshot (w Any, h Any).
Please let me know the current settings.
Update
After sending me the storyboard. I have used it as it is in a new project. and that's how it looks in both iPhone and iPad
It looks fine in both of them. my best guess is it's a problem of the
preview only(which doesn't matter).
If you change the scene size from iPhone 4 inch to inferred
it solve the problem in the preview as well.
I have tried for several hours to design and place the different elements accordingly. But it seems like no matter what I do, the elements get messed up with sizes and location when moving to different device (screen sizes).
How would you place constraints in the screen below to ensure proper scaling and position when moving to a different device?
http://postimg.org/image/hl4incjzh/
I only work in portait mode.
The views at the left is a UIImage view and a UIWebview which is hidden, and will show dynamically based on external content.
Label and the textview below is also dynamically populated on ViewDidLoad.
Any ideas, suggestions?
You can click on a view element and use the add-constraints-menu:
There you can set different size-options like the margin, if the view should resize etc.
I have a problem adapting my apps to the new iphone5 layout, I've made the following passes:
Added a retina 4" splash image
Modified the interface in my storyboard with "Size inspector" to change the anchoring of the widgets
Tested the app with iOS6 "retina 4" simulator.
The app works as expected except when the user pop up the keyboard to edit a text, I use the "stretching scrollview" method for this particular situation and this seems not compatibile with the "autosizing" properties of my widgets, here is an example, from iOS6 simulator, without and with keyboard:
And here is what happens:
I'm quite sure this is a coherent behaviour since my main view is stretched so the other items inside it are stretched following their anchoring, the fact is that I'd like to have the same behaviour of my previous fixed position (all widgets anchored to the top left corner) with the iphone5 gui expansion, is this possibile?
How do you solve the problem of showing a keyboard and scroll hidden content in an iphone 5 compatible way?
I have been having similar problems. From what I have found thus far, we may need to remove all constraints on the view within the scrollable view, because it appears that it's contents are being resized along with the frame of the scrollView. I know that setting the internal view's frame manually in viewWillAppear will work, but then you are stuck having a view that is the same size for both iPhone4 and iPhone5 (albeit it will scroll). Or you could "pin height and pin width" of the internalView right there in storyboard.
Two potential approaches that may work. Sorry I can't confirm these as I'm giving up and redesigning around this problem.
1. Programmatically add constraints to your internal view's subviews. The programmatic constraints will allow you to "spring" the distance between your elements proportionally. When adding constraints programmatically, you are given access to a factor called "multiplier" (not to be confused with priority), which I saw someone else on stackoverflow posting about.
2. You can design the internalView in Interface Builder as a separate viewController with it's .xib file, and then use storyboard to load it as an embedded viewController to a "containerView" object, which you would put in place as the new "internal view" of the scrollView. Perhaps then the .xib would first resize to the correct iOS device, and then you could use its frame to resize the containerView.
My advice is create a small test-case of these before implementing, else you end up like me, having spent hours down the wrong path and facing a dead-end.
UPDATE 12/4/12
Make your life easier by NOT setting the ScrollView as the main view of the ViewController.
--Instead, make ViewController.view a dummy/blank view, and embed a scrollView inside that view. Then, embed another view (my CustomView) in the ScrollView. CustomView contains all the visible controls and text boxes and buttons. There is NO HEIGHT CONSTRAINT on CustomView.