Multiple Message Passing Implementation

[msmollin]

Hello folks! Seems like this library is mostly unmaintained but I figured I'd open this PR for posterity sake incase anyone else needs this.

Issue

The default MMWormholeFileTransiting and its subclass MMWormholeCoordinatedFileTransiting both have an inherent issue where they support enqueuing multiple messages across the wormhole, BUT every time a message is enqueued, it overwrites the message payload. So, when attempting to transit N message payloads across the wormhole (similar to how NSNotificationCenter or any other message bus construct works), you get N messages but only the latest written payload.

Solution

This doesn't work for my use case unfortunately, so thus I present MMWormholeManifestFileTransiting for your inspection and approval. It utilizes the more modern NSFileCoordinator-based approach from MMWormholeCoordinatedFileTransiting but instead of just writing the message to disk and thus overwriting whatever is currently there, it manages a stack (NSArray) of messages that need to be sent across the wormhole which are then dispatched FILO style across the wormhole via pushing and popping the stack.

There's a few potential improvements / optimizations to be made here:

• Implement a FIFO queue management in addition to the existing FILO system. For my use case this would change nothing but I could see it being useful if ordering mattered if delivery is delayed (as my use case of sending data from an ActionExtension is)
• Cleanup synchronization between messages on disk and notifications sent to the app. There's potential for drift here if for some reason the CF notification fails to deliver, as then we'll have messages enqueued in the array with no matching notification. The framework could expect the calling code to handle this case as well if that's an expected problem, which in my testing hasn't happened.

[zorn]

Would you want to pass in an error pointer to find out how it might have failed?

[zorn]

Is there a concern that we are storing a reference to the messageObject and someone might later mutate the message? Do we want to prefer a copy of the object here?

[zorn]

Seems curious that we are making the assumption the array returned for this identifier is always a single item collection. Why are we writing and reading arrays from the file system and not the message object itself?

[zorn]

Seems expensive to read from disk for every call, though I'd probably just make a note of the consideration until it's a measurable issue.