StrangeIoC v1.0 RC1 is here!!!

Will Corwin just pulled us over the finish line! Or the starting line…whatever. The first release candidate for Strange v1.0 is now on tip.

Also check out Will’s post in the Google Group (you are a member right?):!topic/strangeioc/IWRTPE4jc0w

Please start using it…find all the flaws…let us know what you like and what you don’t. We’d like to have it blessed and official in time for Unite Boston.

As always, a huge thanks to Will for pushing things forward, and a further thanks to all of you for your patience and interest. Let’s make Unite Strange!

v1.0 and BSHT latest

Once again, just keeping you up-to-date on our progress.

The Big, Strange How-To proceeds at a reasonable pace. We’ve received quite a lot of excellent feedback on everything released so far, and I can’t begin to tell you how grateful Will and I are for that. Please keep it coming!

I thought I’d share the table of contents, as it’s beginning to take a more concrete shape. I’ve also included the status of each chapter, so you can get a feel for how far along we are. Compare it to this article and any thoughts you’ve had, and let me know if you see anything missing.

Intro (open for review)

Walk through (wip)

Deep dives

Best Practices (first draft open for review)

Unit testing with Strange – wip

Platform-specific issues (TODO)

  • IL2CPP
  • iOS and Trampolines
  • Known unsupported platforms and why
  • Other?

As for the state of v1.0 itself, we’re honestly not moving forward as quickly as I’d like. Will and I have had some difficulty coordinating schedules. We need to review each other’s work, and firm up the release so you all can get some time with an RC before it goes live. Here’s our TODO list, along with the state of each item.

Inching towards v1.0

This is just a quick update to let you know we haven’t been entirely idle. Progress on V1 .0 continues on two fronts:

  • Preparing the release candidate
  • Writing sections of the new Big Strange How-To

Will and I have been discussing the fastest route towards getting a release candidate to you so y’all can start playing with it. We apologize that this is taking longer than we anticipated. Some of this boils down to our work for Unity: there’s quite a lot of urgency around the release of 5.1, and even 5.2 behind that.

As to my work on the BSHT, I have partial (almost complete) chapters on injection, mediation, reflection, signals, and commands. I also have a great deal of the walk-through complete (I write a lot via dictation as I walk to and from work, as I’m doing now). In each case, there are some details that require investigation before I’m ready to put these chapters out for review.

Apologies for the delay. Rest assured we are as eager as anyone to get the new version shipped.

One Strange Week in Spain


Let’s start with what this article will not be about. Dependency injection will not be a native feature in Unity. Not, at least, for the foreseeable future.

But for one exciting week, it was.

A question I got more than once when I joined Unity was “will Strange become a part of Unity?” I answered, “No, Unity are hiring me. Not buying Strange.” Nevertheless, the idea of integrating certain features of Strange  directly into Unity has never been far from my mind.

Last week, Unity engineers from all over the world met up in Malaga, Spain for a big hackweek: one hundred and fifty engineers, all brainstorming and blue-skying projects they thought might be fun or useful for the company and/or community.  And a mighty assembly of ideas it was.

Among these brave souls, our friend Will Corwin proposed the integration of dependency injection directly into Unity as a native feature. Obviously, this was something I couldn’t pass up. Together with colleague Aurimas Cernius, we leapt in and made it so.

Our goals:

  • Create a simple, easy-to-use DI system
  • Explain the value of DI to hackweek participants

We were not attempting to make Strange a native feature. The MVC construct on which Strange is based is a useful application paradigm, but it’s certainly not the only one. None of us thought that the larger framework was appropriate as a native feature. What we did (and do) regard as appropriate, was the injection feature itself. To do this we needed the following pieces:

  • The injection system, obviously
  • The reflection system, for efficient caching
  • A context, for writing bindings

We started by copying the appropriate packages from Strange, stripping out anything that wasn’t useful to our case. Mostly this meant simplifying the Context.

