これは IOS6 の質問です。
クラス (A) を呼び出して何かを確認するアプリがあります。次に、クラス (B) を呼び出して別のことをしたいのですが、プロセス A が終了する前にプロセス B が開始されないようにすることは可能ですか?
現時点では、RootVC で次々と呼び出すだけです。
それぞれがモーダル ビューを表示しており、B しか表示されません。
[self performA];
[self performB];
ありがとう
これは IOS6 の質問です。
クラス (A) を呼び出して何かを確認するアプリがあります。次に、クラス (B) を呼び出して別のことをしたいのですが、プロセス A が終了する前にプロセス B が開始されないようにすることは可能ですか?
現時点では、RootVC で次々と呼び出すだけです。
それぞれがモーダル ビューを表示しており、B しか表示されません。
[self performA];
[self performB];
ありがとう
アプリケーションの一部の実行順序を管理するために使用できるツールがいくつかあります。ただし、View Controller を提示しているため、いくつかの制約があります。メイン スレッドをブロックしたくない場合 (そうしないと、アプリが応答しなくなります)、メイン スレッドで UI アクションを実行する必要があります。
この場合、最も一般的でおそらく最も適切な解決策は、アクションの終了B
時にアクションをトリガーするようにコールバックを設定することです。A
の一部として提示されたモーダル ビュー コントローラーA
は、タスクが正常に終了したときにデリゲートを呼び出す場合があります。その後、そのデリゲートは task を開始できますB
。
または、終了時に実行A
されるブロックを渡すこともできます。A
そのブロックはタスクを実行できますB
。
敢えて失敗しました。ストーリー: 私のアプリは、iOS4 ターゲットから iOS6 (iOS5/3GS 用の偶発的なコードのサブを使用) への更新に地獄を与えています。@try などを使用しない限りクラッシュします... 再試行時に遅延間隔が組み込まれています (これはばかげています。ユーザーが持っているデータベースの大きさや、それらをロードするのにかかる時間がわからないためです) . 私の本当の問題を回避するのは面倒な方法です.CoreDataスタック(ログ)が完全にロードされる前にビューがロードされ、NSMutableArray(私のCoreDataデータベースに基づく)まで初期ビューを待機させる方法がわかりませんオブジェクト) が読み込まれます。基本的に、私のエンティティの最も重要な属性である addObjectsSortedBy に関する誤ったエラーが発生し続けます。スレッド化が答えのようですが、NSMutableArray をロードして initialViewController にフィードする必要があります。これはすべての起動時に表示されます (FirstTime の初回を除く) が、スレッドを使用しようとする試み (12 回の試行) で、アプリの起動の早い段階でクラッシュが発生しました。結果:私は、その糸の雄牛を論争させた人々に頭を下げます. 私の解決策は、AppDelegate.m に通知を組み込むことでした。私の initialViewController viewDidLoad は、何よりも先にそれをリッスンするように指示されました。通知を受け取った場合はスキップして、[super viewDidLoad] までの通常のプロセスを完了します。そうでない場合は、@try、@catch、@finally を実行します。@try では、通知が到着したかのように (少し遅れたように) 続行を試みます。次に、ユーザーに「お待ちください」ラベルを表示してエラーを処理 (@catch) し、アプリに待機するように指示します。 .xx を追加して、元の addObjectsSortedBy: を繰り返します。ログに画像とデータが含まれている私のアプリのスイートスポットは、待機間隔 @ 50 テストエントリで 0.15 のように見え、時間に余裕があり、負荷に明らかな遅延はありません。おそらく .10 @50 エントリまで下げることができます。BUT: object.count を取得するのに十分なログをロードせずに、これをスケーリングする方法がわかりません! それがなければ、遅延をスケーリングする方法はありません。つまり、多くのエントリ (200 以上) を含む大きなログでは機能しない可能性があります (読み取り: 機能しません)。回避策はありますが、解決策を得るために、スレッド化を把握しようと試み続けます。正直なところ、20 個のエントリをヒットすると、@try が発生するのに間に合うように通知がヒットすることはありません。可能であれば、スレッドを使用してください。早い段階で失敗して窮地に追い込まれ、その代償を払っています。私のアプリはオーバーホールが必要でした。しかし、それが価値あるものになる前に、ベルトにこのノッチが必要です. スレッド化されたロードを実装できる時期が早ければ早いほど、長期的な開発に適しています。それまでの間、私の回避策を使用して、アプリの他の部分のテストを続行できる場合があります。