iOS 7 では、UIStatusBar次のようにビューと統合されるように設計されています。
（GUIデザイン：ティナ・タヴチャー）
これはクールですが、ビューの上部に何かがあり、それがステータス バーと重なると、ビューが多少乱れます。
動作方法を [重複しない] 状態に戻せる簡単な解決策 (info.plist でプロパティを設定するなど) はありますか?
より簡単な解決策は、
self.view.center.xすべてのビュー コントローラーに + 20 ポイントを設定することですが、それらを変更すると他のディメンションが台無しになり (異なるディメンションを設定すると、self.view.center.xカスタム segue などに問題が発生する可能性があります)、突然、避けたほうがよい面倒な作業になってしまいます。誰かがこれに対するワンライナーの解決策を提供してくれると本当にうれしいです。
PS ステータスバーを非表示にするには、
[[UIApplication sharedApplication] setStatusBarHidden:YES withAnimation:UIStatusBarAnimationNone];
方法はありdidFinishLaunchingWithOptionsますが、それは回避策であり、問題を回避する近道なので、本当の解決策だとは考えていません。
ベストアンサー1
これはクロスポストです私が書いたブログ記事ただし、iOS 7 のステータス バー、ナビゲーション バー、コンテナー ビュー コントローラーの詳細については、次のとおりです。
iOS 6スタイルのステータスバーレイアウトを維持する方法はありません。ステータスバーは常にiOS 7のアプリケーションに重なります。
ステータス バーの外観とステータス バーのレイアウトを混同しないでください。外観 (ライトまたはデフォルト) は、ステータス バーのレイアウト (フレーム/高さ/オーバーラップ) には影響しません。システム ステータス バーには背景色がなくなったことにも注意してください。API が UIStatusBarStyleLightContent を参照する場合、それは透明な背景に白いテキストを意味します。UIStatusBarStyleDefault は透明な背景に黒いテキストです。
ステータス バーの外観は、相互に排他的な 2 つの基本パスのいずれかに沿って制御されます。従来の方法でプログラムによって設定するか、UIViewController の新しいプロパティに基づいて UIKit が外観を更新します。後者のオプションはデフォルトでオンになっています。どちらを使用しているかを確認するには、アプリの plist 値で「ViewController ベースのステータス バーの外観」を確認してください。この値を YES に設定すると、アプリ内のすべてのトップレベル ビュー コントローラー (標準の UIKit コンテナー ビュー コントローラー以外) で、preferredStatusBarStyle をオーバーライドして、デフォルトまたはライト スタイルを返す必要があります。plist 値を NO に編集すると、使い慣れた UIApplication メソッドを使用してステータス バーの外観を管理できます。
UINavigationController は、かなり奇妙で文書化されていない一連の制約に応じて、UINavigationBar の高さを 44 ポイントまたは 64 ポイントに変更します。UINavigationController は、ビューのフレームの上部が UIWindow の上部と視覚的に連続していることを検出すると、ナビゲーション バーを 64 ポイントの高さで描画します。ビューの上部が UIWindow の上部と連続していない場合 (1 ポイントだけずれていても)、ナビゲーション バーを「従来の」方法で 44 ポイントの高さで描画します。このロジックは、アプリケーションのビュー コントローラー階層内でいくつかの子であっても、UINavigationController によって実行されます。この動作を防ぐ方法はありません。
高さが 44 ポイント (88 ピクセル) しかないカスタム ナビゲーション バーの背景画像を指定し、UINavigationController のビューの境界が UIWindow の境界と一致する場合 (4 で説明したように)、UINavigationController はフレーム (0,20,320,44) に画像を描画し、カスタム画像の上に 20 ポイントの不透明な黒いスペースを残します。これで、ルール 1 を無視した賢い開発者だと勘違いするかもしれませんが、それは間違いです。ナビゲーション バーの高さは 64 ポイントのままです。UINavigationController をスライドして表示するスタイルのビュー階層に埋め込むと、このことが非常に明確になります。
UIViewController の、紛らわしい名前の edgeForExtendedLayout プロパティに注意してください。edgesForExtendedLayout を調整しても、ほとんどの場合何も起こりません。UIKit がこのプロパティを使用する唯一の方法は、UINavigationController にビュー コントローラーを追加する場合です。UINavigationController は、edgesForExtendedLayout を使用して、子ビュー コントローラーをナビゲーション バー/ステータス バー領域の下に表示されるかどうかを決定します。UINavigationController 自体に edgesForExtendedLayout を設定しても、UINavigationController のナビゲーション バー領域の高さが 44 ポイントか 64 ポイントかは変わりません。そのロジックについては、#4 を参照してください。ツールバーまたは UITabBarController を使用する場合、同様のレイアウト ロジックがビューの下部に適用されます。
UINavigationController 内でカスタム子ビュー コントローラがナビゲーション バーの下に重ならないようにするだけの場合は、edgesForExtendedLayout を UIRectEdgeNone (または少なくとも UIRectEdgeTop を除外するマスク) に設定します。この値は、ビュー コントローラのライフ サイクルのできるだけ早い段階で設定します。
UINavigationController と UITabBarController は、サブビュー階層内のテーブル ビューとコレクション ビューの contentInsets もパディングしようとします。これは、#4 のステータス バー ロジックと同様の方法で行われます。プログラムでこれを防ぐには、テーブル ビューとコレクション ビューの automaticAdjustsScrollViewInsets を NO に設定します (既定値は YES)。これは、Whisper と Riposte にとって深刻な問題を引き起こしました。これは、ツール バーとキーボードの動きに応じてテーブル ビューのレイアウトを制御するために contentInset 調整を使用しているためです。
繰り返しますが、iOS 6 スタイルのステータス バー レイアウト ロジックに戻す方法はありません。これを近似するには、アプリのすべてのビュー コントローラーを画面上部から 20 ポイントオフセットされたコンテナー ビューに移動し、ステータス バーの背後に意図的に黒いビューを残して、古い外観をシミュレートする必要があります。これが、Riposte と Whisper で最終的に使用した方法です。
Apple は、#9 を実行しないように強く働きかけています。Apple は、すべてのアプリをステータス バーの下に重ねるように再設計することを望んでいます。ただし、ユーザー エクスペリエンスと技術的な理由の両方から、これが必ずしも良いアイデアではない理由については、多くの説得力のある議論があります。ユーザーにとって最善のことを行うべきであり、単にプラットフォームの気まぐれに従うべきではありません。