メインスレッドでUIの変更を行う必要があります。そうでない場合、誤った動作、警告またはクラッシュにつながる可能性があります常にUIの変更をメインスレッドに予防的にラップしますか?
とにかく、ほとんどすべてのUI変更をdispatch_async(dispatch_get_main_queue)) { ... }
にラップし始めました。最近、私はちょうど、すべてのUI関連のものでこれを行うのがベストプラクティスなのかどうか疑問に思っています。presentViewController
、dismissViewController
などです。何百ものラップでコードがオーバーフローするだけです。
もちろん、時にはそれが必要でないことは明らかです。例えばユーザーがボタンをタップして直ちにUIを変更した場合しかし、さまざまなコンテキストで呼び出されるメソッドがあります。ここでは、単に予防的にラップするだけです。結局のところ私はどこにでもそれらを実装し始めました。そうしないと、必要な場所で誤判断や忘れがないように本当に注意する必要があります。
あなたのアプローチは何ですか?
私は非常に分かりやすいアーキテクチャ(VIPER)を使用していますので、メインスレッドで明示的に呼び出されるメソッドがあるかもしれませんが、メインまたはバックグラウンドから呼び出すことができるメソッドがいくつかあります。 - 1つのタスクを4つのクラス(UI、ロジック、データの要求など)で分割して処理できるように、ツリー全体に戻っていく必要があります。そのようなシナリオでは何をお勧めしますか(おそらくこのアーキテクチャの不利な点は、どこにでも簡単に「大きな画像」が表示されないことでしょう)でしょうか? –
どのスレッドで何が呼び出されたのかわからないアーキテクチャは避けます。 VIPERには多くの問題がありますが、これもその一つです。原則として、VIPER **では**プレゼンター*のみがUIスレッドを呼び出す必要があります。 – Mundi
私はすでにVIPERと巨大なプロジェクトを構築しています。実際には若干の不利な点があるにもかかわらず、とても満足しています。 _Presenter_からのみUIを呼び出していますが、たとえば_Interactor_からいくつかのタスクに続く 'foundUsers'(UIに更新する)は、バックグラウンドスレッド/クエリか_Interactor_のメインスレッドから呼び出すことができます。私は自分のコードを更新しました。実際には、明示的に必要な箇所、特に_Interactorの_Interactor__が、完了したタスクの後に_Presenter_を呼び出しているような場所で、ラップを残しました。あるいは、私はその議論の中で何かを混ぜるのですか? –