One of the cool things about adding injection directly to Unity is the ability to ditch some of the shoehorned functionality Strange copes with on startup. UnityEngine.Injection, as our system came to be, had C++ hooks to kick off certain processes, making those early milliseconds cleaner and more reliable.

It all started with this player setting.


With this Boolean switched on, the DI system went to work, searching for a Context marked with the [BindingContext] attribute. This meant that a ContextView in our system was optional. Sure, you’d want one to mark out sub-contexts, but a viewless Context is probably a better choice for your first Context, which shouldn’t have to be tied to a view in any way, and shouldn’t be destroyed if your scene changes (we’ve even thought of implementing this idea in Strange itself).

Of course we have our familiar [Inject] and [PostConstruct] tags. The only other place where our injection system touches the developer is in MonoBehaviours. Aurimas wrote this native hook:

public class SomeClass : MonoBehaviour {
    public ISomeService YouKnowTheDrill { get; set; }

Any MonoBehaviour so marked seeks out and finds the correct Context, based on the same set of rules Strange uses. The results of these simple changes were pretty cool.

  • A developer can start playing with DI with as little as a button click and about 5 lines of code (An Inject tag and a simple Context). Compare that with what it currently takes to get into Strange for the first time.
  • MonoBehaviours can request injection directly. They don’t need to extend View.
  • Strange (or other IoC systems) could be layered on top of this system.
  • A colleague pointed out that resolving bindings should really be a compile-time operation, not runtime. We agree. That could potentially be fixed by internalizing DI.

We had most of the functionality working by Wednesday morning, so we had accomplished our first goal. But for the second goal — explaining the value — we didn’t yet feel like we had an ideal presentation. Fortunately, inspiration struck late Wednesday: we quickly re-tooled a one player game to two player and wired it up with a real-time server.

Actually, we used not one real time server but two! We leveraged an experimental server written by another hackweek team, then showed how using DI bindings we could instantly swap between the experimental one and UNet.

The video below (no audio) shows our presentation “slides” along with some side-by-side video of the game running with the experimental server.

public class MyGameContext : Context
  protected override void mapBindings()

  protected override void postBindings ()

This was a fun project. It led us to consider more deeply than we ever had before what it would mean to integrate DI directly into Unity. As I said at the top, this isn’t something we see being implemented in real product anytime soon, but we made more folks within Unity aware of what we do and why. We met some great people, heard about some amazing ideas, and started some conversations that may someday bear fruit.

Babel Naming

Journey From BabelThis just tickled my funny bone, and I thought I’d share. As I’m working on the documentation for the next version of Strange, I thought I’d go through some of my early notes, looking for ideas. And I stumbled across this blast from the past.

The development codename for what eventually became Strange was Babel. As the framework was nearing completion — and we knew we were going to open-source it — we decided we needed a cool name to get it noticed, so we threw together a brainstorming document. Submitted for your amusement, here are all the Stranges that could-have-been…

Babel is the working title for the framework I’ve been building. We’re looking for a name. Feel free to add ideas.

Things to consider

  1. At its heart, Babel is not an injection library. It’s a binding framework. The most important thing Babel does is bind something to something else. One (very important) application of that binding is dependency injection.
  2. Consideration #1 might not matter.
  3. It might be nice to use our initials, TM, to reflect back upon us.*
  4. Consideration #3 might be unnecessary.
  5. Babel is lightweight and modular, something that appeals to developers.
  6. Babel is written for C# and Unity, and will be (so far as we know) the first “serious” attempt to provide a Inversion-of-Control/Dependency Injection framework for this purpose.
  7. If you care, you can see the names of some IoC/DI libraries here.

Name ideas (feel free to add)

