1

私はここで少し途方に暮れています。どこが間違っているのか誰かが指摘してくれることを願っています。

私のアプリケーションは、iPad 用のマスター/ビュー アプリケーションです。

私の MasterView は UITableView を継承しており、didReceiveMemoryWarning がない限り問題なく動作します。カスタム セル コンテンツを取得しましたが、すべてうまく機能します。ここまでは順調で、ビルドに数時間しかかかりませんでした。

ただし、didReceiveMemoryWarning を取得すると、self.tableView の動作がおかしいようです。numberOfSectionsInTableView および tableView:numberOfRowsInSection: メソッドが再度呼び出されることはなく、コードが最初の項目を選択しようとすると (メモリ警告の後)、次のようになります。

[self.tableView selectRowAtIndexPath:[NSIndexPath indexPathForRow:0 inSection:0] 
                animated:NO
                scrollPosition:UITableViewScrollPositionMiddle];

でクラッシュします

-[UITableView scrollToRowAtIndexPath:atScrollPosition:animated:]: 行 (0) がセクション (0) の境界 (0) を超えています。

それで、何が得られますか？メモリ警告中に tableView のメモリが完全に消去された場合、なぜ nil に設定されなかったのですか? また、どうすればそれを再び構築できますか？

4

1 に答える 1

1

コードごとにインターフェースビルダーごとにテーブルビューを実装していますか? self を使用する場合、retain を使用してプロパティを使用すると仮定します。viewDidUnLoad でこれを nil に設定しているかどうかを確認し、dealloc メソッドでフィールド ポインタを解放してください。そうでない場合、問題は別の場所にありますが、良い習慣であるため、そうすることをお勧めします。

コードで tableview を作成し、viewDidUnload でプロパティを nil に設定した場合は、メモリ警告を受け取った後に再度割り当てる必要があります。それを行う場所は、viewDidLoad、initWith などです。Nav または TabBarController を介して戻るとすぐに呼び出されるため、ほとんどの場合、View did load がより適切なオプションです。

インターフェイス ビルダーを使用し、ビューが AppDelegate (たとえば didFinishLaunchingWithOptions メソッド) に読み込まれた場合、awakeFromNib メソッドは、再度呼び出さない限り、再度呼び出されることはありません。したがって、その場合、viewDidUnload でインスタンス変数を nil に設定しないでください。そうしないと、インターフェイスビルダーのテーブルビューへのポインターが失われます。この最後の部分が理由である可能性がありますが、IMO は良い習慣ではないため、実際にはそうすべきではありません。

コードについて詳しく教えていただければ、より具体的にお手伝いできます。

こんにちはマルクス

于 2012-01-01T12:18:05.630 に答える