This article shows you how to remove events from the MV-C design pattern to make it simpler to understand, safer to use, and faster to execute. It’s a step-by-step lesson in refactoring. Start by reading the MV-C article, then read on!
Posts Tagged events
How fast are C# delegates and events? The best answer is “compared to what?”. You probably use callbacks all the time, but what’s the fastest kind of callback? C# delegates and events are nice, built-in features of C#, but you could also implement your own callback interface. Would that gain you any speed? Read on for the performance test and results!
Today’s article is about WebCall, a class to make Unity’s WWW cleaner and easier to use. How could it be cleaner or easier than it already is? By adding C# events! Normally your web calls have lots of clutter around them, your logic gets split across functions, and handling the call is hard when the GameObject or MonoBehaviour get destroyed. WebCall solves all these problems so your web calls are clean, easy, and robust. Read on for the source code and examples!
DLLs—like SWCs in Flash—are an extremely handy way to build your code into reusable modules. Unfortunately, Unity has some quirks that can lead to crashes on iOS and other environments that don’t support JIT compilation. The biggest problem that crops up is when you try to use C# events in a DLL. Today’s article investigates why and where the problem occurs and presents a simple solution to work around the problem. Read on to learn how to safely use C# events in Unity DLLs!
One apparent downside to the “pure code” approach to Unity app code design is that it makes less use of the Unity Editor. Because it only uses one main MonoBehaviour, there aren’t a lot of MonoBehaviour classes that can be modified by the Inspector panel- a mainstay in Unity design and debugging. Today’s article introduces another kind of auxiliary MonoBehaviour to work around this issue enabling you to use the “pure code” approach without sacrificing the Inspector panel.
Last week’s article continued the discussion of special types of functions in C#’s class system, including variable numbers of arguments (“var args”), indexers, and conversion operators. Today’s article should finish up the topic of special functions. Read on to learn about the built-in support for delegates, events, and object initializers!
In my recent work related to events and signals, I had a little discussion about errors that are thrown during the dispatch of an event or signal. I did some investigating to see how EventDispatcher handles this and found something rather surprising.
My last article on Callback Strategies highlighted some pretty severe performance differences between my Runnable strategy, as3signals by Robert Penner, and Flash’s native Event system. My simple Runnable technique had an artificial advantage though: it was not a proper library but instead a little bit of code built right into the test app. Today I’m introducing TurboSignals as an AS3 library making use of the Runnable technique.
I’ve previously covered ways of implementing in my article on Runnables (aka observers) which showed how to call back about 15 times faster than just using a Function object. There are still more ways to call back though and I didn’t cover them at the time. Today I’ll be adding to Function and Runnables by testing Event and the as3signals library by Robert Penner.
Making sure you remove event listeners is good for both correctness and garbage collection. Sometimes you don’t want (or need) to hear events any more and some times you just need to release references to aid the garbage collector in memory cleanup. Whatever your reason, there are a few ways to do it.