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!


The Good, The Bad and The Strange

This is a presentation I gave awhile back, which I finally got around to recording. It explains the core principle of dependency inversion upon which Strange is based. It’s largely intended as an intro that explains why writing Singletons is such bad practice (and writing Factories only marginally better), and why injection is a better way to go.

Part 1 (theory)

Part 2 (practice)

I’m going to Unity!

Unity logo

Powered by Unity

As friends of Strange will know, things have been very quiet on the development front over the last eight months or so. The reason is that I’ve been engaged in building a new startup company which frankly had nothing whatsoever to do with Unity. All that is changing today.

The sad news is that my startup didn’t take off as quickly as we had planned or hoped. The good news is that this puts me back in the Unity game, and therefore back into StrangeIoC. Even better, I’m not just going to work on Unity, I’ll be working at Unity.

So what does this mean for Strange? Well, Unity are hiring me, they’re not buying Strange, so on the one hand don’t expect them to be integrating it into the product anytime soon, or charging for its use, or anything of that sort. From Unity’s perspective i don’t think anything about Strange will really change. On the other hand, you can expect that future StrangeIoC development (and there will be further development) will be able to take better account of upcoming features, and of course I hope to both increase the profile of Strange in Unity development circles and help improve the overall community ethic around relevant issues such as decoupling, testing, and other best practices.

I hope everyone in the Strange family is as excited about this turn of events as I am. While I’m naturally disappointed that my little startup didn’t meet with instant success, I’m nevertheless stoked to be back with Strange and Unity. I hope you’ll forgive my absence and celebrate an exciting future.

So what will I be doing? Well, my first responsibility will be to the analytics team, helping you to make better sense of how users are playing your games. From our early discussions (and this Unite 2014 presentation), it’s clear Unity wants to eliminate the pain points that keep you from instrumenting your app or understanding the resulting data. My experience in front-end development and decoupling come very much into play in achieving these goals. More generally, you can be assured that the philosophies underpinning IoC will have another in-house advocate.

Before I wrap, let me take a moment to once again thank the superheroic efforts of Will Corwin, who has looked after Strange, answered questions on the Google Group, handled pull requests and bug reports, and generally kept this enterprise alive in my absence. It’s down to him and you that there is an enterprise to return to.

So, the ball is in your court. Where should Strange go next? Ideas for new features? More examples/documentation? I’d certainly love to build a roster page at our site listing games and companies using Strange, which I think would help advance the cause. Please chime in. We’re off to a Strange new start!