39

(本当の答えを見つけるにはかなりの掘り下げが必要だったので、これは質問と答えの両方です。)

症状:viewWillAppearがviewDidAppearUIViewController で呼び出されませんでした。

UINavigationController原因: or UITabBarController(私の場合) を a に埋め込むと、UIViewController何らかの形でこれらのメソッドの呼び出しが中断されます。

UIViewController解決策:前述のUINavigationController/を含むで手動で呼び出しますUITabBarController。

projectNavigationController例（があなたのものであると仮定UINavigationController）：

-(void)viewWillAppear:(BOOL)アニメーション {
    [super viewWillAppear:アニメーション];
    [projectNavigationController viewWillAppear:アニメーション];
}

-(void)viewWillDisappear:(BOOL)アニメーション {
    [super viewWillDisappear:アニメーション];
    [projectNavigationController viewWillDisappear:アニメーション];
}

-(void)viewDidAppear:(BOOL)アニメーション {
    [super viewDidAppear:animated];
    [projectNavigationController viewDidAppear:animated];
}

-(void)viewDidDisappear:(BOOL)アニメーション {
    [super viewDidDisappear:animated];
    [projectNavigationController viewDidDisappear:animated];
}

私の場合、インナーがUITabBarControllerあり、それに応じてメソッドを呼び出し、すべてが解決されました。

(ソリューションの帰属: http://davidebenini.it/2009/01/03/viewwillappear-not-being-called-inside-a-uinavigationcontroller/ )

4

2 に答える 2

11

I'm going to go ahead and disagree with @St3fan, and use UIKit as the counter-example.

However, the wisdom (or lack thereof), of embedding controllers in general should be guided by sane UI design principles.

The easiest counter-example is UINavigationControllers embedded in UITabBarControllers. These appear all over the place. Just off the top of my head, the iPod app on iPhone, and Contacts within the Phone app on iPhone.

I was curious enough to bother to check what they do with the views (add to the "super-controller" view or to the UIWindow. I was pretty sure I was going to find that the sub-controller views were descendants of the super-controller views in the view hierarchy, which is contrary to St3fan's recommendation.

I whipped up a very quick iPhone app hooking everything up in InterfaceBuilder to create a UITabBarController based app with two tabs, the first of which was a UINavigationController with a plain ole UIViewController as it's root view controller, and a 2nd tab with a plain old UIViewController just so I had a 2nd tab to click later.

Sprinkle in some NSLog statements to output the various UIView's for the controllers we see this:

tabBarController.view = <UILayoutContainerView: 0x5b0dc80; ...
navigationController.view = <UILayoutContainerView: 0x59469a0; ...
rootViewController.view = <UIView: 0x594bb70; ...
Superview: <UIViewControllerWrapperView: 0x594cc90; ...
Superview: <UINavigationTransitionView: 0x594a420; ...
Superview: <UILayoutContainerView: 0x59469a0; ... // navigationController.view
Superview: <UIViewControllerWrapperView: 0x594b430; ...
Superview: <UITransitionView: 0x5b0e110; ...
Superview: <UILayoutContainerView: 0x5b0dc80; ... // tabBarController.view
Superview: <UIWindow: 0x5942a30; ...

The lines prefixed with "Superview" were the output from walking up the rootViewController.view's superview chain until hitting nil.

Then of course a quick glance at the call stack in a couple of places where viewDidDisappear would get called on the root view controller.

First, the call stack when viewDidDisappear is called on the root controller as a result of a new controller being pushed on to the stack:

-[RootController viewDidDisappear:]
-[UINavigationController navigationTransitionView:didEndTransition:fromView:toView:]
...

Second, the call stack when another tab is selected in the top-most UITabBarController:

-[RootController viewDidDisappear:]
-[UINavigationController viewDidDisappear:]
-[UITabBarController transitionFromViewController:toViewController:transition:shouldSetSelected:]

So in all cases, it seems that Apple decided that controllers should be calling the various viewDidAppear, etc methods on their embedded subcontrollers and that the view's should be embedded similarly. I think the OP hit this nail right on the head if we're to take UIKit design as a good lead to follow.

于 2010-08-25T04:40:57.537 に答える
0

私はちょうどこれと同じ状況を見ました。以前は、テーブルセルの選択によってトリガーされたInterface Builderのセグエが機能しなくなり、コードを少し苛立たせた後、テーブルビューデリゲートのセル選択オーバーライドから呼び出して手動で設定しました。

後で、呼び出されたView Controllerでレイアウトを変更したところ、上記のように、viewDidAppearが呼び出されていないことがわかりました。デバッグ出力は「ネストされたプッシュ操作」などを参照していましたが、手動プッシュ操作で自分自身に大きなコメントがあったので

#warning I SHOULD NOT HAVE TO DO THIS!!

セグエコードにブレークポイントを設定すると、確かにIBセグエが機能し、呼び出されたビューでデリゲート呼び出しを台無しにしていたのは、テーブルセル選択コードでの手動操作でした。手動コードを削除しましたが、すべて問題ありません。

ビューがプッシュされた後にセル選択コードが呼び出されるのは奇妙に思えます。呼び出し元で選択したセルのインデックスパスを取得するには、プロトコルと委任を実行する必要があります。

于 2012-01-15T09:43:28.223 に答える