7

タブバーアプリがあり、さまざまなタブでCore Locationを使用することを計画している場合、CLLocationManagerの割り当て/初期化に使用するコードを配置し、startUpdatingLocationが呼び出されたら更新を取得するための適切な一般的な場所はありますか?または、2つの異なるタブで使用する場合は、各タブのコードに配置するだけですか?私はプログラミングに不慣れなので、ベストプラクティスは何であるか疑問に思っています。ありがとう。

4

3 に答える 3

5

私はジョンに同意しません。AppDelegateはそれを行うための「簡単な」方法ですが、常に優れているとは限りません。

これはシングルトンで行います。シングルトン、AppDelegates、およびトップレベルのデータに関するMattGallagherの記事を参照してください。

于 2010-10-25T17:36:30.243 に答える
1

自分が書いたものを複製していることに気付いた場合、または存在するコードの記述に直面した場合は、これらのタスクを処理するためのインターフェイス(オブジェクト、集合関数など)を作成することを検討してください。

DRYを参照してください(繰り返さないでください)。いくつかのアプリを作成するまでに、多くの重複する機能があります。一度書いて、正しく書くのが一番です。

ここにいくつかの高レベルのガイドラインがあります:

  • 共通のインターフェースにアプリ固有の機能を配置しないでください(代わりに、2つのプロジェクトで共有されるサブクラスを使用してください)

  • (システムライブラリの問題を扱っている場合を除いて)常に拠点をハッキングしないようにしてください。クライアント(サブクラス、呼び出し元など)が特定の回避策を必要とする場合、または特定のチェックを必要とする場合は、クライアントにそれを処理させることをお勧めします。

  • アサーションを使用して、意図したとおりにインターフェイスを使用していることを確認し、すべての引数、前提条件/事後条件、オブジェクトの状態などを確認します。

  • オブジェクト/インターフェースを非常に小さく、保守しやすくし、使用目的を明確にします。当然、これによりオブジェクトの数が多くなります。

  • シングルトンと静的データを使用したいという衝動を避けてください。クライアントにクラスのインスタンスを作成させるのと同じくらい簡単な場合でも、ほとんどの場合、より良い方法があります。

  • これらのインターフェイスを使用してライブラリを作成し、論理的に分割します。

これでカバーされました…</p>

まず、必要なオブジェクトの(場合によっては複数の)インスタンスを使用します。ドキュメントには、「オブジェクトの複数のインスタンスを作成しないでください」と記載されているものはありません。

これがプロファイリングで何らかの理由で不十分な場合は、更新が必要なオブジェクト(アプリ内)にメッセージを中継する共有オブジェクトの使用を検討してください

理論的根拠:Appleはすでに実装を最適化している可能性があるため、そうする必要はありません。

最後に、大量の位置情報リクエストを必要とするアプリでこれらのガイドラインを破り、大量の位置情報を表示しました。アプリは、ロケーションマネージャーとロケーション(とりわけ)を保存するインターフェースの背後にある静的データを使用しました。そのため、この場合、メモリとCPUの要求を減らすために、静的データとプライベート(非表示)静的データを使用することになりました。

于 2010-10-25T18:02:37.773 に答える
-3

App Delegateは、このようなデータの中心的な場所です。いつでもアプリデリゲートにアクセスできます[[UIApplication sharedApplication] delegate]

于 2010-10-25T17:30:52.103 に答える