私は今同じ問題を抱えていました...大きな頭痛の種の後、私はそれを解決しました... :D
(説明が必要ない場合は、サンプルコードとその上の数行を見てください... :D )
問題は、alertView が別のウィンドウを作成し、それをキー ウィンドウにし、alertView のビューをそこに配置することです... FBConnect に再度ログインするように指示すると、ダイアログとすべてが表示され、キー ウィンドウ内に自分自身が表示されます。 . その時点では、alertView のウィンドウです。
そのため、アラートのウィンドウを作成して、それを重要なステータスにする必要があります。私はそれを手動で行う方法を見つけられませんでしたが、幸運にもあなたのためにそれを行います. いつ?実行ループの最後に(実際には少し時間がかかります;))。
解決策は非常に簡単です。アラートの実行ループを終了させます。これを行うには、バックグラウンドで再ログイン メソッドを実行します。
[self performSelectorInBackground:@selector(loginToFaceBook) withObject:nil];
ただし、他に対処すべき 2 つの問題があります。
- 前に述べたように、alertView の混乱 (特にウィンドウ) を実際にクリーンアップするには、少し時間がかかります。だから私たちはそれを待つ必要があります。
- FBConnect が作成するダイアログには内部に webView があり、WebView はバックグラウンドにあるのが好きではないため、メイン スレッドでそれを呼び出す必要があります。
KennyTM は、他の積み重ねられたアラートをチェックすることは不可能であると親切に提案しましたが、私は同意しません... 私はこのコードを使用しました:
BOOL shouldWait = YES ;
// wait for the alert view to dissmiss it's self
while (shouldWait) {
[NSThread sleepForTimeInterval:0.1];
UIWindow *keyWindow = [[UIApplication sharedApplication] keyWindow];
shouldWait = [keyWindow isKindOfClass:NSClassFromString(@"_UIAlertOverlayWindow")];
}
これがパブリックAPIで合法かどうかはわかりません...しかし、キーウィンドウがアラートビューのウィンドウであるかどうかを確認する方法は他にもたくさんあると思います...もう1つ思いつくのは、試してみることですサブビューのいずれかが「UIAlertView」クラスのものであることを確認してください...次のように:
for (UIView *subView in [keyWindow subviews]) {
if (shouldWait = [subView isKindOfClass:[UIAlertView class]) {
break;
}
}
とにかく、それは解決可能な問題だと確信しています...そしてアプリを提出した後、覚えていれば(メモリの問題があります:/)、Appleがこれらの技術のいずれかを承認したかどうかをお知らせします...
もう 1 つは、メイン スレッドでダイアログを「表示」することです。しかし、それは簡単です:
FBStreamDialog* dialog = [[[FBStreamDialog alloc] init] autorelease];
[dialog performSelectorOnMainThread:@selector(show) withObject:nil];
セッションでダイアログを開始したい場合は、メインスレッドでもそれを行う必要があります...
バックグラウンドで実行する「showDialodWhenAppropriate」というメソッドがありました。それは待機を行い、適切なときに、メイン スレッドで呼び出す「showTheDialog」という別のメソッドを呼び出します。
Facebookはおそらくこれを自分で実装する必要があります..しかし、実装するまで楽しんでください. :D