Попробуйте:
int main(int argc, char *argv[])
{
NSLog(@"Step 0");
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSLog(@"Step 1");
int retVal = UIApplicationMain(argc, argv, nil, nil);
NSLog(@"Step 2");
[pool release];
NSLog(@"Step 3");
return retVal;
}
Возможно, освобождение пула препятствует дальнейшей регистрации, в этом случае вы получите шаг 2, но не шаг 3.
Если шаг 2 не печатается, то это почти наверняка что-то не так с UIApplicationMain - есть вероятность, что он не вернется, поэтому поместите операторы NSLog (шаг 1.1, шаг 1.2, ...) в различные точки внутри него и запустите, чтобы найти последнее зарегистрированное сообщение.
Продолжайте детализацию (Шаг 1.7.1, 1.7.2, .... 1.7.6.3.2, ...) - в конце концов, вы будете отслеживать точную линию (как бы глубоко в иерархии вызовов), когда сообщения журнала перестают регистрироваться, и эта строка станет вашим виновником (либо «отключение» входа, либо выход без обычного возврата).
Еще один фрагмент, который я нашел в Интернете:
=====
Когда вы используете эту строку:
int retVal = UIApplicationMain(argc, argv, @"MyApp", @"MyApp");
Первый MyApp - это ваш основной класс делегатов приложения. Второй - это класс, куда SpringBoard отправляет сенсорные уведомления.
Кроме того, если вы используете SDK и у вас есть основной кончик, определенный в Info.plist, вы можете оставить вызов как:
int retVal = UIApplicationMain(argc, argv, nil, nil);
как все, что будет рассмотрено, когда вы создадите свои xibs.
=====
Теперь я не знаю достаточно о разработке iPhone (в частности, xibs), чтобы знать, что этот последний бит вообще означает (или если вы настроили его правильно), но это звучит как другая фаза компиляции.
Тем не менее, моя первая мысль при чтении заключается в том, что Springboard будет вызывать ваш класс делегата при нажатии кнопок, чтобы попросить вас что-то сделать (например, отключить изящно). Если он не может спросить вас (т. Е. Не имеет ни одного делегата), возможно, он имеет право закрыть вас так, как считает нужным, например, с [UIApplication _terminateWithStatus:].
В мире Windows вы, вероятно, отправили бы сообщение о выходе в главное окно, но, как я уже сказал, разработка для iPhone может отличаться.
Тем не менее, это проспект для расследования. Мне было бы интересно узнать, какие звонки были сделаны делегату, если вы его предоставили. Код, включенный в приведенный выше фрагмент, имеет следующий код:
@implementation MyApp
- (void) applicationDidFinishLaunching:(id)unused {
rect = [ UIHardware fullScreenApplicationContentRect ];
rect.origin.x = 0.0f;
rect.origin.y = 0.0f;
window = [ [ UIWindow alloc ] initWithContentRect: rect ];
[ window makeKeyAndVisible ];
view = [ [ MyAppView alloc ] initWithFrame: rect ];
[ window setContentView: view ];
}
- (void) dealloc {
[ window release ];
[ view release ];
[ super dealloc ];
}
Так что, возможно, делегат с dealloc() является секретом того, чтобы заставить его вернуться обратно к main(). Почему бы тебе не попробовать? Это может приблизить вас к вашей цели, даже если это не решит основную проблему.