[RELEASED] StrangeIoC - Inversion-of-Control Framework for Unity C#

Community Showcases
1

Unity…it’s time to get STRANGE!
Today, Third Motion, Inc. open sourced StrangeIoC, a super-lightweight and highly extensible Inversion-of-Control micro-framework, written specifically for C# and Unity.

Site: StrangeIoC
GitHub repo: GitHub - thirdmotion/strangeioc
Submission to Unity Store pending (will be free).

KEY FEATURES- Dependency Injection

  • Shared pub/sub system
  • View mediation
  • Battle-tested architecture
  • Core binding framework
  • Multiple, modular contexts
  • Comes with two example projects to get you going

KEY BENEFITS- Decoupled, modular code.

  • Rapid development.
  • Good for individuals, great for teams!
  • Works great with Unity MonoDevelop. Also works great without them.

Dependency Injection
Decouple all your class dependencies and write cleaner, modular code with a highly optimized Reflection/Injection system.

Pub/sub system
Each context features an EventDispatcher reachable by any point in code.

View mediation
Insulate your app from the chaos often present in views. Mediation allows clean separation of Views from Controllers and Models with no loss of capability.

Battle-tested architecture
Strange’s architecture is based on the popular RobotLegs micro-framework. This architecture is well founded, highly proven, and lightly urges responsible development that works great for individuals or teams.

Core binding framework
The core of Strange is a simple, highly extensible Binder class. Extend the Binder to create decoupling models that suit your situation. Every component in Strange is an extension of Binder, so there are already many examples to follow.

Multiple, modular contexts
Modular contexts allow you to spin off portions of your project to different teams, then agree on an API and plug-and-play. This simplifies development and decouples whole components of the app for later re-use.

No joke: this will revolutionize your development process.

2

Hello Srimarc,

I am currently trying to integrate StrangeIoC with nGUI ; do you have some recommendations with this ?

