You've implemented your API using StrangeIoC. It's unsupported for now and it's really hard to refactor into the regular patterns. We don't use IoC on any of our projects because it's very hard to maintain. In a case of StrangeIoC, it's very hard to overview overall execution flow. For ex. Zenject can show UML graph for all bindings. But still, it's anti-pattern for a big project from our perspective.
Sorry, at this time we do not have any plans to refactor this. I chose StrangeIoC at the time because it was very easy to isolate code that is "PlayFab" from any architecture code.
Here is the important stuff if you want to factor out StrangeIoC:
1> Look at assets/packages/defaultpackages/PlayFabServer. This is a working example of accepting the Params passed into Unity and making proper use of them.
2> Completely Ignore PlayFabContext. I will be getting rid of this soon, as it is absolutely pointless. I'm not sure why I even bothered doing it in the first place, it is just conversion of our API into signals and commands which IMO is not good practice anyways (so thanks for making me re-examine this, by the way). You are better off directly calling to the PlayFab APIs anyways. So you can literally remove / replace the signal / command calls with actual API calls from the PlayFabSDK.
3> Also have a look at assets/packages/defaultpackages/UnityNetworkingContext: This is how we are starting up the Unity Networking Server and listening for events.
We are barely even using StrangeIoC anyways, and any mediator can almost be copy & pasted into a standard Monobehaviour.
Hope that helps!
1 Person is following this question.
