8

Accountのサブクラスとして表されるCore Data オブジェクト がありNSManagedObjectます。

@interface Account : NSManagedObject

私のアプリ全体は問題なく開発されていますMessageUI.frameworkが、メールを作成するビュー コントローラーを取得できるように を追加すると、すべての地獄が解き放たれます。アプリは正常にリンクおよびコンパイルされ、正常に実行されます。Accountつまり、以前に作業していたオブジェクトとのインターフェースを開始するまでです。次に、これらを取得し始めます。

*** Terminating app due to uncaught exception 'NSInternalInconsistencyException',
reason: '"Account" is not a subclass of NSManagedObject.'
*** First throw call stack:
(0x202b012 ... 0x2385)
libc++abi.dylib: terminate called throwing an exception

この特定の 1 つは、次のことが原因で発生しました。

// we need to insert a new account
Account *newAccount = [NSEntityDescription
                            insertNewObjectForEntityForName:[Account entityName] 
                            inManagedObjectContext:self.managedObjectContext];

MessageUI.frameworkさて、競合の原因には何らかのクラスがあると推測していますが、いくつか質問があります。

  1. アプリは正常にコンパイルおよび実行され、コンパイル時の名前の競合はありません
  2. フレームワークの他のコンポーネントはプレフィックス名前空間 (つまり: MFMailComposeViewController) のように見えるので、理論上の説明は ではないのMFAccountでしょうか?
  3. #import <MessageUI/MessageUI.h>またはを実行していませんが#import <MessageUI/MFMailComposeViewController.h>、後者は調べたところ の定義が見られなかったAccountので、競合の可能性がロードされる理由がわかりません。
  4. 念のため、Core Data クラスを再生成し、すべてのシミュレーター設定をリセットしましたが、サイコロはまだありません。
  5. プロジェクトとビルド設定からフレームワークを削除すると、すぐに問題が修正されます。
4

2 に答える 2

8

これは正確なフレームワークです（クラスは と呼ばれていましたBroadcaster）。この場合、プライベートMessageフレームワークは によってリンクされMessageUI、このフレームワークがAccount実装を提供します。

Account新しいプロジェクトを作成し、アプリ デリゲートのapplication:didFinishLaunchingWithOptions:メソッドに次のコードを追加することで、MessageUI フレームワークがクラ​​スを読み込むことを確認できます。

NSString *account = @"Account";
Class accountClass = NSClassFromString(account);
NSLog(@"accountClass = %@",accountClass);

新しいプロジェクトではこれが印刷されますaccountClass = (null)が、MessageUI を追加すると印刷されますaccountClass = Account。

さらに、class-dumpプライベートMessageフレームワークで使用すると、 のインターフェイス宣言が表示されAccountます。

ここで、質問として投稿に 5 つの項目をリストします。私はそれらに対処しようとします。

  1. フレームワークを操作するためのリンク時のプロセスについては、はっきりとは言えませんが、Messageフレームワークのリンクが弱いため、リンク時にシンボルの重複エラーが発生することはないと思います。
  2. 公開されているものは正しく名前が付けられていますが、文書化されていないものはそうではありません。また、競合するクラスはプライベートMessageフレームワークにあります。
  3. それはまったく問題ではありません。コンパイラは を使用します#importが、実行時にすべてのクラスがアプリケーションとともにロードされ、実行時に強制される「可視性」などはありません。
  4. なし
  5. 他の証拠と一致

一連の行動として、モデルクラスの名前をプレフィックスを持つように変更しました。私は他の解決策を知りません。

于 2012-09-25T03:51:42.470 に答える
0

メッセージ フレームワークがまったく問題ではない可能性があります。このようなことは、何らかの形でモデルを変更した場合など、コア データで予期せず発生する可能性があります。ビルドをクリーンアップし、シミュレーター/ハードウェアにインストールされたテスト アプリを削除して、もう一度実行してみてください。geraldWilliam が名前の変更を提案した理由は、この問題を修正するためだと思いますが、名前を変更する必要はないかもしれません。

このスレッドを確認してください:エンティティの NSManagedObjectModel が見つかりませんでした

于 2012-09-25T03:49:22.087 に答える