[Bindable] on a read-only getter is unnecessary and will be ignored.

by Josh Tynjala

Sometimes, when you build a Flex application, you encounter a compiler warning that says, “[Bindable] on a read-only getter is unnecessary and will be ignored.” If you’ve seen that message, and you’re curious what it means, hopefully I can explain it. In short, the compiler is telling you that it can’t actually make that property bindable because it has no way of determining when the property changes.

To understand that better, you should first know a little more about how binding works. Normally, when you make a getter/setter pair bindable, the compiler adds a little extra code for you. Behind the scenes, it dispatches PropertyChangeEvent.PROPERTY_CHANGE to tell the binding system that your property has changed. Basically, it converts your property functions from something like this:

private var _example:String = "I am the very model of a modern Flex developer";

[Bindable]
public function get example():String
{
    return this._example;
}
public function set example(value:String):void
{
    this._example = value;
}

to this:

private var _example:String = "I am the very model of a modern Flex developer";

[Bindable("propertyChange")]
public function get example():String
{
    return this._example;
}
public function set example(value:String):void
{
    this._example = value;
    this.dispatchEvent(new PropertyChangeEvent(PropertyChangeEvent.PROPERTY_CHANGE);
}

If you don’t have a setter, there’s nowhere for the compiler to act smart and determine that your property has changed. If you want a getter without a setter to be bindable, you need to specify an event to be fired when the value returned by the getter changes. Your code should look something like this:

private var _example:String = "I am the very model of a modern Flex developer";

[Bindable("exampleChange")]
public function get example():String
{
    return this._example;
}

Notice the inclusion of the event type in the metadata’s parentheses.

That’s only the first part, though. Next, you need to actually dispatch the exampleChange event from somewhere in your code. For example, let’s say that we change the _example variable when an URLLoader returns a result:

private function urlLoader_completeHandler(event:Event):void
{
    var loader:URLLoader = URLLoader(event.currentTarget);
    loader.removeEventListener(Event.COMPLETE, completeHandler);
    this._example = loader.data.toString();
    this.dispatchEvent(new Event("exampleChange"));
}

Any time you change _example, you need to dispatch the exampleChange event specified in the metadata so that the the binding system knows about what you did. If you set _example in many different places, you might consider making a private or protected setter that sets _example and dispatches that event, but that’s not required.

In summary, the compiler warning goes away when you specify an event type in the metadata. Simply specifying an event type won’t update bindings though, you also have to dispatch that event when the underlying variable changes. When the binding system receives your event, it knows to update any component to which your getter is bound.

One extra thing worth mentioning is that any property with Bindable metadata that has no event specified with dispatch the same generic propertyChange event. This means the binding system will have to work harder than needed because it could receive the same event for many different properties. It’s a good idea to a create custom event for each property to avoid this limitation. You can see in the Flex framework source code that Adobe has separate events for most, if not all, bindable properties they create.

Sometimes, fl.core.UIComponent redraws too often

by Josh Tynjala

Recently, as I was working on a Flash component (not a Flex component, mind you), I found myself wondering why the component would redraw for supposedly no reason. It had obviously drawn itself to display the current state after a property change, but sometimes it would throw in one extra redraw a bit later. If you’re unfamiliar with the way the “fl” components work, they use a system of invalidation where property changes will queue up a drawing cycle for later (typically before the next frame is drawn by Flash Player’s renderer). When the extra redraw slipped in there, it seemed that something wasn’t getting cleaned up properly during the validation cycle.

When you create an “fl” component that has children that are also “fl” components, you’re required to call a function named drawNow() on the sub-components inside the parent’s draw() function. You want to do this because many users will find it aesthetically undesirable to see those sub-components update one frame later rather than immediately. In fact, the architecture actually forces you to call drawNow() because it refuses to queue another redraw while in the “call later phase”. Of course, there are ways to force “fl” sub-components to invalidate during that call later phase if you don’t mind patching the source yourself, but that’s a different story.

Call later, or else!

That’s the background for how the architecture works. Here’s the problem I discovered. When you set a property of a sub-component from outside its parent, that sub-component will invalidate and callLater() will get it ready for a redraw. If, for some reason, the parent redraws before its sub-component, the sub-component will draw when drawNow() is called, but the redraw it independently queued up earlier won’t be removed from the queue!

The only time that the draw() function gets removed from the queue is when the callLaterDispatcher() receives the stage’s render event. Instead, UIComponent should account for the possibility that a certain functions that will be “called later” may not need to be called again if they get called early. Here’s a patch to fl.core.UIComponent that will do just that for component drawing:

protected function validate():void
{
	invalidHash = {};

	//remove draw() from the "call later" queue
	delete this.callLaterMethods[draw];
}

I simply added one line at the end of the function validate() This function gets called at the end of draw(). The default version only cleans the invalidation hash, which tracks changes to minimize the number of component parts that need to redraw. My addition also ensures that it only redraws once. If the component has validated, then there’s nothing invalid to require another draw.

It’s worth noting that an extra redraw isn’t the end of the world. For most components, it won’t cause any noticeable problems, but for some, it may impact performance. Things like the layout containers in Yahoo! Astra are a bit more CPU-intensive than most “fl” components because they need to determine ideal dimensions, the best positioning of components, and whether scrollbars are needed and that involves some nasty looping. They have a few flags to indicate whether certain changes affect the layout at all, but still, that’s not always perfect and drawing the component again for no good reason isn’t useful.

By the way, if you ever want to monkey patch a component in a specific Flash or Flex project, it’s easy.

  1. Copy the original source file into a new file. Make sure the package structure is the same as the original.

  2. Make any changes that are needed.

  3. Add the folder for the top-level package of the new component to your compiler’s “source path”. Make sure your patched source is higher in the list than the original version so that the compiler knows that it is more important. Typically, if the patched version is in the project’s own directory, it will be given more importance.

Enjoy!

New from Bowler Hat Games: Gridshock

by Josh Tynjala

Another creation from my indie game venture, Bowler Hat Games, has been released into the wild. It goes by the name Gridshock, and I see it as a bit of a combination between a couple classic puzzle games, Tetris and Collapse!. It’s a lot less of a thinker than my previous game, Chroma Circuit, but I wanted to aim at a more casual market this time. That said, I think everyone can enjoy Gridshock.

Screenshot of Gridshock
Screenshot of Gridshock

Development for Gridshock went a lot faster than with Chroma Circuit. I completed Chroma Circuit in a bit over a month, while it took me only three weeks to finish Gridshock. I think this happened for a few reasons.

  • Chroma Circuit was the very first game I built in Flash, and I spent a lot of time finding the right way to structure my projects, balance development vs. design time, and really had too strong a focus on various “administrative” things. I was able to jump into Gridshock pretty quickly because I had become very comfortable with that stuff by the end of Chroma Circuit’s development, and they moved more into the background.

  • I did most of my visual design work for Gridshock in Flash CS4. Chroma Circuit had some very specific geometric requirements that needed a lot of programmatic drawing. I tried the visual drawing approach at first, but the in-game objects simply wouldn’t fit together properly with the tiny variations made by creating the art by hand, so I had to scrap a couple early attempts and do it all the mathematical way. For Gridshock, a vast majority of the art was finished in only a couple of days, and I focused much more on programming game mechanics than programming graphics.

  • Content creation for Gridshock was much easier. Chroma Circuit had levels that needed to be designed, and I didn’t put together my Flex-based level editor until the very end (for use if I make a followup). Gridshock has a fixed playing area that doesn’t change as the game progresses. I had to focus on making the same basic play area more replayable rather than using variety like I had in the previous game.

Early prototypes for Gridshock varied quite a bit from the final product. When the initial idea for the game popped into my head, I imagined activating lights on the board from four different directions. Unfortunately, the pace of the game ended up being pretty slow, and clearing the board was absolutely trivial. There was no good way to add new rows to speed it up, so I had to rework my idea a bit. The second variation simplified gameplay to activating lights from the left and the right sides of the board, with lights settling in the middle rather than on the right edge, as in the final version. I found it was too difficult to move back and forth to both sides of the grid. When I simplified the board one last time, I also added the timer on the right that pushes a new row on the bottom. This quickly proved to be the most fun and playable version of the game.

I made another modification with my final prototype worth mentioning. It allowed players to click anywhere on the row to activate a light. In the first builds, the smaller lights on the left side that indicate color were buttons instead. Expanding the clickable area to the entire row made for fewer player mistakes, and a bit of a faster pace. Interestingly enough, this change may actually make it easier for a bi-directional version of Gridshock to be possible again, since the mouse movement won’t be as fatiguing as when I tried it the first time. I’ll certainly consider it if I make a sequel. I have other interesting ideas for board layout that may be more interesting, though.

Please go take a look at Gridshock. It’s a fun little puzzle game that’ll help you waste a few minutes of your morning or afternoon. If you haven’t played any of my games yet, I encourage you to check out Chroma Circuit too. That one’s a bit more cerebral and deliberate. I also recently finished development of my third game, called Qrossfire. It’s another casual puzzle game, and I’m pretty proud of the way it turned out. The graphics, in particular, really pop. Qrossfire will be out once I find a sponsor. If you’re a developer with an account over on FlashGameLicense, go take a look and give it a rating (thanks!). This week, I’m deep in brainstorming stage for the game I want to build next. I’m planning to branch out from the puzzle game genre, now that I’ve gotten more comfortable after finishing a few games, and I’m pretty excited. Stay tuned for more from Bowler Hat Games!

Flex Builder to Flash Builder? Scandalous!

by Josh Tynjala

Much discussion ensued in the Flash and Flex world today as Adobe announced to the community that they’re rebranding Flex Builder as Flash Builder. It’s a good change, in my opinion. Though I consider myself a Flex developer at least half the time, I think I’ve actually worked on more pure AS3 projects in Flex Builder than Flex projects. It’s clearly not a Flex-only development environment, and the new name is far more accurate and widens the audience, in my opinion. It may cause some initial confusion (as all rebranding does), but I think that any problems will clear up quickly.

I’ve noticed a few people wonder out loud if explicitly declaring that Flex is a part of the Flash brand in the product name will turn off developers who are considering Flex. We all know that a certain subset of the developer community has a lasting grudge against Flash due to its occasional misuse on the web, so this almost seems possible. However, I suggest thinking critically about that concern for a moment. Don’t you think it’s rather obvious that Flex runs in Flash Player? Is it really conceivable that a developer would never realize that Flex is really Flash-based with even the smallest amount of research? If someone is so anti-Flash that simply seeing the name of the development tool would turn them away, I would expect them to have the same reaction after a quick visit to their favorite search engine or Wikipedia to learn a little more about Flex.

Also, can we stop with the irrational fear that Flash Builder will replace the Flash authoring tool? Do you really think Adobe would decide to start ignoring the massive number of Flash content creators who draw things by hand, work with animation on the timeline, and understand symbols in the library much better than code in classes? Flash Builder is a code-centric development tool that advanced developers find more comfortable and productive. It would need years and years of development time to implement all the features needed to replace the Flash authoring tool. Not to mention the massive amounts of training Adobe would have to commit to in order to move developers and designers from one to the other. These two tools, Flash CS and Flash Builder, have many of their own unique use-cases, but they can also co-exist for the same user. I create art for my games and applications in Flash CS, while I write all my code in the current version of Flex Builder. They’re separate tools, though, and both must exist for Adobe to have any chance of making their target audiences that don’t overlap happy. You need only look at the incredible differences between the layouts of each tool to see that. For some of us, that means we need to purchase both, which may be a little expensive. Personally, I’d say that each falls under “one tool that does one thing, but does it well”, so they’re worth the price.

Changing the name of the development environment you use shouldn’t mean that you must change your job title, the experience you list on your resume (one word only, if you happen to list the tools you know), or what you write in job descriptions when you want to hire a developer. A Senior Flex Developer is still a Senior Flex Developer, regardless of whether he or she uses Flash Builder, FDT, FlashDevelop, or a simple text editor like TextMate with a command line compiler from the Flex SDK. A Flash Developer is still a Flash Developer in the exact same way. If you build Flex applications, then market your technical knowledge by only talking about Flex, Flex, Flex(!), if you feel that’s important. You don’t need to tell your clients what IDE you use, if you’re worried that the word “Flash” will cause them undue stress. Personally, I think you’re probably causing yourself too much stress by wondering how the name change will affect others.

As I’ve probably made clear, I don’t believe that the name change from Flex Builder to Flash Builder will be bad for either brand. What’s strange to me is that I’ve seen the strongest pushback coming from the Flex developers in the community. What’s up with that, guys? I consider myself one of you, but sometimes I don’t understand you. The name Flex will become much clearer because it will always be a Rich Internet Application framework that runs on Flash Player. No more IDE that’s called Flex (but does more than Flex), no more expensive server requirements. Those parts of the old Flex brand are surviving separately on their own merits now, as they should, and the framework can now be Flex without interference. The ubiquitous Flash Platform will solidify a bit more with another “Flash” branded product, and maybe the Flash name will even a little more respect from those developers who think Flash is all about animation and banner ads. I doubt that Flex will lose any respect, though. It gained ground with developers outside the Flash community because it’s a great open source framework for building RIAs, not because it somehow separated itself from Flash. Sometimes, good libraries and frameworks can change the minds of developers by being just that, good. Look at how JavaScript went from being a web toy to becoming a serious language in the last several years. I think Flex will continue to gain mindshare in a similar way, and I think it can only benefit the Flash Platform as a whole.

Pages: Prev 1 2 3 4 5 6 7 8 ...46 47 Next