A Flash Developer Resource Site

Results 1 to 9 of 9

Thread: Why should I use Events?

  1. #1
    Member
    Join Date
    Mar 2004
    Posts
    45

    Why should I use Events?

    Why should I use events?

    I mean, in order to use events, I have to 1. setup an event dispatcher, 2.add an event listener to an object and 3. have a listener function set up.

    Could I not achieve the same thing by just calling a function in whichever object I need to?

    What is the benefit? Maybe I'm missing the point....

    Anyone care to enlighten me? Cheers!

  2. #2
    Mod cancerinform's Avatar
    Join Date
    Mar 2002
    Location
    press the picture...
    Posts
    13,448
    In order to handle any events (functions) you need to create eventListeners for the object, which triggers the event. There is no other way.
    - The right of the People to create Flash movies shall not be infringed. -
    | www.Flashscript.biz | Flashscript Biz Classes/Components |

  3. #3
    Member
    Join Date
    Mar 2004
    Posts
    45

    Perhaps...

    I didn't explain what I meant clearly enough, so hopefully this will...

    Imagine I'm making a game....a "game over" event can take place.
    This happens when a playerObject has a y property above 100.

    imagine something like this:

    Code:
    public class Game {
    
    private var __playerObject:Player = new Player();
    
            public function Game () {
                   __playerObject.y = 102;
                   updateState();
            }
    
            private function updateState() {
                  if (__playerObject.y>100){
                    gameOver();
                  }
            }
    
            private function gameOver(){
                  __playerObject.gameOver();
            }
    
    }
    In this case, I was able to call a gameOver() method on a __playerObject without any event.

    So, what exactly is the case for using an event?

  4. #4
    Knows where you live
    Join Date
    Oct 2004
    Posts
    944
    Low coupling or writing a class that doesn't know ahead of time what/how many objects will be listening to its events.
    The greatest pleasure in life is doing what people say you cannot do.
    - Walter Bagehot
    The height of cleverness is to be able to conceal it.
    - Francois de La Rochefoucauld

  5. #5
    Will moderate for beer
    Join Date
    Apr 2007
    Location
    Austin, TX
    Posts
    6,801
    The primary advantage in situations such as you describe is when the object which would be doing the dispatch doesn't have a reference to everything that would like to know about it.

    It's a more object oriented approach which allows levels of structural abstraction.

    Let's say your Player object could tell when the game was over and wanted to notify the Game. Let's also say you have an arbitrary number of Players.

    Code:
    public class Game {
      private var _players:Array = new Array();
      private var gameTimer:Timer;
      
      public function Game() {
        var p:Player;
        for (var i:int = 0; i < 10; i++){
          p = new Player();
          _players.push(p);
          p.addEventListener(GameEvent.GAME_OVER, gameOver);
          this.addEventListener(GameEvent.TICK, p.update);
        }
        gameTimer = new Timer(100);
        gameTimer.addEventListener(TimerEvent.TIMER, updateState);
        gameTimer.start();
      }
    
      public function updateState(event:TimerEvent):void{
        //any logic such as updating leader board, etc.
        dispatchEvent(new GameEvent(GameEvent.TICK));
      }
    
      public function gameOver(gevent:GameEvent):void{
         gameTimer.stop();
         //other cleanup code.
      }
    If you had kept the architecture you had above, you'd have to test each player for the gameOver condition in your updateState method. Honestly, for a simple game, that's not so bad. But it gets hairy quickly if you don't let objects take care of themselves.

  6. #6
    Member
    Join Date
    Mar 2004
    Posts
    45
    Thanks that helps...I can see now how it helps when adding and removing objects from listening, without having to write new code for handling the adding and removing to a list.....

    however, the coupling...I don't understand how it is less strongly coupled than just calling a method on an object.

    Thanks for the help!

  7. #7
    Member
    Join Date
    Mar 2004
    Posts
    45

    more questions...

    Quote Originally Posted by 5TonsOfFlax
    The primary advantage in situations such as you describe is when the object which would be doing the dispatch doesn't have a reference to everything that would like to know about it.
    What is a typical case of this? I can imagine something like this:
    Code:
    class someClass {
         
            public function someClass(){
                 
            var fooInstance:Foo = new Foo();
            var barInstance:Bar = new Bar();
    
            //somehow here i'd like to make barInstance listen to an event generated by fooInstance
    
            }
    
    }
    how is it possible that I can make barInstance listen to an event generated by fooInstance?
    Sorry if these questions are basic. I'm not familiar with events, and it shows

    P.S. thanks for all the help, it is slowly getting through to me

  8. #8
    Will moderate for beer
    Join Date
    Apr 2007
    Location
    Austin, TX
    Posts
    6,801
    Yes, that is a good example.

    To set up the listener relationship, you'd just need to do this:
    Code:
    fooInstance.addEventListener(FooEvent.FOO, barInstance.handleFoo);
    I like to have the Bar class provide a method which accepts a Foo, but only when you already know that the dispatching instance will be a Foo.

    Code:
    public class Bar {
    
      public function addFoo(foo:Foo):void{
        foo.addEventListener(FooEvent.FOO, handleFoo);
      }
    //...
    
    }

  9. #9
    Member
    Join Date
    Mar 2004
    Posts
    45

    Cool!

    OK, that's awesome, I think it all just clicked now
    Cool that the objects don't really know about each other, apart from the events The main purpose from what I now see, is preserving encapsulation. Right?

    Thanks for explaining all of that
    P.S. The method for adding foo listeners to bars...I guess is just to make it easier/neater to register individual bars with a foo instance?
    I imagine a removeFoo method would be handy too.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  




Click Here to Expand Forum to Full Width

HTML5 Development Center