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.

Status Update

Just a status update, so y’all know I’m alive.

As you may recall, I left ThirdMotion a couple weeks ago. I’m now working on a new startup (my idea, actually). Unfortunately, this work is non-Unity-related, so it’s diverting me from Strange, at least for awhile. I still see the posts and bug reports, but as I mentioned in my prior post, I’m keeping a somewhat lower profile while my team and I try to rush our exciting new project to market.

As ever, thanks for your Strange support!

The Times They Are a-Strangin’

film_dylanNothing ever stays the same I guess.

Yesterday, ThirdMotion, Inc. (the company that brought you StrangeIoC) and I decided it was time to part ways. This change is perfectly amicable on both sides; sometimes things just move in different directions.

Oh, Mighty Zarquon! What does this mean for me, er, I mean, for Strange?!

Relax, nerd. It’s not that bad. ThirdMotion has always been Strange’s staunchest advocate and ally (we open sourced it in the first place to make sure it would always be there for you), and that hasn’t changed. The company plans to hand over all Strange-related material to me and I’ll administer it…which isn’t really much of a change, since I’ve pretty much been doing that anyway.

What will change

I’ll be spending time looking for a new job, so at least for the short term we’ll probably not see a huge amount of forward development. How much development happens once I’m settled probably depends a lot on wherever I end up working.

While the old repo addresses (e.g. thirdmotion/strangeioc) will continue to function, we now have new recommended addresses:

[EDIT]Owing to an issue with GitHub pages, the old StrangeIoC repo no longer has an automatic redirect to the new repo. There’s just a note there telling you to go to the new page. Doing this allows the old documentation page to auto redirect to the new one. Don’t ask.[/EDIT]

By the same token, the docs at…
…have officially moved to…

Probably I won’t be able to assist as much in support for a little while. I’ll jump in when I can, but feeding the wife and cat kind of take precedence. I’m sure y’all understand.

What won’t change

Strange isn’t going away. I kind of expect that whoever hires me next will do so in large part because of Strange, so hopefully I can convince them that it’s in their interest to support me in keeping it going.

As always, I’m grateful to everyone for your interest and support. It’s not always easy, but it’s never dull.

StrangeIoC v0.7.0 Released

logoWe’ve just released v0.7.0. Available now at GitHub. We’ll release soon to the Unity Asset Store.

From the change log, here’s all the new/improved goodness:

– New feature: Pooling
– New feature: Implicit and Weak Bindings
– Fix: bug on removal of first Context
– Fix: Fix to multiple context removal regarding false circular dependencies
– Fix: Fixed a race condition that allowed some Views to register before the Context was ready
– Fix: Fixed an EventDispatcher bug where a listener removed during Dispatch still receives callback.
– Change: Many methods that previously returned ‘object’ now return T.
– Change: MediationBinder now Mediates Views ‘bottom-up’ so that more deeply nested Views receive injection first.
– Change: Added a new exception to warn if accidentally mapped a View to something not a MonoBehaviour
– [Issue #56] Improved Context startup syntax
– [Issue #53] Exposing a checkbox that allows a View to not register with the Context
– [Issue #45] Fix for issue that could cause double-instantiation of a mapped Singleton
– [Issue #44] Prevent empty Constructors from improperly firing when a longer Constructor has been tagged as default
– [Issue #40] Fixes a null pointer when using CrossContext without MVCSContext
– [Issue #39] Add some porcelain methods to clarify View/Mediation binding behaviour
– [Issue #34] Fixed a bug where constructor injection resulted in NPE when mapped ToSingleton
– [Issue #13] Reflector now throws an Exception when attempting to inject into non-public setter
– [Issue #1] PostConstructs now support priority ordering


A Very Strange Xmas…


Note: Ardbeg distillers have never heard of StrangeIoC. Even if they had, it’s doubtful they’d approve this image.

Happy festival of your choice!

This will likely be my last post of 2013, and what a year it’s been! In January I was just beginning to conceive of an IoC framework for Unity3D development. Today we not only have the framework, but a growing community of people interested in what we’re doing. As far as I’m concerned, there’s no better definition of success than that people like the work you do.

This post won’t have any useful technical tips or release information (other than to note that v0.7 won’t be official till early January). I just want to take a moment to thank a few people important people.

First, a huge thank you to my employer, ThirdMotion, Inc., who quite literally footed the bill so you could have cleaner code. They could have insisted I write a simpler IoC framework. It would have been faster. They could have refused to open source it. It’s not easy to build something worthwhile and then give it away for free. It’s also not easy to explain that decision to your investors. And they could also have said “Right. That’s done. Get back to work!” Instead, they’ve generously allowed me some of my working week to keep making the world a Stranger place. You and I owe then a protracted slow clap.

A big shoutout to my lovely wife Orla, who puts up with me working weekends and evenings instead of doing the countless things I should be doing around the house. She’s also probably unwittingly the most knowledgable person on Earth about Strange, given the number of times she’s had to hear me explain it.

Of course many friends and colleagues have had a hand in making Strange what it is. I won’t name you all one by one but y’all know who you are, so know that you have my sincerest gratitude.

One particular colleague does deserves special mention. As much as I appreciate code reviews, consultations, tutorials, blog posts and tweets, one guy has really been out in the trenches with me helping to build a better framework. Will Corwin, author of Signals and the new implicit bindings package, is the best, most enthusiastic coding partner I could ask for. This Ardbeg (which for Will I admit should be a Bowmore) is for him!

Finally, and most importantly, my thanks to you, whoever you are. If you’re reading this it means you’re interested in what we’re doing. You’re interested in writing better code and improving the ecosystem of Unity3D development, hopefully bringing more of your colleagues along for the ride. I evolved as a developer with Actionscript…from spaghetti code to OOP to, ultimately, IoC. It works. It’s better. And Unity will be a better place because of people like yourself.

Have a lovely New Year.