I also adapted StrageIoC to Unity 3.5.x as the current version seems to works correctly only on 4.x, and did a Dll version for the core StrangeIoC engine.
You’ll find the two things (unitypackage for unity 3.5 and Visual C# project for StrangeIoC dll building) attached to this post.

Edit : My current approach would be to use a Prefab that contains the whole nGUI hierarchy with a View derivated class attached to its root.
This View derivated class would receive all the nGUI messages. The prefabs that encloses the nGUI hierarchy and this view derivates monobehaviour would be instanciated inside the scene from a public parameter of the contextView by a command (StartCommand, by example).
Would this be the best method ?

1286702–58569–$StrangeIoC_3.5.unitypackage (35.1 KB)
1286702–58570–$StrangeIoC.rar (1020 KB)

3

Hi alewinn,

Actually I’m doing exactly the same thing myself! What constitutes the best way to do this could be fodder for some debate, but I don’t really look at an NGUI view as being markedly different from any other view. Whatever its peculiarities, each view should be as simple, reusable and limited in responsibility as reasonable for its particular situation. Within this, consider if any of your views will want to be reusable, and therefore whether some of the peculiarities which NGUI allows (cool animations, e.g.) should be separated from the rest of the View to enhance portability.

In the particular project I’m building, my approach to NGUI as a whole is to put the NGUI hierarchy in a separate scene with its own context (the scene gets loaded using LoadLevelAdditive()). UIContext is a self-standing application, so all the building and testing can happen without reference to the larger app. But some events — as when clicking a button loads something from the server — are sent/received using the crossContextDispatcher. This approach seems to give the parts of our app lots of autonomy, so I’m happy with it so far.

I didn’t really write Strange with 3.5.x support in mind, but we have at least one colleague using it successfully as-is in that environment. Could you describe what exactly is the issue you’re encountering?

Glad you’re using Strange! It’s great to hear that people are putting it through its paces!!!

4

Some useful new(-ish) links for those using/interested in StrangeIoC.

Unity Asset Store: StrangeIoC | Tools | Unity Asset Store
Google group: Redirecting to Google Groups
Facebook: Redirecting...
Twitter: x.com

And of course the pages listed at the top of this thread:
Site: StrangeIoC
GitHub repo: GitHub - thirdmotion/strangeioc

5

Hello srimarc,

Main problem I encontered for Unity 3.5 is that Unity 3.5 don’t support namespaces, so I had to remove them, plus I had to redo the samples scenes setups. It was mostly minor problems.
Thanks for the separated scene context, I’ll try to do this.

6

Thanks so much for this srimarc!

If any of you are like me who’s still wrapping their heads around the idea of inversion-of-control, here’s a very good video tutorial that walks you through from concept to implementation: IT Courses - D-Nrtv

7

alewinn,

That’s curious. As I mentioned we have at least one colleague using 3.5.x successfully with no change. Not sure why your situation is different, but I freely admit that supporting older versions of Unity wasn’t high on our priority list. I’m glad you have a functional workaround. :slight_smile:

AnomalusUndrdog,

Thank you, and thanks for the link. We believe that more devs understanding the advantages of IoC will lead to a stronger Unity community.

8

Seriously thanks for this!

I come from an AS3 background with lots of robotlegs experience and you just saved me a ton of time having to do something similar.
If nothing more than creating the event bus and command map this saves time.
Was about to use sebas77’s ioc container, but yours seems way more solid and documented. I haven’t put yours to the test yet, but I am happy to at least see that it approaches the subject from the same angle I’m used to and see that you’ve put a lot of thought and time into it.

One minor thing that kind of annoys me… TmEvent. Horrible name. After looking at it for a few minutes, I finally realized it stands for ThirdMotion, but its not like you prefixed all the other classes, so I was trying to decipher what kind of event it was. Stick with something like DataEvent or anything non-branded since its the only class like that. Just my 2 cents.

Anyway, like I said thats a very minor issue… overall thanks again for the work you’ve put into this. Looking forward to putting it through its paces in the coming weeks.

9

yourpalmark,

First, you’re very, very welcome.

Second, I thoroughly accept your sincere (and entirely justifiable) criticism of TmEvent. The fact was that we couldn’t use ‘Event’ and didn’t like other ideas we considered, so we used TmEvent (thinking to replace it eventually) and then it just stuck. On the plus side, note that unlike Actionscript you virtually NEVER need to reference the concrete TmEvent. When you fire an event, you simply call:

…or…

and handlers should reference the interface IEvent, not the concrete TmEvent.

So TmEvent is used internal to Strange, but doesn’t really affect you outside it. (Actually, this probably accounts for why I never got around to fixing it.) Still, probably shoulda fixed that. :stuck_out_tongue:

Finally, I’ve looked closely at Sebas’s IoC Container. It’s good, and informed some of what we did when building Strange. But Strange was built to be akin to RL…that is, to provide a holistic solution for organizing IoC, rather than simply a mechanism for injection. Our studio comes from as AS3/RL background. Like you, we’ve seen how useful that pattern is, and we were, frankly, surprised that no similar framework existed for Unity. So we built it.

10

This is pretty awesome, we’ve been looking for a Robotlegs-like framework for ages!

I’m just wondering one thing: In Robotlegs, we typically create bootstrapping classes to handle bindings just to keep everything separate and organized. The classes are instantiated, but no reference is kept so they should get garbage collected.

It seems to be working fine with StrangeIOC, but would there be any downsides?

Example
Map bindings method in the main context:

protected override void mapBindings()
{
	new BootstrapModels(injectionBinder);
	new BootstrapViews(mediationBinder);
}

One of the bootstrap classes:

public class BootstrapModels {

	public BootstrapModels (IInjectionBinder injectionBinder) {
		injectionBinder.Bind<IGameModel>().To<GameModel>().ToSingleton();
	}

}
11

Hi GreatBigJerk (that sounded better in my head),

We used to do much the same thing in RL. There’s no problem doing this if it helps you stay organized, and I can’t think of any reason not to!

12

Hi,

How does this framework compare e.g. to the popular Windsor and Spring IoC frameworks. It seems that they are pretty matured and feature rich. Is the special integration with Unity3d (e.g. context via hierarchy) the main benefit?

Thanks for raising the topic here in the forums.

xad

13

xadhoom,

I have to admit I know only a little about Spring and nothing at all of Windsor. I’m curious: have you implemented either in a Unity3D project? Some quick research revealed nothing at all on either of them being used with Unity…and in months of searching/writing/release no one’s mentioned either to me for use with Unity until now.

Now obviously I can’t compare Strange with frameworks I don’t know, but I can tell you some of its special benefits that I doubt these others offer.

First, of course, it was indeed written with Unity in mind and I now know of several developers actively using it and reporting back to me, so there’s no question that it will work — without any special handling — in Unity 4.x (Strange uses namespaces, so at least one dev has mentioned that as an issue in 3.x).

Second, it’s very lightweight and exceedingly simple. Anyone with reasonable C# chops and a few hours should be able to see how it works, so there needn’t be any internal mysteries. In the (very few) bugs exposed so far, the reporter has almost always identified the line of the actual problem — often suggested the fix — and had it repaired within hours.

Strange is also really, really easy to extend. This gets into one of my little “secrets” about Strange: it’s not really an IoC framework at all. It’s a binding framework that happens to support IoC really well. The core of Strange is a Binder collection class and everything else is just some flavor of Binder: InjectionBinder, ReflectionBinder, CommandBinder, EventDispatcher, etc. You can write other Binders for whatever you need. For example, today (time permitting) I plan to write an NGuiFormBinder, since that’s a really useful thing for binding my NGUI controls to a data structure.

Finally, the bit of Strange that really is about IoC is based on the popular Robotlegs framework. This means that while Strange itself is new, the architecture is already familiar and proven to many developers.

Hope that gives you some idea of what you might get out of Strange. I’ll try to make some time to look at these others and get an idea how they compare, so thanks for pointing them out!

14

Just a note to anyone following here…

The most-up-to-date version of Strange can be obtained from GitHub here:

The version available on the Unity store is acceptable, but out-of-date. We’re working at smoothing out the process so that there’s less lag between updates on GitHub and when they appear in the Asset Store.

Thanks for your patience. :slight_smile:

15

Hi i have a certainly noob question but i try to make a multicontext test with in a current application that we develop actually. I follow the excelent demo for multi context. All work really fine i loadadditive a gui scene with only the gui another who is a level. But actually i wan’t that my gamecontext should be unload form the main scene when i load another scene !!!
What is for you the cleaner method to do this.

Should i just destroy gameobject root or i saw in the context a method for removing context but it doesn’t work actually can you help me

thanks !!

16

I just make an update from the repository and i have a strange issue when a make a mediation binder with my gui view and my gui mediator i have to script attach in the editor with the old version of strange who come from unity asset store all worked well ! Do you make some modification to structure for the binding !

17

i just check your demo on the repository and you a problem on the demo too !!

18

Hi,

I have started a simple project with StrangeIoC based on basic example, I have a Go Root and Context, one view and mediator and one command.

Very basic setup and just Debug log state to understand :slight_smile:

When I launch scene, I have 2 mediator added on my gameobject HomeView, it’s normal ?

HomeView.cs:

public class HomeView : View
	{
		[Inject]
		public IEventDispatcher dispatcher{get;set;}
	
		internal void init()
		{
			Debug.Log("HomeView INIT");
		}
	}

HomeMediator.cs

[Inject]
		public HomeView view{ get; set;}
		
		public override void OnRegister()
		{
			view.init ();
			Debug.Log("Mediator OnRegister");
		}
		
		public override void OnRemove()
		{
			Debug.Log("Mediator OnRemove");
		}

HomeCommand.cs

public class HomeCommand : EventCommand
	{
		
		[Inject(ContextKeys.CONTEXT_VIEW)]
		public GameObject contextView{get;set;}
		
		public override void Execute()
		{
			GameObject go = new GameObject();
			go.name = "HomeView";
			go.AddComponent<HomeView>();
			go.transform.parent = contextView.transform;
			
			Debug.Log("HomeView Added");
		}
	}

ProjectContext.cs

protected override void mapBindings()
		{
			//Event/Command binding
			commandBinder.Bind(ContextEvent.START).To<HomeCommand>().Once ();
			
			//View/Mediator binding
			mediationBinder.Bind<HomeView>().To<HomeMediator>();
		}

Thanks

19

I have the exact same issue as you it is really strange did you take the plug on the repository !!

20

i made a backup to the asset store version all work fine in the editor but i have the issue on build !!!