Juten Tach,
some weeks ago i was messing with OSGi and a possible implementation in ActionScript. That has been put aside, but one thing i noticed, was, that in the original Java implementation most of the constants were integers, using a bitwise notation. This is really not new, but i thought, it might be worthwhile to refresh the topic. Take this little example:
const first:int = 0x000001; const second:int = 0x000002; const third:int = 0x000004;
The rule is, every other constant has a value double of the previous one. With that, you can do pretty nice things.
You can have a variable, that functions as a toggle container for all your constants:
var constantsToggle:int = 0; constantsToggle += second; // now you have turned on the switch for 'second' constantsToggle += third; // now you have turned on the switch for 'third' constantsToggle -= second; // and now you have turned 'second' off again
Wanna know, if any of the switches is turned on?
if(constantsToggle) {...}
Wanna know, if a particular switch is turned on?
if(constantsToggle & second) {...}
Again, this is nothing major, but i found it useful.
Juten Tach,
arghh. Do you know the -include-stylesheets compiler option, which is specifically made for building libraries? It is a great feature, because it compiles your stylesheets instead of just embedding the css file in your swc(see update).
BUT! How are we supposed to use that wonderful feature in Flash Builder? If i add it as a compiler option, Flash Builder nags, that it does not want this option. My feeling is, that it is the mxmlc, that is speaking there, although i have a library project. But i cannot find any other place to tell FlashBuilder, that i want to use that option.
Have you found a solution to that? Please shout!
By the way, it would be so cool, if Flash Builder would not only show the classes of a library swc, but also included assets, otherwise, how am i to know, what files i can use?
[Update]: Hm, seems like that compiler option works differently than i thought. It actually does NOT compile the Stylesheet, but classes, which are referenced by that stylesheet only. Too bad.
Juten Tach,
i just recently stumbled upon this little gem: MouseEvent.relatedObject. It turns out, it already exists since FlashPlayer 9.0, but i missed it. It is a pretty useful property. In a nutshell, it holds a reference to the object, which either lost or gained focus during mouse over or mouse out respectively. So i thought, i make a little example:
package { import flash.display.Sprite; import flash.events.MouseEvent; public class HelloWorld extends Sprite { private var panel:Sprite; private var button1:Sprite; private var button2:Sprite; public function HelloWorld() { panel = new Sprite(); panel.graphics.beginFill(0x777777, 1); panel.graphics.drawRect(0,0,200, 150); panel.graphics.endFill(); panel.x = 50; panel.y = 50; button1 = createButton(0xff0000, 100, 100); button2 = createButton(0x0000ff, 100, 120); panel.name = "Panel"; button1.name = "Button 1"; button2.name = "Button 2"; addChild(panel); addChild(button1); addChild(button2); addEventListener(MouseEvent.MOUSE_OVER, onMouseOver); } private function onMouseOver(event:MouseEvent):void { trace( "Mouse now over: " + event.target.name + ". Used to be over: " + (event.relatedObject != null ? event.relatedObject.name : "n/a") ); } private function createButton(color:uint, x:int, y:int):Sprite { var result:Sprite = new Sprite(); result.graphics.beginFill(color, 1); result.graphics.drawRect(0,0,100,20); result.graphics.endFill(); result.x = x; result.y = y; return result; } } }
Instead of explaining everything, simply take a look at the result (in which i added a textfield, so you can see the traces). You will see, that whenever you roll on the panel from the main stage (which is colored in this aesthetically bright yellow), the relatedObject is null.
Juten Tach,
A commenter in a previous post said, he loves callbacks. That made me think about the difference and about why we mostly use events and not callbacks. I think one reason is, because the Flash Player is using events all over the place. But is using events always the best solution? I am not talking about performance here, i am more interested in the underlying concepts. Here’s a classification, i would like to propose( I have been searching the web for existing classifications. If you find one, please shout):
You should use a callback, when you’re client initiates an asynchronous call and awaits an answer to it.
Rationale
In Flash – as opposed to Java – we are forced to do a lot of things asynchronously. The most popular example is loading a file. We as a client want to load a file and we want to be notified, when that process – the process, that we have initiated – is complete. We don’t want to be notified of loading events in general, no, we just want to know, when our initiated process has finished. A good way to detect a potential use case for such a scenario is, if you remove yourself as a listener in the event handler method. It is a good indicator, that you actually just wanted a callback.
The advantage of callbacks here is, that your intention becomes directly visible. If your calling a method, which takes a callback function, it is crystal clear, what is happening. You’re doing an asynchronous call and you are waiting for THAT call to finish. With events, you often have the problem, that the line in your code, where you added yourself as a listener, and the line in your code, where you are initiating the asynchronous call, might be in completely different places, which makes it hard to understand for another developer.
With callbacks, you have everything in one place and you can even check at runtime, that the callback is indeed a function and not null. You cannot check at runtime, if a client has added himself as a listener for a particular event before calling a specific method.
You should use events, when something can happen unexpectedly
Rationale
There are scenarios, in which you as a client have not initiated an asynchronous process by yourself, yet something still might happen. As an example, let’s consider an application with a shared model and different modules, that consume and feed it. ModuleX might want to be notified, when a particular value in the model changes. Yet, ModuleX might not do anything to force that. Instead another Module is doing something, that changes that particular value. Then the model dispatches an event, saying that the value has changed.
So in this case, the event comes unexpected for ModuleX. Unexpected, because ModuleX has not initiated an asynchronous process, which led to this event. ModuleX might have been idle for some time and now the event comes in and it lets ModuleX do, whatever it wants to do in that case. You cannot use a callback in this scenario, because the client didn’t want to start a process. Instead it really just wanted to be notified more generally, when something happens.
Another very popular example, where events make sense, is user interaction. You create a button and wait for a user to click on it. But the button does not force the user to click on it as part of a sequential process. Instead, the button just waits, until it might happen (which might be never). A callback would not make sense here.
Juten Tach,
you probably know this setting perfectly well:
package { public class Example { private var myDispatchingObject:DispatchingObject; // ... private function createSomething():void { myDispacthingObject = new DispatchingObject(); myDispatchingObject.addEventListener(SomeEvent.COMPLETE, onDispatcherComplete); myDispatchingObject.start(); // ... } private function onDispatcherComplete(evt:SomeEvent):void { if(evt.something == true) doSomethingImportant(); } private function doSomethingImportant():void { // ... } } }
This class is very simple, it has an object which apparently dispatches an event. You add yourself as a listener and implement an event handler.
You also know, that if your class uses a bunch of objects, which dispatch events, your own class becomes littered with event handler methods. Here’s a thought i just had, which aims for making this a bit more readable (which in the end is the opposite of being new. I just noticed, that for some reason, i have stopped doing it this way in the past):
The purpose of an event handler should be:
- check, if the event is relevant.
- If yes, call some functionality.
Now, this is important. If you do not agree with these two things, you don’t have to read any further. A lot of times, we tend to put more into our event handlers, than these two things. But we shouldn’t, because all the additional functionality is then bound to that event. As soon as you recognize, that you might want to call that functionality at another point in time, too, you will separate the handling part from the actual functionality anyway.
So, if you’re still with me, you will probably also agree, that you never want to call the event handler function directly, because it is purely meant to be invoked by, well, an event.
So i thought, why actually defining it as a class member? If the whole purpose is for wiring an event to another function, wouldn’t it be more appropriate to use an inner function instead?
[Update]: OK, that was quick. As Hristo points out, this whole thing makes no sense, if you ever want to remove yourself as a listener and don’t want to do tricks like using arguments.callee. Bummer.
Let’s rewrite the above example accordingly:
package { public class Example { private var myDispatchingObject:DispatchingObject; // ... private function createSomething():void { myDispacthingObject = new DispatchingObject(); myDispatchingObject.addEventListener(SomeEvent.COMPLETE, function (evt:SomeEvent):void { if(evt.something == true) doSomethingImportant(); }); myDispatchingObject.start(); // ... } private function doSomethingImportant():void { // ... } } }
By the way, i was a bit astonished at first, that it works this way. Like, that doSomethingImportant() is available within the inner function. Seems like closures do not only have access to their parent function, but also to class members. I think, that used not to work in the past, or am i mixing things up?!
Anyway, doing it this way, has a couple of advantages in my opinion:
- The wiring of the event becomes directly apparent and it happens at a place, you would search for anyway, because the DispatchingObject is created there.
- Since the event handler function is now an inner function of the createSomething method, it cannot accidentally be called directly.
- All methods in the class are ones, that are valid to be called. No litter of event handler methods.
So, again, this not new at all, but i know a lot of developers, who have not been doing event handlers this way for ages anymore (including me). You might say, that using inner functions brings a bad smell with it. But perhaps this is just a “i’m not used to this” feeling?!
