Understanding the docs. UIApplication for iOS

  • What I'm used to in Apple's iOS class reference docs are listings at the top of the file that specify the objects inherited from and protocols conformed to.

    I'm either missing something with UIApplication, or the docs are.

    Referring to this class reference document:
    https://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIAp
    plication_Class/Reference/Reference.html


    It's not listed that the UIApplication class conforms to the UIApplicationDelegate, but it is mentioned that the delegate exists and is "defined" by the UIApplication.

    In fact, in the .h file, it obviously extends UIResponder to conform to the UIApplicationDelegate, but you actually can't tell this by eyeballing the docs.  It's not listed at all until you read the overview.

    Shouldn't this be included in the "Conforms to" section at the top of the class reference, while stating that it is conformed to through an extension to UIResponder?

    It just seems odd that a fundamental part of UIApplication (the delegate protocol) isn't mentioned in area of the doc that normally lists it.

    If this is a doc bug, I'll gladly report it, but I'd like to make sure it's not my oversight first.

    Thoughts?
  • On Jun 3, 2013, at 10:49 AM, Alex Zavatone <zav...> wrote:

    > Referring to this class reference document:
    > https://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIAp
    plication_Class/Reference/Reference.html

    >
    > It's not listed that the UIApplication class conforms to the UIApplicationDelegate,
    > In fact, in the .h file, it obviously extends UIResponder to conform to the UIApplicationDelegate, but you actually can't tell this by eyeballing the docs.

    No, it doesn’t:

    NS_CLASS_AVAILABLE_IOS(2_0) @interface UIApplication : UIResponder <UIActionSheetDelegate>

    It does implement/conform to UIActionSheetDelegate; is that what you meant?

    —Jens
  • On Jun 3, 2013, at 1:49 PM, Alex Zavatone <zav...> wrote:

    > What I'm used to in Apple's iOS class reference docs are listings at the top of the file that specify the objects inherited from and protocols conformed to.
    >
    > I'm either missing something with UIApplication, or the docs are.
    >
    > Referring to this class reference document:
    > https://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIAp
    plication_Class/Reference/Reference.html

    >
    > It's not listed that the UIApplication class conforms to the UIApplicationDelegate, but it is mentioned that the delegate exists and is "defined" by the UIApplication.
    >
    > In fact, in the .h file, it obviously extends UIResponder to conform to the UIApplicationDelegate, but you actually can't tell this by eyeballing the docs.  It's not listed at all until you read the overview.
    >
    > Shouldn't this be included in the "Conforms to" section at the top of the class reference, while stating that it is conformed to through an extension to UIResponder?
    >
    > It just seems odd that a fundamental part of UIApplication (the delegate protocol) isn't mentioned in area of the doc that normally lists it.
    >
    > If this is a doc bug, I'll gladly report it, but I'd like to make sure it's not my oversight first.
    >
    > Thoughts?

    Alex,

    Not a doc bug.

    UIApplication doesn't conform to UIApplicationDelegate. The shared instance of UIApplication, though, is the grand poobah object that ensures that UIApplicationDelegate methods get invoked and that all application lifecycle notifications get posted at the appropriate times.

    You *could* write a working iOS application without implementing any UIApplicationDelegate compliant class. Subclass UIApplication and have it do the things that an app delegate would do by writing handlers for all the application notifications that get broadcast. This would be a great learning exercise, and you would come to fully appreciate the value of the UIApplicationDelegate object.

    The docs are correct, though. UIApplication doesn't implement any of the UIApplicationDelegate defined methods, so it doesn't conform to the protocol.

    Bill
  • On Jun 3, 2013, at 3:19 PM, Bill Garrison wrote:

    >
    > On Jun 3, 2013, at 1:49 PM, Alex Zavatone <zav...> wrote:
    >
    >> What I'm used to in Apple's iOS class reference docs are listings at the top of the file that specify the objects inherited from and protocols conformed to.
    >>
    >> I'm either missing something with UIApplication, or the docs are.
    >>
    >> Referring to this class reference document:
    >> https://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIAp
    plication_Class/Reference/Reference.html

    >>
    >> It's not listed that the UIApplication class conforms to the UIApplicationDelegate, but it is mentioned that the delegate exists and is "defined" by the UIApplication.
    >>
    >> In fact, in the .h file, it obviously extends UIResponder to conform to the UIApplicationDelegate, but you actually can't tell this by eyeballing the docs.  It's not listed at all until you read the overview.
    >>
    >> Shouldn't this be included in the "Conforms to" section at the top of the class reference, while stating that it is conformed to through an extension to UIResponder?
    >>
    >> It just seems odd that a fundamental part of UIApplication (the delegate protocol) isn't mentioned in area of the doc that normally lists it.
    >>
    >> If this is a doc bug, I'll gladly report it, but I'd like to make sure it's not my oversight first.
    >>
    >> Thoughts?
    >
    > Alex,
    >
    > Not a doc bug.
    >
    > UIApplication doesn't conform to UIApplicationDelegate. The shared instance of UIApplication, though, is the grand poobah object that ensures that UIApplicationDelegate methods get invoked and that all application lifecycle notifications get posted at the appropriate times.
    >
    > You *could* write a working iOS application without implementing any UIApplicationDelegate compliant class. Subclass UIApplication and have it do the things that an app delegate would do by writing handlers for all the application notifications that get broadcast. This would be a great learning exercise, and you would come to fully appreciate the value of the UIApplicationDelegate object.
    >
    > The docs are correct, though. UIApplication doesn't implement any of the UIApplicationDelegate defined methods, so it doesn't conform to the protocol.
    >
    > Bill

    Thanks for that concise explanation.  It does seem that the auto generated code for the AppDelegate is doing the extension of UIResponder.  Here is the @interface code from my Xcode 4.6.1 iOS app's AppDelegate:

    @interface AppDelegate : UIResponder <UIApplicationDelegate>

    But looking at the header file that Jens pointed out, I see it in the @package and in the +sharedApplication instance as you mentioned.  And at that point, my knowledge of the subject falls short.

    I guess I used the wrong term in asking about this, as it seems more like a doc shortcoming than a bug.

    Yeah, the AppDelegate doesn't conform at all to the Delegate by itself, agreed.

    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?

    In any case, I know about it now, but since the docs are supposed to make these relations clear and this is a standard, it seems like they are falling short a little in this case.

    Just making sure how to properly predict and interpret the docs can take some doing, especially in this case, and this case is present every time you create a new iOS app in Xcode.

    Cheers, and thanks.
  • On Jun 3, 2013, at 1:22 PM, Alex Zavatone <zav...> 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.

    —Jens
  • On Jun 3, 2013, at 4:48 PM, Jens Alfke wrote:

    >
    > On Jun 3, 2013, at 1:22 PM, Alex Zavatone <zav...> 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.
  • On Jun 3, 2013, at 3:19 PM, Alex Zavatone <zav...> wrote:

    > 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”.

    “The UIKit UIApplication object has a delegate, which is a custom object that it’ll tell things to and ask things about. Our AppDelegate class has a single instance, and it registers itself as that object. So if you look up the methods in the UIApplicationDelegate protocol in the UIKit docs, you can implement any of those in the AppDelegate class and it’ll get called by the UIApplication as described in the docs. That’s how you can get notified of stuff like the app going to sleep.”

    Also, couldn’t you find a good book on UIKit development and give that to the new people, instead of having to explain everything yourself?

    —Jens
  • On Jun 3, 2013, at 6:33 PM, Jens Alfke wrote:

    >
    > On Jun 3, 2013, at 3:19 PM, Alex Zavatone <zav...> wrote:
    >
    >> 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”.
    >
    > “The UIKit UIApplication object has a delegate, which is a custom object that it’ll tell things to and ask things about. Our AppDelegate class has a single instance, and it registers itself as that object. So if you look up the methods in the UIApplicationDelegate protocol in the UIKit docs, you can implement any of those in the AppDelegate class and it’ll get called by the UIApplication as described in the docs. That’s how you can get notified of stuff like the app going to sleep.”

    Yeah, that's clear.  It's just that I was assuming that I could easily hop through the class references and put together a little paragraph to explain it just like that.  I guess I just approached the class references the wrong way.

    In reviewing certain class refs last week, I remember running into cases where it a protocol was conformed to by a class, sometimes the top of the class ref would note that it is conformed to through another class.  It was confusing that I didn't see the same when attempting to through the docs.  Using Dash now, searching for "appDelegate" brings me straight to the UIApplicationDelegate Protocol Reference and things are more clearly exposed.

    Sometimes going through the docs ala the organizer is a little less than optimal.

    > Also, couldn’t you find a good book on UIKit development and give that to the new people, instead of having to explain everything yourself?

    There are many good ones out there, that I agree on.

    In any case, thanks much.  Almost back to Couchbase.
  • On Jun 3, 2013, at 4:32 PM, Alex Zavatone <zav...> wrote:

    > In reviewing certain class refs last week, I remember running into cases where it a protocol was conformed to by a class, sometimes the top of the class ref would note that it is conformed to through another class.

    But there isn’t any class in the OS that implements UIApplicationDelegate.) It’s only implemented by application classes. So there’s nowhere that would show up in the system class docs. (The same is true of most delegate protocols.)

    —Jens
  • > Date: Mon, 03 Jun 2013 18:19:43 -0400
    > From: Alex Zavatone <zav...>
    > Subject: Re: Understanding the docs.  UIApplication for iOS
    > Message-ID: <5CF7D8F7-D50C-40C3-95FE-134D88C621E4...>
    > Content-Type: text/plain; charset="windows-1252"
    >
    > 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

    Well, you could show them my description of UIApplicationMain, here:

    http://www.apeth.com/iOSBook/ch06.html#_code

    It explains how the UIApplication instance is created, how the AppDelegate (or whatever it's called) instance is created, and when the latter is sent application:didFinishLaunchingWithOptions:.

    Subsequently, this section talks in more detail about where your app's main window comes from:

    http://www.apeth.com/iOSBook/ch14.html#_the_window

    And the details for a storyboard-based application (an application with a Main Storyboard) are summarized more fully here:

    http://www.apeth.com/iOSBook/ch19.html#SECsivc

    m.
previous month june 2013 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Go to today