Outlets lose their connections after "vary for traits"

Question

Created Apr ’17

Replies 2

Boosts 0

Views 1.3k

Participants 1

I have three UI objects (two UISwitch-es and a UIButton) that I have configured in different places based on varying traits.

In the original layout, these three were in the layout in the any height/any width case, but I needed to have them in different locations in the compact height case, so I cut them with CMD-X from the main storyboard. I then selected the iPhone SE in landscape mode, clicked "Vary for Traits" and added a variation for the height only (so, any width, compact height). I pasted the elements back in, placed them appropriately, set constraints, and clicked "Done Varying." I then switched back to the iPhone SE in portrait mode, and clicked "Vary for Traits" and added a variation for the height only (so, any width, regular height). I did the same thing, placed the items where they should be, set the appropriate constraints, and clicked "Done Varying."

Ran the simulators for a few devices just to check their layout. iPhone SE, 7, iPad Air 2, all layout properly. No problems there.

What has happened, though, is that the two UISwitch elements (which are in a stack view) have lost their connection to their Outlets in the ViewController. The button did not. I didn't realize this until I got a fatal error trying to unwrap an Optional with a nil value, which was pointing to one of the switches (it occurs for both, but when I first ran across it only one of them was being checked).

I did not add these elements into a stack view in either varied layout, but rather the stack view containing the two UISwitch (and associated labels) is itself being varied for traits, in its location/constraints on the two variations. The UIButton element is not losing its outlet, and it is not in a stack view.

I can click-drag the ➕ button from code to the UISwitch elements, and have done so explicitly in both hC and hR, with and without Vary for Traits enabled (whether Vary for Traits is or is not enabled doesn't change the outcome). When I then hover over the ➕ button, it shows the connected switch, but only for the most recently-changed height; that is, if I reconnect the outlet in wC/hR, it will only highlight the connected switch in wC/hR. When I click on the landscape Orientation, hovering over the ➕ button does not show the connected switch, but it does still have the ➕ (i.e., it is not an empty circle).

After this, running in the simulator no longer crashes in either orientation, but the switches only work correctly in the last orientation in which the outlet was last connected.

So, what did I do wrong, and what can I do to solve this?

Answered by bdw in 222290022

I see my mistake.

I had been following along with the iTunesU lectures for iOS 10, and when Professor Hegarty got to the AutoLayout, he did a copy & paste of a stack view with buttons that layout in different places based on the size class. For his app, that might work; but in my case, I just needed to adjust the location & constraints. When I backed out changes and deleted the "install only in hC" variation (and changed the "install only in hR" to "Installed" without size class restrictions), then moved & adjusted constraints for the stack views with the Switches, there were no more conflicts. Chalk it up to learning more about Autolayout, Stack Views, and Size Classes.

Boost

Answer 1

bdw OP

Apr ’17

Also, I have discovered that this only affects the UISwitch outlet, but not the Action associated with it.

Each switch triggers a different setting enable/disable. Switches and their setting are correct on first launch. Tapping the Switches in the varied trait that I most recently re-connected the outlet, that works. I have a "reset" button (not involved in the variations) which resets everything to its default settings. In the most-recently-varied trait, it resets the settings and also toggles the Switches to their default setting if needed.

Using the app in the orientation where I last reconnected the outlets (in the case I'm testing now, any width/regular height, i.e. portrait for the iPhone SE) works as expected
If I change the state of either switch or both of them, the app responds correctly
Tapping "reset" sets both the UI elements (specifically in this case the two switches) back to their default states if needed (it also appropriately resets the settings that underlie the switches)
If I change orientations (here, to any width/compact height, i.e. landscape for the iPhone SE) in the default state, everything works correctly, including changing the switches …
Until I click "Reset"; then, the UISwitches do not resume their default states, but their settings are reset.
I prove this by
- setting the switches to their non-default state in portrait
- rotating to landscape (switches are still in their current toggle state, appropriately)
- tapping "Reset" and observing that the toggles do not change
- Executing the action of the app, which shows that the settings have changed back
Also, by:
- setting the switches to non-default states in portrait
- rotating to landscape (again, switches are in their current toggle state, appropriately)
- tapping "Reset" and observing the toggles do not change
- And then rotating to portrait mode, in which case the toggles have changed back to default settings

0

Answer 2

bdw OP

Apr ’17

Accepted Answer

I see my mistake.

I had been following along with the iTunesU lectures for iOS 10, and when Professor Hegarty got to the AutoLayout, he did a copy & paste of a stack view with buttons that layout in different places based on the size class. For his app, that might work; but in my case, I just needed to adjust the location & constraints. When I backed out changes and deleted the "install only in hC" variation (and changed the "install only in hR" to "Installed" without size class restrictions), then moved & adjusted constraints for the stack views with the Switches, there were no more conflicts. Chalk it up to learning more about Autolayout, Stack Views, and Size Classes.

0