問題タブ [reuseidentifier]

プロジェクトのビュー コントローラーで UITableView のセルを選択すると、ランダムにクラッシュします。

問題は、再利用しようとしているセルが原因だと思います。

これがコードです。

XCode でテーブルを作成します。そのため、IB には識別子を持つ UITableViewCell オブジェクトはありません。

テーブルの作成中にこれをコードに追加することは可能ですか? それとも別の場所に問題がありますか？

ありがとう

テーブルビューのすべてのセルに「blank_starアイコン」を作成しようとしています。ユーザーがクリックすると、星は「塗りつぶされた」星になります。

UIButton以下のようなサブクラスを作成しました

cellforRow:次のように、テーブルビューのメソッドにUIButtonのサブクラスを追加しました。

ただし、アプリの実行時に問題が発生します。たとえば、「a」とマークされたセルをクリックすると、期待どおりに星が塗りつぶされます。

奇妙なことに、下にスクロールすると、星が点灯している他のセルも表示されます（セル「e」を参照）。

誰かがこれが起こっている理由を説明するのを手伝ってもらえますか？stateセルのが他のセルで再利用されているようです。どうすればこれを回避できますか？

テーブルビューセルにカスタム背景と選択した背景画像を追加したいと思います。現在、セルが再利用されると、背景画像が台無しになり、上部のセルは下部のセルの画像などを使用するようです。

この場合、セルを誤って再利用していますか？

したがって、各セクションに 3 行 (全体で 9 行) の 3 つのセクションがあり、各行はtextField.

私はtableViewにいくつかの問題があり、上下にスクロールするとセルが値と混同され、tableView全体がめちゃくちゃになるので非常に面倒でした。私のプログラミングのロジック不足が原因である可能性がありますが、私はこの問題をすぐに解決することにしました。

だから、私は今、を無効にしましたが、今dequeueReusableCellWithIdentifierは問題ないようです。Apple のドキュメントから、再利用によって大きな tableView のパフォーマンスが向上することがわかります。セルの再利用を防止しました。

それぞれ3行のセクションが3つしかありません。

1. ここで話しているパフォーマンスの低下の大きさは正確にはどれくらいですか?

2. そのビューに小さな tableView があることを念頭に置いて、これはアプリ全体にどのように影響しますか?

3. App-Store でのこのアプリの承認に関して複雑なことはありますか?

ps私はこのアプローチを1つのビューにのみ使用しています。他のすべてのビューには、再利用可能なセルがあります。

私のプロジェクトでは、非推奨の警告があります。initWithFrame：reuseIdentifier：は非推奨です

それが何を意味するのかわかりません。誰かがこの警告を解決する方法を教えてもらえますか？

これがショートコードです

そして警告はその行にあります：

テーブル セル内に水平テーブル ビューを埋め込みました (Pulse Reader のように)。私が得ている興味深い動作は、dequeueReusableCellWithIdentifier:何もしなくても、埋め込まれたテーブル ビューのオフセットを正しく記憶しているように見えることです。しかし、「思い出す」には 2 つの味があります。

最初（予定）

100 個のセクションとセクションごとに 1 行のテーブルを作成します。各セル (各セクション) は、100 行と 1 つのセクションを持つように強制する埋め込みテーブル ビューを取得します。垂直のテーブル ビューをスクロールすると、セルが再利用されます (後でセルのインスタンス名を見て確認します)。dequeueReusableCellWithIdentifier:

最初のテーブル ビュー セルの埋め込みテーブル ビューを右にスクロールすると (たとえば 10.5 セル)、垂直テーブル ビューでいくつかのセルを下にスクロールすると、再利用されたテーブル セルの埋め込みテーブル ビューが 10.5 セル分オフセットされます。これは理にかなっています。セルは再利用されただけで、オフセットをリセットしませんでした。再利用されたセルが 7 行目だったとします。7 番目の行の埋め込みテーブル ビュー (これは再利用のため、行 1 と同じ埋め込みテーブル ビューです) を位置 20 にスライドすると、テーブル ビューを埋め込んだ垂直テーブル ビュー (私が持っていたもの) の上部に移動します。最初は 10.5 に移動されました)、現在は 20 です。繰り返しになりますが、これらの表のセルは同じです。再利用しただけです。

2番目（望ましいが、それがどのように機能するかわかりません）

ここで、実際のデータを入力します (単に印刷するのではなく)

セルに。

さて、突然、埋め込まれたテーブル ビューがどこにあったか覚えているようになりました。セルが再利用されていることをもう一度確認します (上記と同じ方法)。しかし今回は、最初の埋め込みテーブル ビューを (位置 10.5 まで) スクロールし、7 行目までスクロールすると、7 行目が開始点になります。最初の行をスクロールして表示に戻すと、元の場所に戻ります。

