Service.addObserver(owner: closure:) Allows multiple observers for self

[bustoutsolutions]

Service.addObserver(owner: closure:) Allows multiple observers for self

[pcantrell]

The problem is that Swift has no notion of closure identity or comparison: there’s no way for Siesta to know that you’re adding “the same” closure twice, because there’s no such thing as “the same” closure.

If you add an observer that’s an object, then Siesta will prevent dups. But otherwise, it’s up to you to make sure you don’t add redundant observers — by adding them in viewDidLoad instead of viewWillAppear, for example.

[pcantrell]

Prompted by this, I added some information about duplicate observers to the API docs. Thanks for the good question!

Also, an aside on the code you posted: in Swift, when the last arg is a closure, you can place it as a block after the method call. So instead of this:

MyAPI.resource('/home').addObserver(owner: self, closure: {
    [weak self] resource, event in
    print(event)
})

…you can do this:

MyAPI.resource('/home').addObserver(owner: self) {
    [weak self] resource, event in
    print(event)
}

You may already know that, but I though I’d mention it just in case.

[MPiccinato]

That makes a lot of sense with Swift. I guess from the API of a Siesta Service class I made an assumption that 'self' would be the qualifier for adding an extra observer to that resource. Is there a use case to adding multiple 'self' owners to a specific resource?

[pcantrell]

The owners are about lifecycle, not uniqueness. When the owner goes away, the observer stops observing. When you want to remove observers, you do it by owner. There’s a detailed explanation in the docs.

Is there a use case to adding multiple 'self' owners to a specific resource?

Observers have owners, not resources, so I’m not quite sure what you mean by that. I’m guessing you mean, “Is there a use case for having multiple observers with the same owner?” If so, then sure; in fact, it’s quite common. For example, a view controller might might do this:

foo.addObserver(self)
bar.addObserver(self)
bar.addObserver(owner: self) {
    [weak barDisplayerWidget] in
    barDisplayerWidget?.refresh()
}

Here, the VC depends on two resources, so it observes both of them (as a self-owned observer). It also owns a barDisplayerWidget that wants to observe the second resource. All three observers are owned by self, so when the VC is deallocated, Siesta automatically stops sending events to all of them.

This also has the advantage that you can remove multiple observers at once:

for resource in [foo, bar] {
    resource.removeObservers(ownedBy: self)
}

…which is a common idiom when one VC wants to change which resource it’s observing. There’s an example of this in the sample project.

[MPiccinato]

I understand now with that example. My pattern was to only have one observer per a resource per a controller. Having multiple closures available I can see being helpful. I will switch to using the just addObserver(self) for my current case and implementing ResourceObserver protocol.