Re: Seeing nil passed to isEqual:, despite non-null declaration

[Quincey Morris]

On Jan 13, 2017, at 10:59 , Sean McBride  wrote:
> 
> I'd say the header is in error in the sense that it should have nullability 
> specified.

You may be right, but my post was an *informal* comment in the sense that you 
seemed to be asking whether a nil parameter value was something unexpected, and 
I was trying to say that, historically, no, I’m not aware of the need to make 
any particular assumption.

The second part of my post was intended to point out that any attempt to 
formalize this is going to be difficult due to existing code. If you read the 
clang document, things start to get tricky, because the annotations impinge on 
at least these aspects:

— The expectations of the caller about what may be passed.

— The expectations of the implementer about how to handle values that are 
passed.

— The difference between error detection and undefined behavior.

— The difference between a parameter annotation and a pointer annotation (which 
I wasn’t aware of until I read that document today).

— The semantics of the call, separate from syntactic clues. (For example, 
according to the documentation, it would be a semantic violation for the method 
to ever return YES if the parameter was nil. That’s a separate issue from 
whether the parameter can be nil.)

So, for all these reasons, I would assume the correct annotation would be 
“_Null_unspecified”, which is clang’s way of just shrugging, and I would assume 
the lack of explicit annotation would default to this.

I probably should have just omitted the second part of my post, since I didn’t 
realize that there was some question about the assumed nullability macros in 
different versions of the header, or how the method translates into Swift 
(which is the source of all the nullability fuss to begin with).

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Seeing nil passed to isEqual:, despite non-null declaration

[João Varela]

Hi Sean

Yes, I was bitten by that too, very, very recently, when I was translating a 
few files into Swift and I got warning when I didn’t use an optional for the 
object of the method.

Actually, I suspect that’s a bug in the headers, or probably that’s a 
non-audited header for nullability.

Although isEqual: is part of the NSObject protocol and isEqualTo: is part of 
the NSComparisonMethods protocol of NSObject, the latter expects a nullable 
receiver (check that in NSScriptWhoseTests.h). Check the Swift version of it 
and you will see that isEqual(to: Any?) expects an optional. Therefore, I 
suspect that the same is true for isEqual: and that this API has not yet been 
audited for nullability.

Perhaps you should file a bug against that header.

João



> 
> 
> NSObject.h declares:
> 
> - (BOOL)isEqual:(id)object;
> 
> Note the parameter is not nullable.  And yet, I'm seeing nil passed to one of 
> my class's overrides of isEqual: when I invoke Edit>Undo.  Backtrace:
> 
> #4-[RRLookupTable isEqual:]
> #5-[NSManagedObject(_NSInternalMethods) _updateFromUndoSnapshot:] ()
> #6-[NSManagedObjectContext(_NSInternalChangeProcessing) _undoInsertions:] 
> ()
> #7-[_NSUndoStack popAndInvoke] ()
> #8-[NSUndoManager undoNestedGroup] ()
> #9_os_activity_initiate ()
> #10   -[NSApplication(NSResponder) sendAction:to:from:] ()
> #11   -[NSMenuItem _corePerformAction] ()
> #12   -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] ()
> #13   _os_activity_initiate ()
> #14   -[NSMenu performKeyEquivalent:] ()
> #15   routeKeyEquivalent ()
> #16   -[NSApplication(NSEvent) sendEvent:] ()
> #17   -[NSApplication run] ()
> #18   NSApplicationMain ()
> #19   main
> 


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Seeing nil passed to isEqual:, despite non-null declaration

[Sean McBride]

On Fri, 13 Jan 2017 10:51:18 -0800, Jens Alfke said:

>So Quincey is actually correct — isEqual: has unspecified nullability,
>and the header is not in error.

I'd say the header is in error in the sense that it should have nullability 
specified.  Quite surprising that it's not done by now.

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Seeing nil passed to isEqual:, despite non-null declaration

[Sean McBride]

