I am creating a unity package which can be used in multiple projects. So the most important thing in that is decoupling and independently working of the package. I want to create it in a way that we just have to import the package and while main app is running the package module will be inactive/not initialized but when its needed the main app call for it and that module initialized and start doing its job and after complete its job it should inform the main app that its job has been completed and the result is passed to main game.
Most of the people are suggesting to implement Event aggregator in other question/forums some what resemble to my issue. But the issue in that after reading Event Aggregator its looks like its a one way communication because only publisher can trigger the event and subscriber will only listen. But in my case i have two way communication, first Main app will call for initialize the module and then that package module pass the data to back to main app after completing job.
They’re not far off. no one said that the module itself shouldn’t also use events. the main app could call for the module and also send it a callback that it can run when its complete. with the callback, the main app has given the module an abstract hook that allows it to send messages back to the main app with it needing to know what those messages actually do, or that its even the main app that its running for. so in fact its not a one way communique, but two-way.
this is how applications and services communicate with each other in patterns such as the MVCS (Model-View-Controller-Service) patten. you can look into StrangeIOC and their Promise feature for an example in concept of how two completely different apps can communicate with knowing exactly who they are communicating with