これは Xcode 4.2 と iOS 5.0 を使用しています。何か賢いことdequeueReusableCellWithIdentifier:はありますか？

古い学校 (iOS 5.0 より前) では、

何が起こっているかを確認するためのロジックが少しありましたが、StoryBoards ではそれらは不要になりました。

異なる動作をする 2 つのサンプル プロジェクトはちょっと大きいですが、見たい関連コードがあれば教えてください。

あいまいで申し訳ありませんが、これらのテーブル ビューのメモリ管理で何が起こっているのかを正確に把握しようとしています。

すべての接続は IBOutlets 経由で行われ、StoryBoard で行われます。

ありがとう！

最初の垂直テーブル ビュー コントローラー

最初の水平テーブル ビュー デリゲート/データ ソース

2 番目の垂直テーブル ビュー コントローラー

2 番目の水平テーブル ビュー デリゲート/データ ソース

さまざまなカスタム UITableViewCells (およびセル識別子) を持つ UITableView を持つアプリケーションがあります。

実装されたtableView:cellForRowAtIndexPath:メソッドでは、UITableView のdequeueReusableCellWithIdentifier:メソッドを使用し、ユーザーがテーブルをスクロールしているときに呼び出されると、期待されるタイプの UITableViewCell を提供しますが、コードの他の部分で再利用可能なセルを取得しようとすると、nil が得られます。そのため、新しいセルをインスタンス化する必要があります。

たとえば、表示する新しいオブジェクトを挿入するコードは次のようになります。

画面を離れたばかりのセルは、挿入しているのと同じタイプ (同じセル識別子) でしたが、tableView:cellForRowAtIndexPath:それはその呼び出しで and をトリガーし、 nil を返します。dequeueReusableCellWithIdentifier:

再利用可能なセルを提供するべきではありませんか？私の場合、私のセルはその複雑さのためにやや「重い」init メソッドを持っているため、これは問題になる可能性があります。

前もって感謝します

Edit1:明確にするために、(挿入しているのと同じタイプの) 一部のセルが表示されなくなったため、テーブルキャッシュに未使用のセルインスタンスが返されない理由を知りたいですか?

ストーリーボードに次のインターフェイスを設定しています。

コントローラは、UITableViewControllerから拡張されたカスタムコントローラです。アプリを実行すると、次のようになります。

再利用識別子と関係があるのではないかと思ったので、セルごとに固有のものに変更し、それに応じてコードを変更しましたが、何も表示されません。

私はストーリーボードを使用して iOS 5 プロジェクトに取り組んでいるため、IB で動的テーブル セル プロトタイプを使用しています。ビューの 1 つで、セルの高さがコンテンツの高さから計算された、高さが可変のセルを含むテーブル ビューがあります。

tableView:heightForRowAtIndexPath:テーブル ビューが最初に表示されたときに、すべてのセルに対して正しい値を返します。いくつかのアイテムを下にスクロールするとすべて問題ありませんが、何かがうまくいかないことがあります。実際のセルは、タッチ領域を含めて正しい高さのように見えますが、セパレーターが間違った場所 (セル間ではなくセル内) にレンダリングされます。

セパレーターの配置を測定すると、セルの再利用がこれと関係があるように見えます。最初の 3 つのセルのセパレータは正しく表示されますが、4 番目のセルは正しく表示されません。heightForRowAtIndexPath:正しい高さ (この場合は 125 ピクセル) を返し、含まれるサブビューはすべて適切な場所に配置されます。ただし、セパレータは前のセパレータから 108 ピクセルだけレンダリングされ、セルの高さ 125 ピクセルの領域内に配置されます。

キッカーは次のとおりです。108px は最初のテーブル セルの高さで、現在は見えなくなっており、おそらく再利用されています。これについて明確な証拠はありませんが、テーブル ビューはheightForRowAtIndexPath:これらのセルを無視しており、再利用されたセルの高さに応じてセパレータをレンダリングしているようです。

これは、後の短いセルの束がセパレーターとしてまったくレンダリングされない理由を説明していません。しかし、これは私が続けなければならないすべてです。

回避策、IB 設定、またはその他に役立つものはありますか?

以下で loadImage のコールバック ブロックが実行されると、テーブル セルが再利用された可能性があります。したがって、「imageView」に適用される画像は、この再利用されたセルには関係なく、古いセルの画像です。

画像を持つセルごとに識別子を一意にすると、問題はなくなります。しかし、これは多くの結果でパフォーマンスが低下します。

コールバック ブロックで同じ再利用識別子を何らかの形で使用して、画像を正しいセルに表示することはできますか?