• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Understanding the docs. UIApplication for iOS
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Understanding the docs. UIApplication for iOS


  • Subject: Re: Understanding the docs. UIApplication for iOS
  • From: Fritz Anderson <email@hidden>
  • Date: Tue, 04 Jun 2013 12:44:11 -0500

On 3 Jun 2013, at 7:37 PM, Alex Zavatone <email@hidden> wrote:

> On Jun 3, 2013, at 7:42 PM, gweston wrote:
>
>> Alex Zavatone wrote:
>>
>>>> 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), ...
>>
>> And yet, that's really not a good definition of what a protocol is. That's closer to a category.
>
> OK, how about what I said + "for the purpose of establishing a formal mechanism for classes to talk to each other"?

I think people are taking care to be precise. Your initial impression was off by a ways, and what you're saying now is still a bit off-center.

_All_ method declarations in class interfaces establish a formal mechanism for objects to communicate with them.

What makes a protocol different is that a class can make a promise to implement a certain API; and a parameter (or whatever) can demand that API without having to specify a particular class. The compiler enforces the promise and the compatibility as best it can.

As for UIApplication and <UIApplicationDelegate>, I'm not sure what you're driving at. The documentation doesn't hint that UIApplication conforms to that protocol. The @interface directive for UIApplication doesn't say it conforms to <UIApplicationDelegate>. That should be enough. It's not fair to expect a class reference to specify what the class isn't.

UIApplication _uses_ an object conforming to <UIApplicationDelegate>, but that no more makes it a delegate than having an NSString property makes it a string.

And you're right, Apple has never provided a documentation system as good as the third-party browsers. (The class browser in Xcode 3 came close.) If you can navigate the class tree, the "complies through" chains become very clear.

	— F

--
Fritz Anderson
Xcode 4 Unleashed: 4.5 supplement for free!
http://www.informit.com/store/xcode-4-unleashed-9780672333279


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


  • Follow-Ups:
    • Re: Understanding the docs. UIApplication for iOS
      • From: Alex Zavatone <email@hidden>
    • Re: Understanding the docs. UIApplication for iOS
      • From: Jens Alfke <email@hidden>
References: 
 >Re: Understanding the docs. UIApplication for iOS (From: gweston <email@hidden>)
 >Re: Understanding the docs. UIApplication for iOS (From: Alex Zavatone <email@hidden>)

  • Prev by Date: Re: Understanding the docs. UIApplication for iOS
  • Next by Date: Re: Understanding the docs. UIApplication for iOS
  • Previous by thread: Re: Understanding the docs. UIApplication for iOS
  • Next by thread: Re: Understanding the docs. UIApplication for iOS
  • Index(es):
    • Date
    • Thread