Bdtjtk

I believe the answer to this question is "no", but I'm putting it out to the community just in case someone has been more successful than I have.

I have a privileged helper tool that a client Cocoa application uses with the NSXPCConnection and NSXPCInterface. The interface itself includes a method that provides a return code through a completion handler block.

In Objective-C the client code looks like this:

NSXPCConnection * xpcConn = [NSXPCConnection alloc] 

    initWithMachServiceName:kSvcName 

    options:NSXPCConnectionPrivileged];



// MyProtocol defines an instance method runCommand:(NSString*) withReply:^(int result)

NSXPCInterface * mySvcIF = [NSXPCInterface interfaceWithProtocol:@protocol(MyProtocol)];



xpcConn.remoteObjectInterface = mySvcIF;

[xpcConn resume];

if (nil == xpcConn.remoteObjectProxy) {

    NSLog(@"ERROR - remote interface is nil, can't communicate with service");

}



[[xpcConn remoteObjectProxy] runCommand:nsstrCmd withReply:^(int result) {

    NSLog(@"service result is: %d", result);

    if (result != 0) {

        self.svcResult = result;

        self.svcCommandComplete = YES;

    }

}];

I also have a pyobjc / py2app Mac application that needs to use this helper tool's functionality. I've got the tool built into the pyobjc app bundle, signed, and authorizing via SMJobBless, but it is looking like there are several problems that make actual use of this API unsupported:

1) Bridging the invocation of runCommand:withReply:^ doesn't seem to be supported - if I understand correctly blocks are only supported for NS* framework method invocations not for 'custom' (i.e. user-defined) methods? Note, I could make a version of the method with no return code if this was the only blocking issue, but an attempt didn't quite work because...

2) In order to use the API in the way the Objective-C does I need to create a @selector reference to runCommand: that does not actually have any python function implementation - it needs to just be a function object that defines the signature for a function that will be furnished by the dynamically created remoteProxy. I don't define the remoteProxy implementation in python. This does not seem to be supported - I could not get the selector declaration without a python function to work via objc.selector().

3) I'm not positive that even if I could get 2) to work, that construction of the formal protocol would work the way it's expected to as a parameter to interfaceWithProtocol: from python - it needs to become a native custom @protocol that NSXPCInterface could use in its factory method to create the remoteProxy.

Thanks for any tips if you've figured out how to do this in pyobjc, or any definitive confirmation that this stuff just isn't possible based on your knowledge of it.

The first two subquestions are straightforward to answer: It is possible to call APIs with blocks, even those in libraries that aren't Apple frameworks. This does require some more work in the python code because the Objective-C runtime doesn't expose enough information to fully automatically do the right thing.

For this particular example you could do something like this:

objc.registerMetaDataForSelector(b'NSObject', b'runCommand:withReply:', {

'arguments': {

    3: {

       'callable': {

          'retval': {'type': b'@'}, 

          'arguments': {

              0: {'type': b'^v'}, 

              1: {'type': b'i'}, 

          },

       },

    }

  }

})

This registers additional information for the method "-[NSObject runCommand:withReply:]". The block argument is number 3: counting starts at 0 and the first two arguments of Objective-C methods are "self" and "_sel" (the latter is not exposed to Python).

You normally use the actual class where the method is implemented, but I expect that this is a hidden class that might even be dynamically generated. Just registering metadata on NSObject should be safe as long as there is no conflict with other classes.

Creating protocols in Python is also possible:

MyProtocol = objc.formal_protocol('MyProtocol', (), [

    objc.selector(None, b"runCommand:withReply:", signature=b"v@:@@?"),

])

And creating the XPC interface with:

mySvcIF = Foundation.NSXPCInterface.interfaceWithProtocol_(MyProtocol)

The latter step sadly enough does not work because NSXPCInterface raises an exception: NSInvalidArgumentException - NSXPCInterface: Unable to get extended method signature from Protocol data (MyProtocol / runCommand:withReply:). Use of clang is required for NSXPCInterface..

I've filed an issue for this in PyObjC's tracker: https://bitbucket.org/ronaldoussoren/pyobjc/issues/256/enable-using-xpcinterface-with-protocols.

A workaround for this issue is to create a Python extension that contains the protocol definition as well as an unused function that uses the protocol (see for example https://bitbucket.org/ronaldoussoren/pyobjc/src/default/pyobjc-framework-Cocoa/Modules/_AppKit_protocols.m for the latter part). After importing the extension you can use objc.protocolNamed("MyProtocol") to access the protocol, which will then refer to the full protocol object created by clang and should work with NSXPCInterface.

P.S. I rarely visit stackoverflow, its often easier to get my attention by mailing to pyobjc-dev@lists.sourceforge.net (PyObjC mailinglist).