  • TieFighter
  • TinMan
  • ThinMan
  • TinType
  • Babel
  • Babylon
  • Unification
  • UncleBob (a reference to the guy who devised the Dependency Inversion Principle)
  • Stingray
    • Ampule
  • IssacNewtonsBinding or the bindingofIssac
    • FirstMotion
    • Newton
  • Boson – “the ‘glue’ that holds matter together”
    • Higgs
    • DarkMatter
  • Fondant (UK: /ˈfɒndənt/, US: /ˈfɑndənt/ or /ˈfɑndɑnt/, from the French: /fɔ̃.dɑ̃/) is one of several kinds of icing-like substances used to decorate or sculpt pastries.
  • Agar or agar-agar is a gelatinous substance derived by boiling[1] a polysaccharide in red algae, where it accumulates in the cell walls of agarophyte and serves as the primary structural support for the algae’s cell walls
  • A carboy (or demijohn) is a rigid container with a typical capacity of 20 to 60 L (5 to 15 gallons).[1] Carboys are primarily used for transporting fluids, often water or chemicals.[2] (as cider maker, I just find these to be funny words)
  • Strange – A strange attractor generates predictable patterns, often in the scope of a chaotic system.
  • Gloo
    • Glue
    • BluTac (thinking of the virtue of sticking things together, but not permanently)
    • Paste / LibraryPaste / PasteLibrary / PasteBoard
    • Duct tape
  • Vulcan MindMeld
    • My mind to your mind
    • Sneaky sci-fi references
      • Liberator
      • SonicScrewdriver
      • Tanstaafl – see here, particularly in relation to Newton’s Second Law of Thermodynamics
      • Klaatu
      • Illudium
      • Tholian (web)
      • Federation
  • Octopus
    • Tentacles
    • TentacleMotion

* The “Us” in this context was ThirdMotion, the company responsible for me bringing Strange to you.

It’s Big, It’s Strange, and I’m Rewriting It

[EDIT]First draft of Introduction is now open for comment[/EDIT]
[EDIT2]The revised architecture diagram is now open for comment[/EDIT2]

Gentlemen, you can't fight in here! This is the War Room!

The Big, Strange How-To has been the standard (and, er, only) textbook on Strange since its inception. But with the exception of a handful of corrections and the addition of a couple of new features, it has remained largely unchanged since it was first written way back alongside v0.5. With the upcoming release of v1.0, I reckon that it’s high time for a proper update.

With the benefit of hindsight and whisky, I’m looking at everything in the BSHT to see what needs updating, adding, or even removing. And that’s where you come in, my friends!

What could we explain better? What has frustrated you most, especially when you were first learning? I especially want to concentrate on the new user: what can we do to flatten the steepness of our learning curve?

Here are my ideas so far. Please leave comments below and I’ll keep this post updated with your input.

Things to add to the Big Strange How To

Re-work the Introduction

New section: opening Strange for the first time (walk-through)

  • Explain the broad structure of the repo.
  • Walk-through of MyFirstProject project
  • Walk-through of MultipleContexts project

Updated section: Signals