On Fri, 13 Jan 2017 10:43:09 -0800, Ben Kennedy said:

>> Did I miss a change in clang that made the default “not nullable”?? I
>read the above declaration as meaning that the nullability is
>*unspecified*, which implies that nil is allowed.
>
>NSObject.h (from which Sean was quoting) begins with
>NS_ASSUME_NONNULL_BEGIN which, to my understanding, makes everything in
>the file be non-nullable unless otherwise annotated.

I was going to say the exact same, but in fact usr/include/objc/NSObject.h does 
*not* contain NS_ASSUME_NONNULL_BEGIN, which I find quite surprising!  
Foundation's NSObject.h *does* however.  What a mess.

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Seeing nil passed to isEqual:, despite non-null declaration

[Jens Alfke]

> On Jan 13, 2017, at 10:43 AM, Ben Kennedy  wrote:
> 
> NSObject.h (from which Sean was quoting) begins with NS_ASSUME_NONNULL_BEGIN 
> which, to my understanding, makes everything in the file be non-nullable 
> unless otherwise annotated.

You’re looking at . But the -isEqual: method is actually 
declared in , which does _not_ have the 
NS_ASSUME_NONNULL_BEGIN. (I hadn’t noticed that before.)

So Quincey is actually correct — isEqual: has unspecified nullability, and the 
header is not in error.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Seeing nil passed to isEqual:, despite non-null declaration

[Ben Kennedy]

> On 13 Jan 2017, at 10:34 am, Quincey Morris 
>  wrote:
> 
> Did I miss a change in clang that made the default “not nullable”?? I read 
> the above declaration as meaning that the nullability is *unspecified*, which 
> implies that nil is allowed.

NSObject.h (from which Sean was quoting) begins with NS_ASSUME_NONNULL_BEGIN 
which, to my understanding, makes everything in the file be non-nullable unless 
otherwise annotated.

b


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Seeing nil passed to isEqual:, despite non-null declaration

[Quincey Morris]

On Jan 13, 2017, at 09:46 , Sean McBride  wrote:
> 
> NSObject.h declares:
> 
> - (BOOL)isEqual:(id)object;
> 
> Note the parameter is not nullable. 

Did I miss a change in clang that made the default “not nullable”?? I read the 
above declaration as meaning that the nullability is *unspecified*, which 
implies that nil is allowed.

It’s also instructive to read the formal definitions of the attributes:

http://clang.llvm.org/docs/AttributeReference.html#null-unspecified 


which says that nullability might be unspecified in cases where it cannot 
properly be determined. Note also that there are different attributes for 
saying that passing nil is illegal, and passing nil is undefined behavior.

As far as I’m aware, it’s always been possible to pass nil as the parameter to 
“isEqual:”. For that reason, the unannotated method declaration can’t imply a 
nullability attribute now, other than “unspecified”, because that would break 
reams of existing code.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSNetServiceBrowser vs. mDNSResponder

[Alastair Houghton]

