That's strange, since apple says that there is somewhere an main function. But I really can't find any.
It should look somehow like this:
#import <UIKit/UIKit.h>
int main(int argc, char *argv[])
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, nil);
[pool release];
return retVal;
}
What file is that where I can see it? Is it hidden?
It's always in the Other Sources group of your pregenerated project layout.
(source: lyndir.com)
If you can't find it, you can always just create a new code file and copy in this function. When the project compiles, it will only allow you to have one main function, so if it disappeared at some point, you can just re-add it.
Alternately, you might have picked a project type that does not compile down to an executable. Not sure if/what these might be for iphone, but normally a "library" project will not have a main function.
Expand "Other Sources" in the Groups and Files section and the file is named main.m .
Related
I have two complete projects. One works on iPhone and the other works on iPad. I want to merge these into a Universal app.
So far the only solution I have is to rename app the classes with '_iPhone' and '_iPad' suffixes and change all references to those in the code. Then I could merge the AppDelegates and load the correct controllers at launch.
These are two very big projects so this method is going to be very time consuming. Does anyone have a better solution?
well as far as i know the only solution to do that is to create a new universal project and put your files there .. since there is a lot of share code between iPhone and iPad you can check what the device is used to running your app by check if UI_USER_INTERFACE_IDIOM()is UIUserInterfaceIdiomPad or UIUserInterfaceIdiomPhone .. and for the rename the easy way to do that to highlight the class name and select Refactor>Rename and xCode will take care about rename class name in every where you used it.
Your drafted solution seems to be the only option I know of - curious to see other answers.
One thing though; you could actually keep two separate AppDelegates.
Within your main-implementation, you could check the device and launch either the iPad-AppDelegate or the iPhone-AppDelegate.
int main(int argc, char *argv[])
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
int retVal = 0;
if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
{
retVal = UIApplicationMain(argc, argv, nil, #"XXXAppDelegate_iPad");
}
else
{
retVal = UIApplicationMain(argc, argv, nil, #"XXXAppDelegate_iPhone");
}
[pool release];
return retVal;
}
In most cases however, I would advice to rethink such solution - often enough this results into inconsistencies and/or code replication. Still, I thought I should point out the option.
I'm new to Xcode 4.2 and since my project is almost finished, I thought I'd try some of the Instruments Apple provides. So, I ran Leak, and apparently, it found a leak directly at the app start. I get a solid orange vertical bar in the "Leaks" section, and when I investigate, it appears that this is the culprit:
int main(int argc, char *argv[])
{
#autoreleasepool {
//problem appears on the line below in Orange
return UIApplicationMain(argc, argv, nil, NSStringFromClass([TestProjectAppDelegate class]));
}
}
Since I'm new to this, I have no idea what the problem is, how to solve it, or even if I'm finding the actual issue!
(Isn't there supposed to be a "drain" call somewhere?)
Any help would be greatly appreciated.
EDIT
Link to screenshot file: http://whoit.home.comcast.net/~whoit/combined.jpg
(too big to embed)
Click invert call tree in Leak's option pane.
And also, maybe you could add the screenshot for this view if possible:
Replace the entire #autoreleasepool block with this:
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, NSStringFromClass([TestProjectAppDelegate class]));
[pool release];
return retVal;
If you still see the same leak, then you've got an over-retain issue somewhere else in your code and this section is not the issue. If you don't still see it (unlikely), then there could be something wrong with this new language construct. Highly unlikely, but this IS a new construct so there could certainly be bugs.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Is there any reason to modify the main.m file in your iOS applications?
I am new in the iphone applications development and I want to know why we don't actively use the main.m file in the iphone programming. I saw in the many books the following usage:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:
int main(int argc, char *argv[])
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, nil);
[pool release];
return retVal;
}
iOS programs do start from a main() function, usually found in a file called main.m. You might have trouble locating this file, because it's normally in a group called Other Sources, not the Classes group where most code ends up.
In most iOS programs, main() does little more than call UIApplicationMain(), which creates the application object and runs the main event loop.
I don't know the precise details of why it's done like that, but I'll hazard a guess that a lot of framework-dependent stuff will break if you try to call it before the event loop gets going.
The main.m is used just as an entry point for your application (it starts from there), the whole life cycle is handled in Objective C classes.
The method application:didFinishLaunchingWithOptions:, that belongs to Application's delegate, is used to execute code once the app is ready.
ps: you should try to improve your english, since it's hard to read and understand :P
You can read about the main function here. It's not that you don't modify the main file, you do it very rarely. I have modified main function in past when I needed a custom UIApplication subclass.
int retVal = UIApplicationMain(argc, argv, #"CustomApplication", nil);
In general programming, you'd never need to modify the main class, however if you have any special requirements, you can go ahead and do that.
My app takes too much time to loading.
So I put a NSLog in main() function like this to measure loading time from first:
int main(int argc, char *argv[])
{
NSLog(#"main");
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, nil);
[pool release];
return retVal;
}
But, the log displayed at really later time.
Default.png displayed about 5 seconds, all loading process completed in 1~2 seconds after log appeared.
What's happening before executing main() function on iPhone app?
The entry point of a binary is not main(), but start. This is true for most binaries compiled with gcc. When there are static variable constructors in C++, or functions with __attribute__((constructor)) attribute, or +load methods, they will be run before main().
Some code will run even before start, because of dynamic linking. The dyld is responsible for this. All undefined external symbols are filled in at this point. And of course, the initializers of these libraries will execute.
The Default.png is shown by SpringBoard, and is not controlled by your app. Thus there can be a time delay between the Default.png is shown, and code is actually running.
These actions, however, are fast. The delay is more likely introduced by attaching to the remote gdb and Xcode.
in the main.m file:
int main(int argc, char *argv[]) {
NSAutoreleasePool *pool = [NSAutoreleasePool new];
UIApplicationMain(argc, argv, nil, #"AppController");
[pool release];
return 0;
}
I just add the cocos2d sample test code to my project, and there're so many AppController delegate in those files.
So how can I know which "AppController" of delegate is used?
The project for cocos2d example has a lot of build targets.
Scroll down in the Groups & Files pane on the left, until you find the "Targets" group.
Unfold that and look at the individual targets.
All the actual example code uses "...Test" as a name.
When you check in one of the build targets, it will have a group named "Compile Sources" which holds the files that will be compiled for that target.
In the .m file you find there, you will find the implementation of "AppController" used for this target.