So CoreHub is an attempt to combine features from both Pipes and LICS
into a single package. To sum it up, it uses a specialized Singleton called the CoreHub to communicate between MultiCore instances with a minimum of fuss.
Public GitHub repository and download here:https://github.com/tinwatchman/CoreHub/
The CoreHub singleton has two methods to send messages: sendMessage
. The sendMessage method - much like sendNotification in the PureMVC facade - sends one-to-many to any currently active interested listeners, while sendMessageToCore sends a message to a single, specific Core. If that Core is not currently active - as in, if that module hasn't been loaded yet - sendMessageToCore stores the message in a queue for delivery for when the Core comes online. This allows modules to be brought up to speed on critical information immediately after being loaded.Key points:
- Like Pipes, keeps messages between Cores distinct from internal notifications by using a different interface/class for its messages (called ICoreMessage.)
- Uses each Core's unique Multiton key to distinguish between them.
- Each Core uses or subclasses a CoreMediator object to interact with the CoreHub singleton, in much the same way Pipes uses the JunctionMediator class as its single point of contact between the messaging system and each Core. Technically, any object that implements the ICoreMediator interface can connect to the singleton. This means that modules utilizing different frameworks (or no framework at all) can still send and receive messages via CoreHub.
- Allows an easy way to tell if a module has been loaded or not through the hasCore method. CoreHub also automatically sends out messages whenever a core is added or removed from the system (of message type BaseCoreMessageType.CORE_REGISTERED and BaseCoreMessageType.CORE_REMOVED, respectively).
- Message queueing: Like Pipes, CoreHub allows messages for inactive Cores to be stored until their modules are loaded. These messages are (by default) sorted by priority. Please note that message queuing only works when using sendMessageToCore - any messages sent via the sendMessage method are (like INotifications) gone as soon as all active, interested Cores have been notified. Both queueing and queue sorting (resulting in the queues being first-in first-out) can be turned off by setting the appropriate flags on the singleton to false.
Still working on the unit tests. Comments and suggestions on the project appreciated. In particular, I'd be very interested to hear your thoughts on this, Cliff. Especially in regards to any improvements you think could be made.