iPhone の向き (wAny/hC、wC/hR) に基づいてプロパティ「Axis」を変更するストーリーボードで UIStackView をテストしようとしています。
残念ながら、実行時に変更は適用されません。具体的には、プロパティ「Axis」が変更されます (Xcode で検査されます) が、レイアウトは変更されません。
よろしくお願いいたします。
iPhone の向き (wAny/hC、wC/hR) に基づいてプロパティ「Axis」を変更するストーリーボードで UIStackView をテストしようとしています。
残念ながら、実行時に変更は適用されません。具体的には、プロパティ「Axis」が変更されます (Xcode で検査されます) が、レイアウトは変更されません。
よろしくお願いいたします。
これは間違いなくバグです。ランタイム (シミュレーターまたはデバイス) での軸の動作は、詳細な検査の後、ビュー階層内の他のすべてのUIStackView に対してのみ変更されます。
考えられるすべての順列を試したわけではありませんが、この目的の軸変更動作で複数のスタックビューを導入したいときに問題が発生したため、これが私が見つけたものです。単一のスタック ビューがサイズ クラス規則に従わない場合があるかもしれませんが、私はそれを確実に再現していません。
私のiOS 9.1 プロジェクトをチェックしてください。これは、8 つの UIStackView 要素を垂直方向に並べてこの問題を明確に示しています。それらはすべて、互いに相対的に制約された位置と画面の上部を除いて、まったく同じように構成されています。
ストーリーボードのプレビューからわかるように、ランドスケープでは期待どおりに見えます。
シミュレーターやデバイスで実行する場合は別の話になります。多くのスタック ビューを試した後、バグがビュー階層内の他のすべてのスタック ビューに影響を与えることが明らかになりました。
上記のコメントで別の言及を聞いたにもかかわらず、私はこのサンプル プロジェクトで独自の RDAR を作成しました。公的な記録は見つかりませんでした。
どうやら、自動レイアウト、制約、およびサイズクラスの目的に完全に反する、苦痛を伴うコードベースの回避策があるようです。これは、スタック ビューとサイズ クラスの非常に大きなユース ケースを排除するため、私にとって非常に大きなバグです。
Apple Developer フォーラムでの EinharchAltPlus の投稿によると、コードの回避策は次のとおりです。
ところで: viewWillTransitionToSize をオーバーライドし、さまざまなパラメーターを手動で設定することで問題は解決しますが、コード内のビューもチェックする必要があるため、これはかなり面倒です。
それが完全に明確でない場合は、非協調スタック ビューへの IBOutlet 参照と、おそらくそれがビュー コントローラー コードに入力するビューが必要です。スタック ビューの軸プロパティと、理想的には、それが含まれているものの高さを変更できます。
@IBOutlet weak var viewHackStack: UIView!
@IBOutlet weak var hackStackView: UIStackView!
override func viewWillTransitionToSize(size: CGSize, withTransitionCoordinator coordinator: UIViewControllerTransitionCoordinator) {
if(self.traitCollection.verticalSizeClass == .Compact) {
self.viewHackStack.frame.size.height = 25
self.hackStackView.axis = .Horizontal
}
else if(self.traitCollection.verticalSizeClass == .Regular) {
self.viewHackStack.frame.size.height = 50
self.hackStackView.axis = .Vertical
}
}
動作の変更を決定するサイズ クラスをより具体的にしたい場合は、目的の条件が満たされるまで、特性コレクションのサイズ クラス タイプをいじってみてください。
バグ修正のタイムラインについて何か連絡があれば、ここに投稿します。それまでは、これが回避策として役立つことを願っています。