  • Beef up the Signals section.
  • Add explanation for the (new to v1.0) ListensTo feature.
  • Change all examples (across all of BSHT) from EventDispatcher to Signals.

Updated section: Mapping across Contexts

This section is really thin. Let’s clarify the concept and the execution. Particularly, explain the reasoning behind multiple Contexts, along with practical info on how to structure them.

Updated section: Reflection

I don’t want to confuse a new user with too much about this…but then the understanding the principles is important.

New section: Pools

Explain how the Pools extension works

New section: Promises

Explain the (new to v1.0) Promises package

New section: Implicit Bindings

Explain the ImplicitBind package

New section: runtime bindings

Explain the (new to v1.0) feature runtime bindings

New mini-section: Strange for extending Unity

A mini-section because it will essentially just link to a separate document specifically about using the (new to v1.0) Editor extension. The current plan is for the Editor extension to live outside the main Strange repo as an optional plug-in.

New section: Testing tutorial

Explain how to run unit tests and write your own.

Enumerate Exceptions for each package

In each package, list and explain each of the thrown errors. In an appendix at the end of the document, put all Exceptions in one place for easy reference.

Replace artwork

All that pesky text art (—–>). Let’s grow up and use PNGs or SVGs or something.


Lots of people asking for something more like a step-by-step tutorial. Particularly questions about uGUI. Should this be here or a separate document?

New Section: Platform Specific Issues

A request in the comments to explain iOS trampolines. Compile a set of other platform-specific gotchas?

New Section: Best Practices

Some cohesive section on Dos/Don’ts when using Strange.


Add named injection for constructors

How this will work

I’ll going to create the new BSHT as a Google Doc at first. I’ll edit this post and provide a link so everyone can weigh in. In the meantime, feel free to leave comments and ideas.

Owning my responsibilities

Today’s post is not precisely about Strange so much as about keeping one’s eye the fundamentals.

As you might already know, we’ve been working on adding editor functionality so that you can create StrangeIoC-based Extensions for Unity. I usually approach a new project like this in a few simple steps:

  1. Quick and dirty proof of concept
  2. Refactor and tighten
  3. Test and correct

As you can see I’m not really a TDD guy, though I end up with a similar product.

In step one, I copied and pasted the MediationBinder and hacked a version that would work with EditorWindows. This led, in step two, to an obvious refactor: extracting commonalities between MediationBinder and the new EditorMediationBinder into an AbstractMediationBinder. And Oh Look! all those commonalities – freed from the surly shackles of MonoBehaviours – reveal big chunks of testable code!

This has always been an Achilles’ Heel for Strange. The untestability of the mediation package has meant that we have never been entirely certain of the quality of our code in this part of the framework. Because of this, we necessarily approach changes here with a lot more caution then we might do any other part of Strange.

My buddy Will saw this and immediately went to town with a further refactor. The result is amazing: virtually the whole of the (Abstract)MediationBinder is now open to unit testing. The bits that aren’t tested simply represent specific lines where we supply access to the MonoBehaviour-specific API. All the rest has been abstracted away.

The practical result for you – whether or not you care about Editor extensions or even unit testing – is safer, more reliable code in an area of the framework on which you probably rely a great deal.

The mea culpa and moral of all this: the single responsibility principle exists to help us. My failure to consider this fully when writing the original version of the MediationBinder is only coming clear to me years later. Had I broken down the elements of my methods into smaller atomic parts back then, we probably wouldn’t have written off the whole of this package as untestable.

Lesson learned.

New feature: Editor Views within Editor Contexts

At the SF Unity User Group a few nights ago, one gentleman asked me (as he had in fact once before) whether Strange could be used within the Unity Editor. He wants to do a better job building Editor extensions, and he’d like it if we could assist.


Sure, I said, if you want to build in the necessary changes. I wasn’t too keen to do the work myself…how many people actually have this need? But the more I thought about it, the more I decided it was an appropriate use case…and it didn’t actually seem that hard. We’d mostly just need a specialized Context and a specialized MediationBinder.

So I’ve been whirring away at this for a day or two, and the (definitely not-ready for production) alpha is now on branch feature/editor. It principally involves a new extension package called ‘editor’ that includes the following classes:

