セグメント化されたコントロールがトグルとして使用されています。トグルすると、目立った時間がかかります(テーブルビューのセクションの挿入/削除、変更のアニメーション化など)。私は、セグメント化されたコントロールがすぐに選択に応答するようにしたい。だから、セグメント化されたコントロールのUIControlEventValueChangedイベントのコードを処理し、私の行動に、私は、次の手順を実行しますUISegmentedControl(その他)の応答性を維持する
updateGrouping
がある
- (IBAction)groupingChanged:(id)sender {
UISegmentedControl *seg = sender;
[tableModel toggleOn:[seg selectedSegmentIndex] == ToggleOnIndex];
[self performSelectorOnMainThread:@selector(updateGrouping)
withObject:nil
waitUntilDone:NO];
}
:waitUntilDone:NO
の設定
- (void)updateGrouping {
MXAssertMainThread();
[tableView beginUpdates];
... several table updates
[tableView endUpdates];
}
は、updateGrouping
が呼び出される前に完了するgroupingChanged
方法を可能にしかし、これはビューを再描画するのに十分ではないようです。セグメント化されたコントロールは、テーブルの更新が完了するまでスティックされ、切り替えられます。
だから私はそうのような更新のためにスレッドを作成するgroupingChanged:
を修正しようとした:
- (void)delayed {
[self performSelectorOnMainThread:@selector(updateGrouping)
withObject:nil
waitUntilDone:NO];
}
- (IBAction)groupingChanged:(id)sender {
UISegmentedControl *seg = sender;
[tableModel toggleOn:[seg selectedSegmentIndex] == ToggleOnIndex];
[self performSelectorInBackground:@selector(delayed) withObject:nil];
}
そして、これは作業を行います。セグメント化されたコントロールは即座にトグルし、すぐに表が続きます。しかし、私は結果に自信がありません。新しいスレッドが起動している間、メインスレッドに執行猶予を与えるだけの副作用ですか?これはUIに更新をキューイングする必要があるのでしょうか?それは明らかにハッキーです。私は誰かがこの状況のために従っているより良いパターンを持っていることを望んでいます。
これは中間スレッドを排除するので改善ですが、一般的な非ハッキーパターンはないと信じることを拒否します。 –
performSelector:withObject:afterDelayもKendallが指摘するように有効です。この問題は、UIを更新できるように実行ループを完了する必要があることです。これは実際にハックではなく、この事実を認めているだけです。メインスレッドがそのコースを実行することを許可せずにUIを更新する方法はわかりません。 –
もちろん、私はその原因を理解しています。私はこれのための共通のパターンを望んでいたと思います。クレジットが獲得(遅れている)。 –