Listener block called multiple times for multiple instances

[naldikt]

Fixed issue where multiple MMWormhole instances would get their listener blocks called multiple times.

Sample:

//  AppleWatch's FileA.swift 

private var wormholeA : MMWormhole = MMWormhole(....)  // new instance

func awakeWithContext(context: AnyObject?) {
    super.awakeWithContext(context)
    self.wormholeA.listenForMessageWithIdentifier( "MYID" , listener : { (object) -> Void in
        println("FileA called")
    })
}

//  AppleWatch's FileB.swift

private var wormholeB : MMWormhole = MMWormhole(....)   // new instance

func awakeWithContext(context: AnyObject?) {
    super.awakeWithContext(context)
    self.wormholeB.listenForMessageWithIdentifier( "MYID" , listener : { (object) -> Void in
        println("FileB called")
    })
}

// Main Application AppDelegate.swift

let wormholeC = MMWormhole(...)
wormholeC.passMessageObject( "" , identifier : "MYID" )

This results to:
FileA called
FileB called // excess call
FileA called // excess call
FileB called

Here's what's happened:

1. wormholeC invokes passMessageObject:identifier:, eventually calls sendNotificationForMessageWithIdentifier:
2. wormholeA wormholeNotificationCallback is triggered, and post notification MMWormholeNotificationName.
3. wormholeA.didReceiveMessageNotification and wormholeB.didReceiveMessageNotification are both triggered since it does not filter where the notification's coming from. This results to the first "FileA called" and "FileB called"
4. wormholeB wormholeNotificationCallback is triggered, and post notification MMWormholeNotificationName.
5. wormholeA.didReceiveMessageNotification and wormholeB.didReceiveMessageNotification are triggered again. This results to the second "FileA called" and "FileB called"

The issue's number (3) and (5) above. For each wormhole instance's wormholeNotificationCallback called, each should only trigger its own didReceiveMessageNotification.

The fix's to ensure registration and posting of MMWormholeNotificationName implements "object" filtering.

[cnstoll]

😵

Lol...yeah, that would do it!

I'd like to test this out a bit, and wrap this in some actual tests for that matter, before merging this in. If you want to take a stab at adding some unit tests to the sample project please feel free, otherwise I'll get to it in the next day or two.

Thanks,

• Conrad

[naldikt]

Hi @cnstoll,

Thanks for taking a look at this PR.

See second commit.
I also pulled the string @"group.com.mutualmobile.wormhole" into a constant so someone outside mutualmobile like me can have easier time to change the bundleIdentifier / groupID to run it.

Feel free to modify this as needed.

[cnstoll]

Looks good to me, thanks again bud.