  • EditorContext (same as Context, but specialized for Editor)
  • EditorContextException (for reporting errors)
  • EditorMediationBinder (a specialized variation of MediationBinder)
  • EditorMediator (similar to, but with important differences from, Mediator)
  • EditorMVCSContext (a specialized variation of MVCSContext)
  • EditorView (like View, but we extend EditorWindow instead of MonoBehaviour)

Please review the code. For the most part, there’s not a lot that’s surprising. But we do have some differences to discuss, which I’ll get to after I (finally) get to our actual headline.

In order to test my work, I’ve started working on a StrangeIoC inspector. The beginning of this is also on the branch. Thing is, I don’t do a lot of Editor extension work, so I’m not entirely sure how to proceed. And any way, what features would be most useful? So I’m going to start working on this tool-thingy as part of the next release, but I’ll probably come to you via this blog to generate ideas and help me fix the things I break.

OK? Ball’s in your court my friends.

Moving on, here are some things you probably want to know about the differences between regular Strange and Editor-extending Strange.

There’s a lot more working around statics

EditorWindow features seem to be built on a lot of static methods. This isn’t helpful in a Strange world. On the other hand, Strange can help isolate a lot of this silliness. For example, my StrangePanel already has a ScriptReloadService to isolate the service aspect of knowing that scripts have been updated. This helps with abstraction and keeps my StrangePanelView focused on View-related behavior.

There’s no ContextView

Traditionally, we kick off a Strange app with a MonoBehaviour at the top of a view hierarchy. This doesn’t make sense in Editorland (the most magical place on Earth), where we instead use the [InitializeOnLoad] attribute. What’s nice about this, though, is that [InitializeOnLoad] means our package is just plain up-and-running when we enter Unity. And there’s no need to track or think about which View is “on top”.

There’s no Cross-Context behavior

At least for V1, this seems OK to me. It’s a bit hard to say at this point whether we want multiple contexts in a single Editor extension. I suppose we might. Anyway, let’s cross that context when we come to it.

To be clear, I’m talking about multiple Contexts in a single extension. I’ve made sure to handle the possibility of more than one extension, both of which happen to use Strange (this is called ‘optimism’). Each extension gets it’s own Context within which to operate.

EditorMediators are not Views

In regular Strange, your Mediators are MonoBehaviours, so in some respects they’re just like Views. I’m not even sure I could make this happen in Editor-flavored Strange, but I really didn’t try. EditorMediators now actually behave much more like Mediators in Robotlegs, in that they are in contact with the View, but unable to perform actual View logic themselves. This doesn’t seem like a problem to me. You’ll have to let me know if you disagree.

For the EditorMVCSContext, Signals are the primary event bus

I’ve been thinking about doing this in the rest of Strange, where the primary event bus is still EventDispatcher. For Editor, this seems an obvious thing to do, since Signals really are a better approach, and we may as well hit this brave new world with the best tools.

Review and Comment

As always, I ask you to look at this now, before it’s a fait accompli and in the live product. It’s better for everyone if this work is challenged and vetted a lot before we use it in anger.

And let me know what you want/need in a Strange Inspector. Should we be able to inspect our bindings from there? Write them? List all our Contexts/ContextViews? Give me some ideas!

IoC solutions for Unity

This post is just a list of Inversion-of-Control/Dependency Injection solutions for Unity3D for anyone looking to compare. I can’t at this time validate how good any of them are (well, with the obvious exception).

This is a living list. If you know of any I’ve missed, please let me know.


Strange is the open-source IoC framework I built and which is the main focus of this blog. It borrows heavily from previous OS projects Robotlegs and SwiftSuspenders.

Robotlegs for C#

The Actionscript version of Robotlegs was foundational for StrangeIoC. In 2015, our friend prankard ported the framework to C#. Unsurprisingly, the framework will look very familiar to our user base.


A .NET port of Dagger, the lightweight Android dependency injector from Square.


Zenject, like StrangeIoC, is an OS project with a focus on helping Unity developers write large, flexible code bases.

Sebastiano Mandalà

Sebastiano developed some early ideas on Injection containers for Unity. His work was inspirational for many projects that followed, Including StrangeIoC and Zenject.

Simple Injection by Kasper Mindra

Simple IoC Container for Unity3d


uFrame is a paid MVVM framework available from the asset store.


Uniject is an Open Source DI project with a heavy emphasis on creating/promoting testable code. Note that as of this writing this project has been dormant for 2 years.

Inconspicious Framework

Inspired by Strange, the developer tells me. The main difference/selling point is integration with UniRx for type-safe commands/signals.