On Jun 3, 2013, at 4:48 PM, Jens Alfke wrote: On Jun 3, 2013, at 1:22 PM, Alex Zavatone < email@hidden> wrote: But, if the standard is to create an AppDelegate.h that does so,when creating an iOS app project in Xcode, shouldn't that be up in the UIApplication Class Reference? An explanation with a stipulation stating: "I conform to the UIApplicationDelegate by extending the UIResponder in the auto generated AppDelegate.h"? Or at least something more elegantly worded?
I … don’t understand what you’re getting at. AppDelegate isn’t a system class, It’s just some class in your app that acts as the delegate of the UIApplication. You don’t have to have such a class at all, AFAIK, although it would probably limit what your app could do. Xcode’s templates happen to create such a class for you, because it’s convenient, but that class isn’t in any way fixed so there’s no reason to document it in the class reference.
It’s true that if your app has a class Foo that acts as the app delegate, then that class has to implement the UIApplicationDelegate protocol. But that’s already made explicit in the fact that UIApplication’s `delegate` property has type id<UIApplicationDelegate>. In fact those two statements say the same thing.
I think you might have some confusion about what a protocol is in Obj-C, which might be making it hard to frame your question in terms that make sense to the rest of us.
It's not what a protocol is that's confusing (a neatly packaged set of methods geared for a specific purpose), it's being able to decipher the docs so that we can see which protocols a class (or a subclass of that class we are making) will be using.
Ahh, it's just that the app startup process is more complicated than is easily explained and I'm about to tell the staff, "just ignore the details for now, you put this here and it works". I'd love to explain why it works the way it works and "if you have a problem, here is how you go through the docs to find the answer", but it ends up being more confusing to a new coder to try and make sense of it, so I'm going to shelve trying to explain it for now.
Looking at the docs to try and explain what is going in in the start up process and why we put items in a certain place only makes it more confusing than stating "you instantiate the singleton inside application: didFinishLaunchingWithOptions:".
It is what it is and we deal with it.
|