Priority Ordering of delegates for serving a Class with multiple delegates

It appears that when a class like the following:

" class RoomCaptureViewController: UIViewController, RoomCaptureViewDelegate,ARSCNViewDelegate, MTKViewDelegate, ARSessionDelegate, RoomCaptureSessionDelegate. "

has multiple delegates, the ordering of the priority of each message is delivered to a delegate by a priority sensitive order based algorithm and that one message can be processed by only one delegate and not passed off to other delegates if they don't have the proper entry points. Specifically I noted that changing the order seems to result in a delegate not getting a message that it should be seeing. Is there a "handoff" call that can be made after a delegate has seen a message but needs to pass it off to another delegate for processing? This is a protocol typically utilized in Interrupt handlers for PCIe and other messaging protocols and I have not been able to find a similar capability In the voluminous documentation available for IOS and Mac systems. I would also like to know how a message is dispatched by a class to the particular delegate for which the message was intended. Is there a detailed document that explains how the messaging protocol works that is not so fragmented as to require having multiple monitors open in order to form a coherent picture of the messaging interface for Delegates belonging to a class?

Replies

It appears that when a class like … has multiple delegates, the ordering of the priority of each message is delivered to a delegate by a priority sensitive order based algorithm

I think you might be coming at this from the C# perspective, where delegates are specifically modelled in the language. That’s not true for Swift. In Cocoa delegation is implement by simple callbacks. When you define a class like this:

class MyController: UIViewController, RoomCaptureViewDelegate, ARSCNViewDelegate { … }

the first type listed (UIViewController) is your superclass and the remaining types are protocols. So, this declaration says “MyController is a UIViewController subclass and implements the methods defined in the RoomCaptureViewDelegate and ARSCNViewDelegate protocols.” And that’s all it says.

Given that, it does’t matter what order you list the protocols. Moreover, the protocols have no impact on event delivery. Each subsystem that calls one of these delegate methods makes its own decision as to when to call it.

I’m not sure what’s going on with your real app, but your current theory about message delivery priority is definitely not the issue.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you for your response eskimo! The only thing is that when I reorder the protocols it works better and I don't get a failed screen display (all black) and no consistently well behaved screen traffic from the room scan. reordering there protocol list to the way It originally was presented made a significant difference. A message cannot be sent to ALL of the protocols at once so there has to be an order in which the protocols see the message pass through them individually and severally. To have the message pass through all in parallel could result in threadsafe issues.

BTW I don't work in C#, only C and C++ preferably the Gnu varieties

A message cannot be sent to ALL of the protocols at once

Yeah it can. Well, each protocol implements a different set of methods, so there’s no single ‘message’ involved here. But you can consider a method call to be a message, in which case it’s quite possible for two threads to be running two different methods at the same time.

so there has to be an order in which the protocols

Nope. Lemme illustrate this with an example…

Let’s say you have a class:

class MyClass: NSObject {
}

You want to conform to the Waffle protocol:

protocol WaffleMaker {
    func makeWaffle() -> Waffle
}

struct Waffle {
}

So you add it to your conformance list:

class MyClass: NSObject, WaffleMaker {
      ^ Type 'MyClass' does not conform to protocol 'WaffleMaker'
}

Swift now complains that you haven’t implemented the requirements of that protocol. So you add the makeWaffle() method:

class MyClass: NSObject, WaffleMaker {
    func makeWaffle() -> Waffle { Waffle() }
}

This just adds a method to your class. There’s no queuing or serialisation involved. If someone calls that method, it runs.

Now you want varnished waffles, so you conform to a new protocol:

enum Varnish {
    case gloss
    case matt
}

protocol VarnishSelector {
    func varnishForWaffle(_ waffle: Waffle) -> Varnish
}

class MyClass: NSObject, WaffleMaker, VarnishSelector {
    func makeWaffle() -> Waffle { Waffle() }
    func varnishForWaffle(_ waffle: Waffle) -> Varnish { .gloss }
}

Again, this just adds a second method. There’s no queueing or implicit implicit serialisation between these methods.

The only thing is that when I reorder the protocols it works better

I don’t have a ready explanation for that behaviour, but it’s not because the order of the protocol is relevant.

BTW … only C and C++

In C++ terms, a Swift protocol is kinda like a mixin where some (maybe all) of the methods are abstract, requiring you to implement them.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"