プライマリ ビュー (ボタンとして使用するいくつかのサブビューを含む) での対話を無効にしました。
ネットワーク アクティビティ (データの読み込み) を示すセカンダリ ビューを表示している間は、これを無効のままにします。終了したら、プライマリ ビューでインタラクションを再度有効にします。
これは、ネットワーク操作が行われている間、ユーザーがこれらのボタンをタップしないようにするためです。
とにかく、すべて順調に見えますが、ユーザーがプライマリ ビューでボタンをタップし始めると、再有効化が発生すると (過去数秒から) それらのタッチ イベントが実際にトリガーされます。ボタンを強調表示する touches-begin ではなく、touches-end で呼び出される関数です。無効になっている間ずっとキューに入れられ、「追いつくために競争」しているようなものです。
ビューでユーザー操作が無効になっているときにタッチイベントがキューに入れられるのはなぜですか?
ここでコードを見ずに答えを確信するのは難しいですが、ここに 1 つのアイデアがあります。
ネットワーク アクティビティが同期的、つまりブロッキングである場合、ユーザーがコードにアクセスする機会が得られる前に、ユーザーのタッチがキューに入れられる可能性があります。その場合、それらのタッチはネットワーク アクティビティが終了するまでレスポンダー チェーンに送信されず、それらのコントロールとの対話が無効にされたことを「知る」機会が得られません。
状況をデバッグするのに役立つ 1 つの方法を次にNSLog示します。ネットワーク アクティビティを示す最上層 (セカンダリ ビューと呼ばれるもの) にいくつかのデバッグ ステートメントを追加します。セカンダリ ビューのフレームがそれらのタッチを含めるのに十分な大きさであることを確認し、タッチが発生するとすぐにログに記録されるかどうかを確認します。そうでなければ、私の推測は正しいかもしれません。はいの場合でも、有用な情報を得ることができます。タッチをキューに入れるのではなく、このレベルで簡単にキャプチャできる場合があります。
この推測が正しければ、私が考えることができる最も簡単な修正は、ネットワーク操作を非同期にすることです。
それをしたくない場合は、 を使用してNSTimer、同期呼び出しが完了した後、ネットワーク アクティビティ インジケーターを一瞬だけアップしたままにすることもできます。このようにして、レスポンダー チェーンは着信タッチのキューをクリアし、それが望ましい動作であれば無視することができます。