問題タブ [cocoa-design-patterns]

私は経験豊富な開発者であり、Mac開発に不慣れなので、

• 素敵なObjectiveCガイドを読む
• Appleメモリ管理ガイドを読む
• ココアへのアップルのイントロを通過しました
• NSApplicationおよびNSApplicationDelegate参照を確認しました
• 少しめちゃくちゃ

まだ多くのギャップがあり、私は良い読み物を見つけるのに苦労しています。私の質問のいくつかを以下に示します。これらは非常に単純/一般的です。基本的なアプリのブートストラッププロセスと、関連するすべてのクラスについて詳しく説明した、短く簡潔なドキュメントが必要です。ありがとう！

• XCodeによって生成される「デリゲート」には、NSPersistentStoreCoordinator、NSManagedObjectModel、およびNSManagedObjectContextのインスタンスが含まれています。詳細を教えてください。
• デリゲートは「@interfacetests_AppDelegate：NSObject{」と宣言されています。プロトコルが欠落しているのはなぜですか？ネット上に例があります。
• アプリケーションデリゲートがInterfaceBuilder内でインスタンス化されていることがわかります。NSApplicationインスタンスのどこに渡されますか？

現在、作成しようとしているドキュメントの最適な構造を考えています。ドキュメントは基本的に、sqlite をストアとして使用するコア データ ドキュメントですが、Apple が提供する NSPersistentDocument+FileWrapperSupport を使用してファイル ラッパー サポートを有効にします。

ドキュメントは、画像、ビデオ、オーディオ ファイルなどのメディアを多用し、数千のファイルが含まれる可能性があります。だから私がやろうとしているのは、次のような構造を作成することです:

まず、一時ディレクトリを作成し、そこにすべてのメディアを配置するというルートをたどりました。基本的にパスとファイル名「/content/images/image1.jpg」を作成して、保存したファイルラッパーに表示したいので、保存時にこれらすべてをファイルラッパーにコピーしようとしました...

私が見つけたのは、ファイルが実際に必要なファイル構造でラッパーにコピーされたということでしたが、実際のラッパーが保存されると、これらのファイルはすべて魔法のように消えてしまいました。

偉大な。

そのため、既存のソリューションを破棄し、代わりにファイル ラッパーを使用しようとしました。このソリューションには、新しいドキュメントの作成時にコンテンツ ラッパー ファイル ディレクトリを作成するか、ドキュメントを開くときにコンテンツ ディレクトリ ファイル ラッパーをロードすることが含まれていました。

画像が追加/変更されたとき、このルート コンテンツ ラッパー内に必要なディレクトリ ラッパーを作成し (つまり、まだ存在しない場合は画像ディレクトリ ラッパー、または作成する必要があるその他の中間ディレクトリ ラッパー)、通常のディレクトリ ラッパーを作成しました。メディアのファイル ラッパー。そのファイル名の既存のラッパーが存在する場合は削除します。

ドキュメントの保存は、コンテンツ ファイル ラッパーがドキュメント ファイル ラッパーに追加され、ドキュメントが保存されることを確認するための単なるケースでした。

ええと...そうでした。初めて。ただし、その後の変更、つまり画像の追加、保存を試みると、. 次に、画像を置き換えて保存します。期待どおりに動作せず、最初の保存からの画像のみを表示しました。

それで、私の質問は...まず第一に、上記のアプローチのどれが正しいものであるか、そしてそれらが失敗するために私が間違っていることは何ですか.

そして第二に、何千もの画像を管理することを期待しているように、ファイルラッパーを使用して物事を進める正しい方法です。

バインディング/コア データと互換性があり、データのコレクションを表すカスタム ビューを作成しています (NSTableView 風)

ユーザーが変更した後、ビューがコレクション内の要素の特定のサブセット (現在の選択以外) を参照できる方法はありますか?

ちょっとしたコンテキスト:
ビューは、2D 空間にユーザーが移動できる多数のボックスを表示します。各ボックスは、モデル内のレコードに対応しています。いくつかは一度に移動できますが、各ボックスのデルタ値が同じであることに依存することはできません (したがって、選択した各オブジェクトにデルタを追加する必要はありません)。

ビューがそのIDを各ボックスに関連付けることができるように、NSArrayControllerによってコンテンツ配列の各要素に割り当てられたIDのようなものを探していると思います。私が最初に考えたのは、コンテンツ配列でインデックスを使用することでしたが、これは元に戻す/やり直しによって台無しになる可能性があります。NSArrayController をサブクラス化して、各モデル項目の ID を自動生成するようにできますが、cocoa はすでにこのようなことを行っているのでしょうか? 何かが欠けているような気がします。

この大会には何か目的がありますか？

この質問の一見広範に見える性質をご容赦いただければ幸いですが、かなり具体的になります。

Core Data に独自の永続データ ストアを設定できないため、データ ストア (SQLite の変形) に SQLCipher を使用していることを除いて、他のほとんどのアプリケーションと同じように機能するドキュメント ベースの Cocoa アプリケーションを構築しています。また、私は本当にこれを使用する必要があります。

ドキュメント サブクラスには、NSMutableArrayという名前のプロパティがありますcategories。ドキュメント nib では、へのバインドがあり、配列コントローラへのバインドがありますNSArrayController。categoriesNSCollectionView

配列内の各モデル オブジェクト (それぞれがCategory) は、基になるデータ ストア内のレコードにバインドされているため、カテゴリの一部のプロパティが変更されたときに を呼び出し[category save]、カテゴリがセットに追加されたときに、再度 を呼び出し、[category save]最後に、カテゴリが削除されたときに を呼び出します[category destroy]。

私は部分的な解決策を配線しましたが、削除の要件でバラバラになり、それに関するすべてが間違ったツリーを吠えているように思えます。とにかく、ここで何が起こっているのですか：

ドキュメントと nib がすべて読み込まれたら、categories プロパティの観察を開始し、いくつかのデータを割り当てます。

ドキュメントが応答してデータストアを更新できるように、変更が通知されるような方法で監視メソッドを実装しました。

そのリストからわかるように (そして既にお気づきかもしれませんが)、categoriesプロパティを観察するだけでは十分ではありません。個々のカテゴリを観察して、属性 (名前など) が変更されたときにドキュメントに通知されるようにする必要があります。その変更をすぐに保存できること:

これは私には大したことのないように見えます。私はここで Cocoa に反対しているのではないかと思いますが、ほとんどの場合はうまくいきます。

除去以外。インターフェイスにボタンを追加し、それをアレイ コントローラのremove:アクションに割り当てるとcategories、ドキュメントのプロパティからカテゴリが適切に削除されます。

そうすることで、カテゴリがまだ監視されている間に割り当てが解除されます。

[category destroy]さらに、通知を受ける前にオブジェクトの割り当てが解除されたため、オブザーバーから呼び出す機会がありません。

Core Data より前のデータ モデルへの変更を保持するために、NSArrayController と適切に統合するにはどうすればよいでしょうか? ここで削除の問題をどのように回避しますか (または、これは完全に間違ったアプローチですか?)

アドバイスをよろしくお願いします！

StackOverflow の善良な人々、

ドキュメントベースではない Cocoa アプリケーションを構築する初期段階にいます。私が目指しているのは、iTunes に似たウィンドウ レイアウトで、左、中央、右のペインがあります。このようなアプリケーションの Xcode テンプレートには、メイン メニューとメイン アプリケーション ウィンドウの両方を含む MainMenu.xib というファイルが含まれており、サポート ロジックは MyApp_AppDelegate クラスに含まれています。

このルートを継続すると、最終的に非常に大規模でまとまりのないアプリ デリゲート クラスにつながることは既に予測できます。したがって、私の賢明な感覚では、メイン ウィンドウのロジックを独自の NSWindowController サブクラス (および付随する XIB ファイル) に分割するように指示されます。さらに、各ペインを独自の NSViewController サブクラスに分割するのは正しいでしょうか? これは、より多くのファイルとすべてを結び付けるための追加のコードを犠牲にして、私の懸念をより適切に分離するように思われます。

私が見つけることができた最も近いアドバイスは Apple のInterface Builder User Guideにありますが、質問に直接答えることはありません。ただし、私の質問は特に nib ファイルに関するものではなく、高レベルのアプリケーション構成に関するものだと思います。

コアデータをマルチスレッド化するためのAppleの推奨方法は、スレッドごとに管理対象オブジェクトコンテキストを使用し、変更されたスレッドのコンテキストを共有永続ストアに保存することで、あるコンテキストから別のコンテキストに変更を送信することです。

私はそれがうまくいくことを想像することができますが、例えば。RSSリーダー、一部のアプリケーションでは、理想からはほど遠いようです。私の場合、バックグラウンドスレッドを使用してデータを記録および再生するミュージックシーケンサーを作成しています。記録/再生中にメインスレッドにアクセスできるように、記録されたデータが必要です。記録/再生中に常にデータを保存およびロードしなければならないことは十分に悪いことですが、さらに悪いことに、ユーザーが記録または再生するたびに保存を強制するように思われ、「ひどいアプリケーション」と叫びます。

ただし、これを回避する方法があるようです。他のスレッドがコアデータエンティティ自体（それらに含まれるデータのみ）にアクセスする必要がない場合、管理対象オブジェクトコンテキストを独自のスレッドで実行し、UIをバインドするなどして他のスレッドに間接アクセスのみを許可するのを防ぐにはどうすればよいですか？performSelector:onThread:withObject:waitUntilDone:管理対象オブジェクトコンテキストのスレッドを呼び出して値を取得/設定するプロパティへのオブジェクト？

マルチスレッド（つまり、コアデータをマルチコアCPUにスケーリングする）の利点の一部は提供されませんが、多くの場合、集中的な処理が行われているときにUIがロックされないようにマルチスレッドが必要です。

このパターンがコアデータに推奨されているのを見たことがありません。アップルが提案することを正確に行わないと、奇妙で​​予測不可能な獣になる可能性があることを考えると、複数のスレッドが単一の管理対象オブジェクトコンテキストにアクセスすることを思いとどまらせる理由を本当に回避できるかどうかを尋ねる価値があると思いました。

誰かに片付けてもらいたい簡単な質問があります... 自分を保持するのは悪い習慣ですか?

作成したいサーバー要求オブジェクトがあります。以下のような使い方ができるようになりたいです。

自動解放プールが空になるとすぐにオブジェクトが自己破壊しないようにするには、init メソッドで保持を呼び出し、サーバーの応答が受信、処理され、デリゲートに配信されたら解放する必要があると思います。

しかし、このアプローチに関して、私の頭の中で何かが警鐘を鳴らしています。それを行うためのより良い方法は？

ビューのサイズが変更され、ツールチップの相対的なグラフィック要素の場所が変更されました。本当に各ツールチップを削除して、新しいrectで再度追加する必要がありますか？または、どこかに「modifyToolTipRect」がありますか。見つかりませんでした。

特定のモデルに関する情報を知る必要があるドキュメントベースのアプリケーションに、ネストされたオブジェクトのレイヤーがいくつかある状況があります。

具体的には、NSTextView、NSLayoutManager、および NSTypesetter があり、それぞれが正しくレンダリングするためにドキュメント モデルに関する特定のプロパティを知る必要があります。

現在、各クラスをサブクラス化し、モデルへの参照を持つプロパティを与えています。参照はドキュメント コントローラーからサブクラス化された NSLayoutManager に渡され、サブクラス化された NSTypesetter に渡されます。

モデルは Controller->MyLayoutManager->MyTypesetter から渡されます。これは少し冗長なようで、密結合しすぎている可能性があります。

デリゲート パターンの方がよいでしょうか。もしそうなら、それを設定する最良の方法は何ですか? Typesetter にはデリゲートがありませんが、LayoutManager には既にデリゲートがあります。Typesetter にデリゲートを追加してから、LayoutManager でデリゲートをオーバーライドする必要がありますか? それとも、モデルのインターフェースを継承することに固執する方がよいのでしょうか?

任意の洞察をいただければ幸いです。ありがとう。