Sorry for the inconvenience. Please redirect your browsers to http://seanhess.net
Creating a Real-time Multiplayer Game with AFCS
360|Flex is just around the corner, and in true style, I waited until the last day to send in my slides. So, in all their glory, here they are (all 3 of them).
My presentation is all about how to share data, so I created a little multiplayer game to show AFCS off. I’ll be writing a longer post about how it was implemented later, but here’s a sneak preview (be sure to invite a friend to play with you). Click to move, space to lay a bomb. Watch out, it’s buggy!
I’ll see you at 360!
Adobe has just released AFCS (Cocomo), which is an entirely hosted solution to real-time messaging and data sharing for Flex applications. AFCS is perfect for quickly creating any app that needs to share data between multiple clients. During this session, we will explain what AFCS is, what it can do, and show you how you can develop a custom shared data model to create a simple real-time multiplayer game.
Posted in Flex.
Glue 0.2 Released + New Example
Links
Announcement
I’ve release Glue 0.2, with some small, but significant changes.
Basically I decided to start creating tags that make sense
semantically, even if they are the same under-the-hood. An example of
this is <Route> which is the same as <Observe> but is specifically
designed to route view events to a controller, while observe is now
designed to observe controllers.
I also added another example: Login - this demonstrates a login
overlay, and shows how glue can simplify some of the more tricky parts
of a login screen.
Posted in Flex.
Glue - Beautiful Gooey MVC Framework for Flex
So, this isn’t an official release, but more of a call for feedback. I just finished a first-draft of a new MVC framework for Flex that I’m calling Glue.
Links
Library Example
Code Snippet
-
Design Goals
I started out with several specific goals in mind. I’ve been trying to think of how the perfect MVC framework ought to behave, and have designed Glue accordingly. I’m directly responding to the wonderful Mate framework and a few others I’ve used.
Coupling - Glue allows you to specify pieces of your app without them having any coupling to each other. Many frameworks have coupling in one direction (views know about controllers), or some, like Mate, have a map that defines all the coupling in the app (the map knows about everything, but each piece is completely encapsulated). Glue works like Mate in this sense.
Cohesion - The idea is that you put all the glue for a particular component in one place. For example, for a view, you would put injectors and event handlers in one place in the glue map. This has been an issue in every MVC framework I’ve used.
Autocomplete and Strong Typing - Mate’s introduction of the Map to tie things together was brilliant, but it gave up strong typing. Glue has strong typing throughout the map (warning: serious magic involved), except on one side of the injectors, where it uses runtime typing (it will throw an error if it can’t inject).
No overhead - Of course, there’s some overhead, but Glue doesn’t require you to create any custom events or extend any framework classes. You just define your pieces and glue them together in one file. You can use separate glue maps if you want, but you don’t have to.
Controllers Everywhere - Best practice is to call a controller function on a user action. The controller can then decide what to do with it. Controllers can observe other controllers, can inject to each other, and views can observe controllers. This super-flexible approach means you can code your app logic however you want without any technical limitations. You can also create multiple controllers that wrap the same data to create several views of that data.
Super Selectors - If you need more control than matching all views of one type, you can use the match attribute of <Glue/> to match any view by css selector. See here for details.
Other Features
- Dependency Injection
- Laziness - you can encapsulate views, or not.
Future Development
- Figuring out best practices for model adapting. I’m going to encourage creating view-level models, and coming up with a good way to convert between offshore models.
- Best practices for defining the glues - not sure if the current approach is the best. See the example and comments above for details.
Anyway, check out the source for the example and tell me what you think. There are good comments in MainGlue.mxml. I’m very open for ideas at this point, but I think I’ve captured the essence of what I was trying to accomplish.
Do you see any major flaws in the approach or goals? Please be as critical as you can. There may also be things I need to explain better. Post comments here or in the google group
Posted in Flex.
Improve Compile Times in Flex Builder
My relationship with FlexBuilder is definitely love-hate, and frequently includes more hate than love. Making sure it always compiles quickly makes a huge difference in my productivity. Anything over 10 seconds and I start to lose focus. Complex projects quickly get out of hand, and you have to constantly fight to keep compile times down.
Here are some things I have learned (some very recently) to speed things up.
- If your project has more than one application, go to project properties -> Flex applications and remove the ones you aren’t working on. This improved speeds for me by 66%
- Avoid using linked projects. Even with RSLs, these guys slow you down a lot. Any real code libraries should be included as a swc. If you have application code libraries you reuse across projects (so, not a cohesive library, like corelib or degrafa, but just a bunch of classes you reuse), include them as an external source path instead. Go to Project Properties -> Flex Build Path -> Source Path -> Add Folder. Improvement around 50%.
- Turn off Automatic Building. FB seems a lot less laggy when it isn’t compiling constantly.
- If you do have to link projects, use RSL linkage (I don’t know how to do this with Air, anyone figured it out?) .. Improvement around 50%.
- If you need to develop both Web and Air side-by-side, you can put your application code in a folder which you then include via source-path in two projects, one air and one flex. Either that or use this trick.
- Avoid embedded assets. Flex Builder doesn’t do as good of a job as it should optimizing these. Use degrafa instead of images if you can. I haven’t measured this.
- Close any unused projects (right click on them)
That’s all I have for now. I’ll add more as I think of them. What else does everyone do?
Posted in Flex.
Bifff v0.3 Released
I’ve been working / playing hard with Bifff, and have a new release. This a major change, and I’ve refactored all the core behaviors, and tried to think hard about how they should work.
I was influenced by Thomas Burleson, who posted an article on Behaviors that influenced how their interfaces work.
Go check out the documentation and the examples. I think these docs will help everyone to understand the approach a little better.
If you’d like to contribute or follow Bifff’s progress, please join the Google Group
Links
Refactors
- All Behaviors use “set target” to apply themselves. This brings Bifff’s approach more in line with Thomas’
- Lots of renaming
New Features
- Behavior Maps are injectable by Bifff and Mate
- Behavior tag generates a behavior for each match
- Many new Behaviors, see documentation.
- Added BehaviorSheet to allow you to create CSS maps
- MultiStyle behavior allows a component to specify multiple styleName’s and pick up all the classes from flex stylesheets.
- Added Bind behavior
- Added State behavior
- Much more!
Posted in Flex.
Behaviors Defined
As a part of the 0.3 release of Bifff, I’v started to add some documentation on the project page. I wrote a short page on Behaviors, and I think I did a pretty good job explaining how they can be used.
Check out the Behaviors page on the Bifff wiki.
Visit the full documentation (so far) here.
Posted in Flex.
Bifff 0.2a Prerelease - Group + Name
A few days ago I introduced Bifff in my post - jQuery for Flex. I’ve since picked a name, created a google group, released a new version, and figured out a few more uses for it. Yes, I picked the name Bifff, which stands for Behavior Injection Framework for Flex
Important Links
Thoughts after a few days
I’ve been trying to use Bifff on my projects, and have come across a few tips that may be useful.
I created a debugger than can be very useful. Set debug=”true” on your behavior map, then if you double click on the map’s target, it will dump all of its info to the console, including which selectors match which targets, and the display tree of the object you clicked on.
The more complicated the selector is, the more likely you will screw something up and get it wrong. I’ve found it is much better to have a selector based on one id or class with a long name, than to create a complicated selector with descendants, etc.
It can be very useful for applying components of a certain type within some view of your application. So you can say any button in my login form should have style X. (see new Styles and Set behavior updates)
New Release
Version 0.2 includes some updates.
- <Styles> tag adds and removes styles, and runs the selectors against it again
- Selector caching - a selector will not be applied twice to the same target
- <Set> can read styles from a stylesheet. <Set style=”bob”/> will take the .bob style from the StyleManager and set everything on the target.
- Bug fixes + Removed delay on behavior map.
You can get the new release on the home page, here.
Posted in Flex.
jQuery for Flex - Behavior Injection framework
Update - Please visit http://bifff.seanhess.net for more information and to be directed to the google group
Update - These examples are out-of-date. Visit the url above for the latest examples and downloads.
I’ve just finished my pre-alpha version of a Behavior Injection framework for Flex. It adds support for functionality similar to jQuery for flex, along with support for a more complete CSS syntax. The approach is slightly different than jQuery, and hopes to play along with Flex’s strengths as well.
Downloads and Examples
- Selectors Example - old
- Behaviors Example - old
- Download SWC v0.1a - old
- GitHub Repository
Background…
I love jQuery. I love CSS. jQuery allows you to use css selectors to select objects on an html page, and dynamically change things, add behavior, and do whatever you want. I’m calling that “Behavior Injection.” It allows you to print out semantic html, and inject functionality from outside.
Flex is a totally different beast. It has very good support for making encapsulated components, so the need isn’t as great as for Javascript. However, the ability to inject behavior can really help decouple your components from your application framework, and the css support is miserable.
The Approach
You define <Selectors> in a <BehaviorMap> that match certain views as they are created. When a match is found, it applies all of its behaviors to the matched view. Behaviors can be anything, all they have to do is implement IBehavior, which has one method, apply. The behavior then “applies” itself to the matched object.
Selector Syntax
Visit the links above for more complete examples, but here’s a taste of what the syntax looks like. You can select by Tag, by styleName (multiple classes are supported), by id, by superclass, by interface, etc. It also has support for wildcards “*” and direct children “>”.
-
Behavior Syntax
I won’t bother posting an example inline, the syntax is quite different for each behavior I’ve included in the core.
Possible Uses
- Adding Full CSS Support to Flex (You can even set width/height)
- Tying encapsulated views into your application framework via events (Mate/Cairngorm)
- Adding Dependency Injection to a framework that doesn’t have it (Cairngorm!)
- Improving DI of other frameworks with CSS selectors
- Adding custom behaviors that do amazing things
- Skinning 3rd-party components that aren’t stylizable
- Blah, blah, I don’t know, let’s see if anyone else thinks it is useful
Limitations / Known Issues
I am using styleName to set class names, so you can say <mx:Button styleName=”big fat important”/> but if you create a .big style in a regular stylesheet, it won’t apply. I also ran out of time trying to figure out how to apply a CSSStyleDeclaration to a component by hand. The <Styles> behavior needs this to function propertly.
Note that the <Set> tag happens on creation complete, meaning it will override any local settings. This is very different from how css works.
The <Swap> and <Contents> tags are still in Flux. I had some weird ideas for <Swap> when I started out, and have since abandoned them. <Contents> needs a way to add copies of views before it will be really useful.
For custom behaviors - Right now a behavior is really a data object that knows how to apply itself to several different views. They should not store state, since the framework uses the same one for each one.
The Future
I’m mostly interested in peer review at this point. I’d like some feedback on the idea, the implementation, and the approach. After that, I suspect a beta release wouldn’t take too long.
It wouldn’t take long to write a parser for a real stylesheet. That would give us all the selectors this framework has + the ability to set properties instead of just styles.
Finally, well deserved thanks must be rendererd to the Mate crew for stolen code and ideas, and to the jQuery guys for their amazing framework.
A new approach to asynchronous testing in FlexUnit
I have run into the need to test asynchronously more frequently than I thought I would. This comes into play somewhere near the fuzzy line between unit and integration testing, but either way, it is a must-have. A recent example of this is executing asynchronous statements on an SQLite database in Air.
The old way
FlexUnit has support for async testing built in, but I didn’t particularly like the implementation. In Asynchronous Testing with FlexUnit, shows a simple example of how this is done. Basically, you wrap your event handlers in a call to addAsync. If you don’t do this, flexunit assumes there are no more asserts in your test and moves on.
That’s fine, but it gets more complicated if you need to chain multiples together. In another example, How to handle events in a TestCase? Daniel shows how to do this. He mentions that you can
What I don’t like
First, it’s annoying to have to wrap an addAsync to every step of the chain. Second, it doesn’t work very consistently when you chain events. Third, it doesn’t work with responders, only with events. (Don’t try wrapping addAsync around a responder, it won’t work).
The Solution!
I wrote a small class, AsyncTestCase, that extends TestCase and adds support for two functions: start and finish. Basically you call start at the beginning of a series of asynchronous steps, and finish at the end.
-
This seems much more intuitive to me, and works quite well. You only have to worry about it at the beginning and end, and don’t have to do anything screwy with your handlers. It works perfectly with chained events, and also works with responders. If you use it with responders, it will say it it passed but registered 0 asserts for the test. However, if the same asserts happened to fail, they will actually fail and let you know.
I’m interested in any feedback on the approach.
Posted in Flex.