On 13 Jan 2017, at 09:40, Gerriet M. Denkmann  wrote:
> 
> iOS (10.2) app does:
> 
> SERVICE_TYPE =  1 to 63 ascii chars; no spaces; no ‘.’; no ‘[‘; can use ‘_' 
> or '-'; case insensitive
> Note: I did not find these rules documented anywhere, they are just the 
> result of trial and error.

[snip]

> If SERVICE_TYPE is more than 63 chars, then 
> -[NSNetServiceBrowserDelegate netServiceBrowser:didNotSearch:] will complain 
> with BadArgument.
> 
> Now I see in iOS 10.2 (maybe was there before):
> com.apple.mDNSResponder AllINFO 
> Bad service type in ._GmdEcho890123456._tcp.local. Application protocol name 
> must be underscore plus 1-15 characters. See 
> 
> 
> But it still works.
> 
> So:
> 
> 1. what is the real constraint of SERVICE_TYPE:
> 1a: underscore plus 1-63 characters (NSNetServiceBrowser)
> 1b: underscore plus 1-15 characters (mDNSResponder)
> 
> 2. is this documented anywhere?

The 63 character limit is from the DNS, specifically RFC 1035 section 2.3.1, 
which says:

  Labels must be 63 characters or less.

This applies to each label in a domain name.

The 15 character limit is specific to SRV records and comes from RFC 6763, 
section 7.2, which says:

  The Service Name  may be up to 15 bytes, plus the underscore…

I don’t know if *Apple* has documented these anywhere in its documentation, but 
they are certainly in the relevant RFCs.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: What do NSArrayController, etc. do for me?

[Quincey Morris]

On Jan 13, 2017, at 09:52 , Charles Srstka  wrote:
> 
> What does NSObjectController do? Well, not a lot, but what it does is pretty 
> helpful:

There’s one other obscure thing that NSObjectController does (or did, since I 
don’t know if this situation still exists, but I doubt the bug will ever be 
fixed). When you bind a text field directly to an undoable model property, the 
undo chain gets messed up after certain combinations of undo and redo. There 
are actually two undo chains involved, because the window maintains an internal 
undo chain for typing which is grafted onto the top of your app’s undo chain 
while editing is in progress. For some reason, binding through a 
NSObjectController eliminates the problem in most cases.

There are a few other things that NSArrayController can usefully do that you 
didn’t mention explicitly:

— As well as shadowing the table view’s selection, it provides markers that 
represent “multiple selection” and “no selection” that Cocoa bindings are aware 
of.

— It supports the more intricate set of bindings that (say) NSPopupButton uses 
for its menu items’ checked and enabled states, and item text. Some of these 
things, if used, are required to be bound via array controllers.

— It has a standardized mechanism for handling validation errors, including the 
display of an error dialog.

In general, NS…Controller classes are glue classes that support the behavior of 
Cocoa bindings. That means, in general, when you use bindings, it’s desirable 
to bind via a NS…Controller for consistent UI behavior.

(OTOH, NS…Controller classes are horrible, inscrutable black boxes. But that’s 
a different rant.)

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Seeing nil passed to isEqual:, despite non-null declaration

[Sean McBride]

On Fri, 13 Jan 2017 09:53:25 -0800, Jens Alfke said:

>So yes, the parameter should be declared as `nullable`.

Thanks, 

Sean



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Seeing nil passed to isEqual:, despite non-null declaration

[Sandor Szatmari]

I was thinking, and I'm guessing there were no warnings and errors in Xcode on 
this line of code, that a clean compile would indicate that the header did not 
match the documentation.  Does this make sense?

Sandor

> On Jan 13, 2017, at 12:53, Jens Alfke  wrote:
> 
> 
>> On Jan 13, 2017, at 9:46 AM, Sean McBride  wrote:
>> 
>> Anyone ever seen nil passed to isEqual:?  Is the SDK declaration maybe wrong?
> 
> Check the class documentation, not just the header. The parameter is declared 
> as:
>anObjectThe object to be compared to the receiver. May be nil, in 
> which case this method returns NO.
> 
> So yes, the parameter should be declared as `nullable`.
> 
> —Jens
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/admin.szatmari.net%40gmail.com
> 
> This email sent to admin.szatmari@gmail.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Seeing nil passed to isEqual:, despite non-null declaration

[Jens Alfke]

> On Jan 13, 2017, at 9:46 AM, Sean McBride  wrote:
> 
> Anyone ever seen nil passed to isEqual:?  Is the SDK declaration maybe wrong?

Check the class documentation, not just the header. The parameter is declared 
as:
anObjectThe object to be compared to the receiver. May be nil, 
in which case this method returns NO.

So yes, the parameter should be declared as `nullable`.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: What do NSArrayController, etc. do for me?

[Charles Srstka]

> On Jan 13, 2017, at 6:39 AM, Daryle Walker  > wrote:
> 
> If my data model supports KVC/KVO, it seems like I should be able to bind my 
> views to my data directly via Cocoa Bindings, without using NSArrayController 
> or NSObjectController or the like. What advantage do those classes give me?

I just realized you were asking about NSObjectController as well, not just 
NSArrayController. What does NSObjectController do? Well, not a lot, but what 
it does is pretty helpful:

- One minor benefit NSObjectController has is that if you end up with reference 
cycles caused by the bindings system, which is a problem I’ve run into from 
time to time, you can just set the object controller’s content to nil in 
windowWillClose: or a similar place, and break everything’s bindings at once so 
they won’t interfere with the teardown. However, by far the most important 
feature of NSObjectController is:

- NSEditor support 
(https://developer.apple.com/reference/appkit/1654405-nseditor 
). This gives 
you a quick and easy way to solve a very annoying problem. Try building this 
simple application from the Xcode non-storyboard template:

https://gist.github.com/anonymous/207330c13c9144c52381d31421574777 


Try making this application, then binding a text field directly to 
AppDelegate’s “foo” property. Then, connect a button to the saveOrSomething: 
method. Now, build and run the app, type something into the text field, and 
click the button. What do you get? Well, chances are, you saw this:

as this is clicked, foo is ''

The didSet on foo was never called, foo was never updated, and consequently 
when you clicked your save button, out-of-date information got saved. Why is 
this? Because NSTextField doesn’t actually update its bindings until editing 
*ends*, either by the user moving the focus to another UI element by clicking 
on another text field or something, or by the user hitting Return. If you hit 
the Return key after typing something in the field, and *then* hit the button, 
you’ll get the behavior you expect:

did set foo to This is a test
as this is clicked, foo is 'This is a test'

However, this is a pretty annoying UI to use, because it’s very easy to forget 
to end editing before performing some action that depends on the results. You 
can end up thinking you were done with something, closing a document, then 
having to go back and set things up again. If you’ve used macOS/OS X for a long 
time, you’ve probably used a few apps that work like this (Xcode suffered from 
this behavior in certain places for a part of its development), and you’ll know 
how aggravating this can be.

Anyway, NSObjectController can come to our rescue. Change the above code to 
this:

https://gist.github.com/anonymous/c30df983f7603c04cf186b6499c7fac1 


Bind the text field to the object controller instead of to AppDelegate, build 
and run. Type something in the text field, don’t hit Return, and click the 
button. You’ll get:

did set foo to this is a test
as this is clicked, foo is 'this is a test'

Now, when your save method is called, anything that was currently being 
operated upon by a UI element will be updated for you, ensuring that your 
actual save operation writes up-to-date data. Nice!

Note: If you’re using storyboards instead of old-school XIB files, your “File’s 
Owner” will, in most places, be a view controller. NSViewController supports 
the NSEditor methods itself, including commitEditing(), so in this case you 
don’t need an NSObjectController; you can just bind straight to the view 
controller and call commitEditing() on it when necessary. NSObjectController is 
handy in situations where you don’t have an NSViewController, though.

Charles
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Seeing nil passed to isEqual:, despite non-null declaration

[Sean McBride]

Hi all,

NSObject.h declares:

- (BOOL)isEqual:(id)object;

Note the parameter is not nullable.  And yet, I'm seeing nil passed to one of 
my class's overrides of isEqual: when I invoke Edit>Undo.  Backtrace:

#4  -[RRLookupTable isEqual:]
#5  -[NSManagedObject(_NSInternalMethods) _updateFromUndoSnapshot:] ()
#6  -[NSManagedObjectContext(_NSInternalChangeProcessing) _undoInsertions:] 
()
#7  -[_NSUndoStack popAndInvoke] ()
#8  -[NSUndoManager undoNestedGroup] ()
#9  _os_activity_initiate ()
#10 -[NSApplication(NSResponder) sendAction:to:from:] ()
#11 -[NSMenuItem _corePerformAction] ()
#12 -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] ()
#13 _os_activity_initiate ()
#14 -[NSMenu performKeyEquivalent:] ()
#15 routeKeyEquivalent ()
#16 -[NSApplication(NSEvent) sendEvent:] ()
#17 -[NSApplication run] ()
#18 NSApplicationMain ()
#19 main

Anyone ever seen nil passed to isEqual:?  Is the SDK declaration maybe wrong?

Thanks,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: What do NSArrayController, etc. do for me?

[Richard Charles]

> On Jan 13, 2017, at 9:30 AM, Richard Charles  wrote:
> 
> 
> You can chain array controller together.

You can chain array controllers together.

Also binding using a controller will work better in Interface Builder than 
binding directly. Binding directly in Interface Builder may have memory 
management issues.

--Richard Charles


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: What do NSArrayController, etc. do for me?

[Charles Srstka]

> On Jan 13, 2017, at 6:39 AM, Daryle Walker  wrote:
> 
> If my data model supports KVC/KVO, it seems like I should be able to bind my 
> views to my data directly via Cocoa Bindings, without using NSArrayController 
> or NSObjectController or the like. What advantage do those classes give me?
> 
> Sent from my iPhone

What does NSArrayController do? A heck of a lot:

- Automatic propagation of an NSTableView without your having to implement a 
data source.

- Automatic handling of sorting. So, if you click on a table header, that 
column is sorted for you without your having to worry about it. This is fairly 
sophisticated, as well; If you had column A selected before you clicked on 
column B, it will remember that, so two items that have an identical value for 
column B will get sorted according to their values in column A.

- Automatic selection management. So, you can bind a UI element to the array 
controller’s selected object, and that UI element’s content will change as the 
array controller’s selection changes. Pretty handy for implementing something 
like Mail.app’s UI where selecting a different e-mail message in the left-hand 
pane updates the right-hand pane with the contents of that message.

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSNetServiceBrowser vs. mDNSResponder

[Jens Alfke]

> On Jan 13, 2017, at 1:40 AM, Gerriet M. Denkmann  wrote:
> 
> SERVICE_TYPE =  1 to 63 ascii chars; no spaces; no ‘.’; no ‘[‘; can use ‘_' 
> or '-'; case insensitive
> Note: I did not find these rules documented anywhere, they are just the 
> result of trial and error.

These are DNS names, so I think the rules are part of the RFCs that define DNS.

Also, this is a better question for MacNetworkProg or Bonjour-Dev, not 
Cocoa-Dev.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: What do NSArrayController, etc. do for me?

[Richard Charles]

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

What do NSArrayController, etc. do for me?

[Daryle Walker]

If my data model supports KVC/KVO, it seems like I should be able to bind my 
views to my data directly via Cocoa Bindings, without using NSArrayController 
or NSObjectController or the like. What advantage do those classes give me?

Sent from my iPhone
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSNetServiceBrowser vs. mDNSResponder

[Gerriet M. Denkmann]

iOS (10.2) app does:

SERVICE_TYPE =  1 to 63 ascii chars; no spaces; no ‘.’; no ‘[‘; can use ‘_' or 
'-'; case insensitive
Note: I did not find these rules documented anywhere, they are just the result 
of trial and error.

fullNameOfServiceType = “_SERVICE_TYPE._tcp."
[ NSNetServiceBrowser searchForServicesOfType: fullNameOfServiceType  inDomain: 
… ];

If SERVICE_TYPE is more than 63 chars, then 
-[NSNetServiceBrowserDelegate netServiceBrowser:didNotSearch:] will complain 
with BadArgument.

Now I see in iOS 10.2 (maybe was there before):
com.apple.mDNSResponder AllINFO 
Bad service type in ._GmdEcho890123456._tcp.local. Application protocol name 
must be underscore plus 1-15 characters. See 


But it still works.

So:

1. what is the real constraint of SERVICE_TYPE:
1a: underscore plus 1-63 characters (NSNetServiceBrowser)
1b: underscore plus 1-15 characters (mDNSResponder)

2. is this documented anywhere?

Gerriet.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com