4

neb でビューの高さを固定値に設定すると、問題が発生するのではないかと考えています。

例: ステータス バーの高さはわかっています。20台です。では、素敵なインターフェイスを表示するビューを作成する場合、ユーザーがアプリの使用中に電話をかけ、ステータス バーの高さが増加するとどうなるでしょうか? あるいは、Apple が将来、ステータス バーやタブ バーの高さを変更したらどうなるでしょうか?

すべてのインターフェース要素を内部に持つコンテナビューに常に自動サイズ変更機能を使用していますか? あなたのパターンは？

4

6 に答える 6

7

ステータス バーやツールバーなどの高さの値をプログラムにハード コーディングすることは避けたいと思います。これらの値がどのように動的であり、将来変化する可能性があるかについて、いくつかの良い例を示しています。サポートされているかどうかに関係なく、もう 1 つの一般的なシナリオは、ユーザーが iPhone を横向きに回転できることです。

私は常にコンテナのサブビューのレイアウトを柔軟に保つようにしています。自動サイズ変更機能を使用するのが良い方法です。あなたの質問は良いもので、自分のレイアウト戦略を見直すきっかけになると思います!

于 2009-05-12T14:08:39.043 に答える
4

私は常に、自動的にサイズが変更される柔軟なレイアウトを使用しています。これにより、デザインに集中し、コンピューターに計算を任せることができます。

[編集] 私の理由は、何かが変わるだろうということであり、この場合、計算をやり直したくありません。変更できること:

  • ユーザーはより大きなフォントを選択する可能性があります
  • 次世代のデバイスはより大きな画面を取得します
  • 翻訳者は、単語をピクセル単位のスペースに収めなければならないことを嫌います
  • アドオンは画面上で数ピクセルを占める場合があります
  • OSの変更により、画面サイズが数ピクセル変わる場合があります
  • 定義済みのアイコンを使用している場合、サイズが変わることがあります
  • 最終的に、柔軟なアプリケーションでは、ユーザーは見たいものを選択できます。彼女が UI をレイアウトする必要はありません。

したがって、レイアウトを静的にすると、最終的にはもう一度やり直す必要があります。そしてまた。ソフトウェア開発の唯一の不変は変化であることを学ぶまで。

于 2009-05-12T13:52:45.783 に答える
3

さて、私はここで手足を出していますが、レイアウトの寸法 (今日の iPhone ではピクセル単位です) をハードコーディングするという考えは、理論的には問題を引き起こす可能性があると思います (または、少なくとも余分な作業が必要になります)。将来。

ステータス バー、デフォルトのタブ バー、またはナビゲーション バーの見た目のサイズを変更することについてはあまり心配していません... 単位が変更されることを心配しています。私は登録済みの OS X 開発者ではありませんが、Snow Leopard が、ピクセルに基づくのではなく、解像度に依存しないインターフェイスの指定方法をサポートするという噂が長い間ありました。

明日、3.0、あるいは来年には実現しないかもしれませんが、解像度に依存しないインターフェイスというこのアイデアは、特にディスプレイサイズ (より具体的にはディスプレイ解像度) が将来変更されるにつれて、iPhone に実装される予定です。 .

話が長くなってしまいましたが、私が将来変更したいと考えているのはステータス バーのサイズではなく、デバイスのサイズであり、Cocoa Touch でサイズを指定するために使用する単位です。

于 2009-05-12T14:24:22.210 に答える
1

考慮すべきことの1つは、ユーザーが電話を受けた後、電話中にアプリケーションを起動すると、ステータスバーの高さが変化することです。したがって、システムUI要素の高さでのハードコーディングを回避することは間違いなく必要です。

于 2009-05-12T15:12:22.943 に答える
1

UICatalogサンプルには「constants.h」がありますが、これはそのサンプルにローカルであり、サンプル開発者が自分の生活を楽にするための単なる方法であることは明らかです。上記のすべての問題が発生します...将来、「標準サイズ」が変更された場合、このサンプルは正常に機能しなくなります。

配置を正しくするために他のオブジェクトにクエリを実行する必要があるのは面倒ですが、環境が変化したときに物事が適切に機能するようにする方法です。拡大する「通話中」ステータスバーは完璧な例です。ステータスバーを回避するために20個の「ユニット」をハードコーディングすると、通話中にアプリが壊れます。そして、それはシミュレーターでは気付かない可能性が高いものです（なぜなら、シミュレーターでそのオプションを試すのに十分なことを考えていれば、アプリのコーディング中に考えたことがあるでしょう！）

于 2009-05-13T15:15:37.513 に答える
0

これらのサイズのほとんどは、Appleが提供するファイル「Constants.h」に含まれていませんか？（UICatalog SDKの例の一部であることに気づきました）。

Appleは、画面が大きいまたは小さい別のデバイスをいつか発売する可能性が非常に高いと思います。したがって、[UIScreenフレーム/境界]と組み合わせて使用​​する必要があります。

// these are the various screen placement constants used across all the UIViewControllers

// padding for margins
#define kLeftMargin             20.0
#define kTopMargin              20.0
#define kRightMargin            20.0
#define kBottomMargin           20.0
#define kTweenMargin            10.0

// control dimensions
#define kStdButtonWidth        106.0
#define kStdButtonHeight        40.0
#define kSegmentedControlHeight 40.0
#define kPageControlHeight      20.0
#define kPageControlWidth      160.0
#define kSliderHeight            7.0
#define kSwitchButtonWidth      94.0
#define kSwitchButtonHeight     27.0
#define kTextFieldHeight        30.0
#define kSearchBarHeight        40.0
#define kLabelHeight            20.0
#define kProgressIndicatorSize  40.0
#define kToolbarHeight          40.0
#define kUIProgressBarWidth    160.0
#define kUIProgressBarHeight    24.0

// specific font metrics used in our text fields and text views
#define kFontName               @"Arial"
#define kTextFieldFontSize      18.0
#define kTextViewFontSize       18.0

// UITableView row heights
#define kUIRowHeight            50.0
#define kUIRowLabelHeight       22.0

// table view cell content offsets

#define kCellLeftOffset          8.0
#define kCellTopOffset          12.0

トニー

于 2009-05-12T14:20:49.143 に答える