私のアプリの要件では、アプリを初めて起動すると、サーバーにリクエストを送信してデータを取得し、解析して、プロジェクト全体で使用されるドキュメントフォルダーに保存します。特定の時間間隔が経過すると、アプリは再び送信します。更新されたデータ（存在する場合）を取得し、ドキュメントフォルダー内のそのデータを更新するようサーバーに要求します。このデータは、プロジェクト全体で再度更新されます。このプロセスはすべてバックグラウンドスレッドで実行されます。このプロセスは、アプリがフォアグラウンドで実行されるまで繰り返されます。ユーザーがアプリを閉じると、アプリは終了し、バックグラウンドでは実行されません。
この繰り返しのリクエストは、アプリデリゲートで作成し、データを受信したらxml解析を実行し、解析後に保存します。今私の質問は、これはアプリデリゲートでやりすぎることが安全であることを意味しますか、それともいくつかの制限がありますか、それともこれは悪いプログラミングですか？
これを行う正しい方法は何ですか？
torrey.lyons にはある程度同意できません。シングルトンを作成することは、一般的に言えば悪い習慣であり、可能な限り避けるべきだと思います。絶対にしてはいけないことの 1 つは、必ずシングルトンになるようにクラスをコーディングすることです。専用に構築されたシングルトンは結合を増加させる傾向があり、シングルトンをスタブ クラスに置き換えたり、ユニット テストごとに再初期化する必要があるユニット テストに関しては、非常に問題になる可能性があります。
データを取得するこのタスクがアプリケーション レベルのタスクである場合、アプリケーション デリゲートに論理的に配置できない理由はまったくありません。ただし、torrey.lyons が示唆するように「接続マネージャー」を作成し、アプリ デリゲートのプロパティとして使用します。
また、明示的なバックグラウンド スレッドを使用してデータを更新するのではなく、NSOperationのサブクラスを使用します。これは、独自のスレッドを管理するよりもはるかに簡単です。
それは悪い習慣です。アプリのデリゲートは、理想的には、それ自体の責任のみに関心を持つ必要があります。アプリケーションがデリゲートを送信するメッセージに応答します。他の個別の責任を他のオブジェクトに分割する方がはるかに優れています。たとえば、サーバーとの定期的な通信を担当する「接続マネージャー」オブジェクトを作成できます。アプリが一度に 1 つのサーバーにしか接続しないことが確実な場合は、シングルトン パターンを使用して、アプリケーション内にオブジェクトのインスタンスが 1 つだけ存在し、他のクラスから簡単にアクセスできるようにすることをお勧めします。アプリ デリゲートとシングルトンの適切な役割については、Singletons, AppDelegates and top-level data で詳しく説明されています。シングルトンの記述に関する優れた一般的な概要は、シングルトンのケアと給餌。