Whenever I get a conflict in a storyboard file, I can usually resolve it. However, I have an issue that has now come up twice in two weeks.
At the very bottom of my Storyboard file, I see block named "inferredMetricsTieBreakers", with bunch of "segue" tags contained within. It seems that some segue in my local repo is conflicted with another segue in the remote repo. To be safe, I could just "choose both". But since this happened once before, I'm afraid that it will keep happening, and eventually have a long list of these segue references at the end of my storyboard file.
Just wondering if anyone is that intimately knowledgeable about these tags in the file, or whether I should just blindly continue to just "choose both" and ignore the issue.
Thanks,
-Dan.
Each view controller in a storyboard has "Simulated Metrics" which you can see in the attributes inspector:
Some of these metrics are inferred (thus, inferred metrics).
As mentioned by #thesystem, if a given view controller is the destination of multiple segues, there could be differences between the simulated metrics of the source view controllers of the segues. To address these differences IB picks a segue to break the tie when resolving the inferred metrics for the destination view controller.
#rick-pastoor's conclusion that it's safe to remove the entire inferredMetricsTieBreakers section is correct in that IB can just choose different tie-breaking segues. However, there is no guarantee that the new tie-breakers will lead to the same layout results in IB.*
For example, I had a situation in which, depending on the tie-breaking segue, a view controller was shown in IB either with or without a status bar. Its view maintained a height of 568pts in both cases, such that the position of the top layout guide kept changing. This snowballed into other undesired (and largely meaningless) changes to the frames of views constrained to the top layout guide.
Based on these observations, choosing both the new and old sets of inferred metrics is not advisable. Instead, remove both sets and then open the storyboard in IB to allow the ties to be broken before committing the merge. To avoid undesired frame changes due to a change in tie-breaking segue, pick some value other than "Inferred" for the relevant simulated metrics of the destination view controller. This will ensure that IB generates a consistent layout result.
* The results at runtime should be the same unless there is any logic that relies on the initial layout immediately after the view is unarchived.
Same thing going on here. Got errors in my storyboard file after using your "choose both" method. Found that searching the storyboard for the segue references resulted in one segue that was mentioned inside the inferredMetricsTieBreakers section. Removing the segue from the list solved my breaking build.
To try and find out what this inferredMetricsTieBreakers does, I tried removing the whole section first. Breaking my build. Next I removed all the items. During the build, Xcode added 2 new and different segues to my list (before the merge I had 3). The application I'm building is working fine.
My conclusion: it's safe to remove all the items and perform a clean build. This will keep your storyboard clean.
It looks like, the tie breakers occur when in the storyboard one view controller is connected from two or more other view controllers via segues and its simulated metrics setting is set to "inferred" but Xcode cannot make sure that inferred means exactly one metrics setting (landscape or portrait) in every case.
I fixed it by changing all controllers simulated metrics to "inferred" and all metrics are inferred from a controller that has fixed simulated metrics setting "landscape". After that I removed the tie breaker segue ids from the section (but not the section itself).
Changed the metrics from Inferred to Freeform (Xcode 8, Swift 3). Solved my problem.
Related
Recently, I encountered a problem with the Interface Builder which I failed to solve. I'm using a UICollectionViewController and whenever I add a Cell it immediately shows a orange rectangle (indicating a auto-layout update). Updating the frame/cell doesn't change anything. The warning associated with the orange marking reads "Expected: height=Y, Actual: height=X" where Y is always exactly X-100. That is: When I set a custom cell height of 193, it says "Expected: height=93". This happens no matter which size I enter.
The problem with this is that I have many difficulties with the subviews and their constraints. For instance, if I add a subview with the constraint to keep the same height as the cell, it will be shown as 93 (the expected height), even though my cell should be 193. Layouting becomes impossible.
I tried adding a new cell, same issue. I tried removing every subview and re-adding them, nothing.
Any ideas are highly welcome.
Thank you very much!
Solution found ! (Xcode 9.2)
The bug seems to only happen when you try to embed the UICollectionViewController in a Container View in the storyboard. The workaround is to remove the segue while you set your constraints, and re-add the segue once your constraints are well set.
I also think that setting UICollectionViewController size as Freeform could be responsible of the bug. If so, try to set constraints before changing the size.
Hope this helps !
I'm not sure if this solved it, but the warning and issue disappeared once I did the following:
Select the CollectionViewController in Interface Builder and set the size to freeform and make the height larger, large enough to show all your template cells. (Plus: maybe refresh the views). That solved the issue for me.
In my case, I have added two collection view cell, withing collection view Controller.Only setting the view controller to free form wont help us. Need to update the size, to get rid of the warning.
updating collection view cell frames, wont help us. Warning will be continuously changing its length.
I tried to work without considering the warning, as I have set my collection view cell size programmatically and it does working as expected.
I think it's just a strange bug
I delete the collectionViewController in SB, then create a new one, the problem disappear
This is a common bug with Interface Builder. I don't know the exact cause, but I believe it's something to do with placing collection views inside arrangement views that do not have an exact size. I've seen it when putting them in scroll views, stack views and container views.
There is a simple fix, although I believe this to be a bug in IB that ought to be corrected by Apple rather than hacking around it. The solution (for me at least - your mileage may vary!) is to place the collection view inside an ordinary UIView and pin its edges to it, then place that parent view in the position that you wanted your collection view with all the constraints it required.
I usually found that there were actually no auto layout issues at run-time, which is why I believe this to be purely an Interface Builder bug.
In order to explain what problem I am having I will quickly explain the scenario. I have a synthesizer I am building that has several "control views". One control view may be 4 vertical sliders while another is one big matrix or something.. So, say I have control views 1-4. In addition, I have two main sections (which are just holder views), which can contain one of the 4 control views. At any given moment, sectionA can have controlView4 while sectionB can have controlView2. This works perfectly.
The problem with this is SectionA cannot have ControlView1 while SectionB has ControlView1 simultaneously. This leads to undesirable behavior. For example, if SectionA currently has ControlView1 while SectionB has ControlView4 (which will wrap around to ControlView1 on the next toggle), than the next time I toggle SectionB's active ControlView, SectionA's ControlView will simply disappear. (presumably because UIKit implicitly removes it from SectionA's subviews when I add it as a SectionB's subview.)
So, there is some default behavior of UIView that isn't ideal for this modular scheme I wish to implement. That being said, is there a way to achieve what I want without deviating to far afield from iOS best practices and sane code design?
First, I would want to have a different type of view controller for each type of view. Then, each time I wanted a view in a section, I would create its matching controller and have it take over that container area. If the four sections are then displaying multiple copies of the same view, they each have their own controller to keep them organized.
Assuming you have your data model separate from your views and controllers, there should be no extra complexity.
I can't see items that add to my ViewController before like buttons but it shows in simulator and I tried to Select Identity Inspector of view and set Lock to Nothing but does not changing , How can I solve that ?
This quote from another post by matt could be helpful:
"It looks to me like you are using size class and you went into a particular size class and added these views. Now you are back in Any size class, so the views are not there (that is why they are greyed out in the document outline at the left). They are available only for that particular size class. If you switch back to it again, whatever it was, you will see them again. Basically, you have created conditional views - the condition being that they are present only when that particular size class situation is the case.
In other words, if you want your layout to apply in the general case, you want to start by creating and editing it under Any size classes. Only then do you switch to a particular size class and modify the layout for that particular size class.
when i run my app all ui element visible in my device
Yes, because on your device the particular size class situation matches the size class you were editing when you added those views. So there they are. That seems to me to prove my guess is right."
link is: why storyboard ui elements not showing on UIViewController in xcode 6?
I'm trying to get the split view controller working properly but apparently there's a bug in there or I'm missing something.
First of all, I've started a blank OSX Obj-C application, and in the Storyboard I've dragged the split view controller. Next, I've linked the segues from the main window controller to the split view and added two labels.
http://i.imgur.com/dlFObaF.png
When I build the project, it shows only the second page. Not to mention strange window size in the final build.
http://i.stack.imgur.com/IqRqr.png
I've tried everything.
This occurs in both vertical and horizontal split view.
Any suggestions?
I had the same issue myself today, but it's just the split line wasn't initiated properly.
To see, this, once you run your app, move your mouse toward the edge of the window and drag it, you will now see another view emerging.
To my best knowledge, I do not know how to fix this in IB or in code. Apparently NSSplitViewController does not have a property like UISplitViewControllerAutomaticDimension. Would appreciate if someone can contribute to this.
Edited: Found an answer via another thread. Basically, try to add some constraints to the subviews inside each view and that should prevent the size of a view to be zero. In my toy example, adding margin constraints to my buttons worked out well.
I've got a button in a toolbar that I'd like to use to control the state (expanded/collapsed) of the right-hand-side split of a split-view. In a xib-based project this is trivial, but I'm using storyboards, and can't work out what the best approach is.
The key limitation is the fact that I'm not able to create target-action connections between objects in different scenes. As I see it, this leaves me with three options:
Have the window controller handle the expand/collapse request - this seems inappropriate - what's the window controller got to do with the state of the split view?
Have the window 'collect' the action and refer it on to the split-view controller for processing - this is better but to me it still seems like bad design to have the window controller in this process at all.
Add a custom action to the responder chain, and connect the button's selector to the responder chain. This is what I've done, but it still seems like a distant second-best compared with the xib-style approach - a direct drag-and-drop between objects.
I suppose as I was hoping that storyboards would just make everything easier - am I now right in thinking that this target-action dilemma is a genuine shortcoming of the storyboard approach, and that I just need to get used to one of the above?