これは私がやりたいことです:
ご覧のとおり、次のことを行います。
tableView の幅を減らします (グループ化された tableView が提供するよりも側面にマージンが必要です)
角の半径 (グループ化された tableView のデフォルトよりも大きな半径)
テーブルの周りに影を落とし、最後のセルの下に特別な影を付ける
これは私がやりたいことです:
ご覧のとおり、次のことを行います。
tableView の幅を減らします (グループ化された tableView が提供するよりも側面にマージンが必要です)
角の半径 (グループ化された tableView のデフォルトよりも大きな半径)
テーブルの周りに影を落とし、最後のセルの下に特別な影を付ける
これを行うには、セルの backgroundView を自分で「描画」します。
背景として使用する画像を取得することをお勧めします (セルがすべて同じ高さの場合)。
3 つの画像が必要です。
上部の角が丸くなった「上部」の画像。下の角を丸くし、希望どおりのドロップ シャドウを付けた「下」の画像。そして、角が丸くない「真ん中」のイメージ。
セルにテクスチャやグラデーションが含まれていない場合は、伸縮可能な画像を使用してセルのメモリ フットプリントを削減できます。
次に、UITableViewCell をサブクラス化し、backgroundView をオーバーライドして UIImageView を追加します。また、セルのタイプ (上、中、下) を変更するためのアクセサー メソッドも提供します。
各セルは、UIImage の 3 つの placeHolder プロパティ (topImage、bottomImage、および middleImage) を持つことができます。セルのタイプが変更されると、これらにアクセスできます (遅延インスタンス化を使用して、必要なときにのみ 1 回だけ読み込まれるようにします)。次に、backgroundView 画像を必要な画像に設定します。
このようなもの...
UITableViewCell サブクラスで、列挙型を定義します...
typedef enum {
CellTypeTop,
CellTypeMiddle,
CellTypeBottom
} cellType;
次に、タイプのプロパティ...
@property (nonatomic) cellType cellType
次に、.m ...
さらにいくつかの内部プロパティを定義します...
@property UIImageView *bgImageView;
@property UIImage *topImage;
@property UIImage *middleImage;
@property UIImage *bottomImage;
次に、imageViewを追加します(1回だけ)...
- (void)awakeFromNib //or in the init depends how you are initialising the cell
{
self.bgImageView = [[UIImageView alloc] initWithFrame:blah];
[self.backgroundView addSubView:self.bgImageView];
}
さて、型を変えると・・・
- (void)setCellType:(cellType)cellType
{
switch(cellType) {
case CellTypeTop:
self.bgImageView.image = self.topImage;
break;
case CellTypeMiddle:
self.bgImageView.image = self.middleImage;
break;
case CellTypeBottom:
self.bgImageView.image = self.bottomImage;
break;
}
}
最後に、画像の遅延インスタンス化...
- (UIImage *)topImage
{
if (_topImage == nil) {
_topImage = [UIImage imageNamed:@"topImage"];
//alternatively...
_topImage = [[UIImage imageNamed:@"topImage"] stretchableImageWith...
}
return _topImage;
}
他の画像についてもこれらを繰り返します。
これは、CALayer の代替を使用するよりも (長い道のりで) パフォーマンスが向上し、特に伸縮可能な画像を使用する場合は、メモリ フットプリントが非常に小さくなります。
他の何人かのユーザーは、これはパフォーマンス、メモリ、デザインなどに良くないと言っていますが、CALayers よりも UserExperience で最高のパフォーマンスを得るための最良の方法です。はい、それは CALayers よりも多くのメモリを使用しますが、作成されるデキュー可能なセルはごくわずかであるため、限界に達します。
scrollViews で CALayers を使用する場合のパフォーマンスの問題を説明するいくつかのリンク...
CALayer で描画された 3 つのビュー コントローラーを搭載したスクロール ビューでパフォーマンスが低下する
::編集:: 編集してマイケルの質問に答えます。
ストーリーボードで UITableViewController を作成します (サブクラス UITableViewController と一致するように、インスペクターでクラスの名前を変更します - 私はそれを MyTableViewController と呼びます)。
コード (つまり、.h と .m) で UITableViewCell のサブクラス (私は MyTableViewCell と呼びます) を作成します。
上記のコードを MyTableViewCell.h ファイルに追加して、プロパティとタイプ、および imageViews を処理します。
ストーリーボードで、TableViewController のセルを選択し、クラスの名前を MyTableViewCell に変更します。また、再利用識別子を設定します。
MyTableViewController コードでは、次のような関数が必要になります...
-(UITableViewCell*)tableView:(UITabelView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath
{
MyTableViewCell *cell = [tableView dequeueCellWithReuseIdentifier:@"Cell"];
cell.cellType = CellTypeTop; //or whichever it needs to be
cell.textLabel.text = @"Blah";
return cell;
}
ああ、別のことですが、ストーリーボードでは、セルをどのように表示し、すべてのラベルとイメージビューなどをリンクするかをレイアウトできます... IBOutlet を UIImageView に追加して、リンクできるようにしてくださいストーリーボード。
#import <QuartzCore/QuartzCore.h>
インポートしたことを確認してから、UITableView のレイヤーへのアクセスを開始できます。
UITableView *yourTable = [[UITableView alloc] initWithStyle:UITableViewStyleGrouped];
[[yourTable layer] setCornerRadius:10.0f];
[[yourTable layer] setShadowColor:[[UIColor blackColor] CGColor]];
[[yourTable layer] setShadowOffset:CGSizeMake([CALayer ShadowOffSetWidthWithFloat:10.0f], [CALayer ShadowOffSetWidthWithFloat:10.0f])];
[[yourTable layer] setShadowOpacity:[CALayer ShadowOpacity:1]];
[[yourTable layer] setMasksToBounds:NO];
UIBezierPath *path = [UIBezierPAth bezierPathWithRect:yourTable.bounds];
[[yourTable layer] setShadowPath:[path CGPath]];
これにより、影が の境界にマスクされずに、テーブル ビューに影の影響が追加されます。テーブルUITableView
のsetCornerRadius
角を好きなように設定できます。を実行してframe
を設定することもできますUITableView
[yourTable setFrame:CGRectMake(CGFloat x, CGFloat y, CGFloat width, CGFloat height)];
編集
CALayer
別のユーザーが非常に遅いと指摘しようとしたように、そうではありません
CALayerは、アニメーションに関するパフォーマンスの問題を解決するために導入されました。ドキュメントをお読みください。画像をそのままロードするのは良い考えのように思えるかもしれませんが、長い目で見ればより多くのメモリを消費します。画像のメモリ割り当てについてこの質問をしてください。ご覧のとおり、高速に見えるかもしれませんが、2.25 MByte of memory
各画像を何度も読み込むと、アプリの速度が低下し始めます。