Apparently, I’ve been living under a rock as I just heard wind of the fact that Adobe is planning on renaming Flex Builder to Flash Builder. Is this change a good or bad thing? I’m personally indifferent, but I can see how to certain people such as headhunters, recruiting managers and clients this might cause some confusion as a lot of people may thing of Flex as a whole different technology.

I started reading some blog posts on the subject and some of the discussions/arguments ensuing over this change, and came to the conclusion that people seem to have quite a few misconceptions and false ideas on this whole subject, “Flex Developers” included.

I’m sure this is covered elsewhere somewhere, but I felt like writing about it anyways.

So, first things first, what is Flex? At it’s simplest definition, the Flex SDK is an AS3 framework, that’s all it is. What tool you use to develop Flex apps in is entirely up to you, it’s not tied to any program at all. Sure you can use Flex/Flash Builder, or FlashDevelop or even Notepad for that matter, but no it’s not it’s own “technology” per se, it’s a framework, and it’s only AS3. By calling yourself a Flex Developer, you are not saying you know x and y programs, instead you are saying you’re an AS3 developer with a coherent understanding of the Flex SDK.

Yes, there is MXML, which is a markup language, and there is an MXML compiler (included in the SDK), so maybe the SDK is a bit more than just a bunch of AS3 classes, but nonetheless MXML compiles into .swf form, which is played back by Flash Player. If your content is viewed in Flash Player, then the tool you use to build it being called Flash Builder is completely understandable, and makes perfect sense.

Basically what I’m trying to say is that I don’t see why some people are almost up in arms over this whole thing, as looking at the name change logically, it all checks out fine.

I’ve decided that within the next couple months, I’m going to release two of my ongoing projects as open source. This is a pretty big deal to me, because both of these projects have a lot of invested time into them — they are my babies, and both could probably make me some good money if I decided to license/sell them. Not to say that selling babies for money is right…

The two projects are so far named (these names may or may not stay): Modzy and Brink.

Modzy is a CMS (oh no, not another one, right?). But Modzy is unique in that it was built with its main purpose being to manage content for XML based Flash sites. Flash CMS’es are not very common, and the ones that exist for some reason exist inside Flash. Modzy is extremely light weight and very modular, i.e. it’s very easy to design and develop a module for Modzy and you only need to install the things you need. It’s also very easy to modify the template xml schemas for outputted Modzy content.

In addition to being able to manage XML, Modzy is also able to generate static HTML pages (after all HTML IS XML isn’t it?). It’s extremely flexible and hopefully it’s useful for the world at large (and not just me and my clients).

Brink is an Actionscript 3 Framework for timeline based websites (i.e. websites built using the Flash IDE). It has native support for commonly used (and often tedious) functionality such as localization, SWFAddress, page management, global sound management, etc. It’s very intuitive and drastically shortens the development cycle for websites.

Brink is a lot further along than Modzy is, but Modzy is well in the works. I’ll probably end up releasing Brink first and then Modzy shortly after.

Initially I will be the only ones contributing to the projects, however I’m sure I will accept help from people once (and if) they familiarize themselves and offer their help.

Like me, you might have realized that events in AS3 are quite restrictive — they can never leave their heirarchy and thus they promote tight coupling. Why is this? Let’s look at an example:

Let’s say I have a button that I when clicked I want to change the background color of another MovieClip and the background music track that is playing. Using Flash’s built in event handling, I would have to do something like this:

myBtn.addEventListener(MouseEvent.CLICK, myBtnClick);

function myBtnClick(e:MouseEvent):void{
  this.root.backgroundMC.changeColor(0xFF0000);
  this.root.musicPlayer.changeSong("newSong.mp3");
}

This, ladies and gentlemen is bad software design. Why? Because everything becomes so tightly coupled. Now, if you decide to remove musicPlayer (even if you’re just guiding it out temporarily), you have to go into the myBtnClick function and comment out the line that references it. For small projects, this isn’t really a big deal but when you start building out games, intricate websites with a lot of components and pages, it gets to be quite a mess.

The solution to this is to take a different approach and build out a class to handle these types of things. This class is called EventManager and what it does is act as a liaison between components. This class is quite simple and only has 3 methods: registerInterests(), unregisterInterests() and fireEvent(). I’ve stripped down my EventManager class (the one I use in my AS3 framework) and pasted it here: http://pastie.org/528406. Take a looksie, you can even use it and modify it if you want.

So… what does this mean? Let’s take the same example above and using EventManager, do it the right way:

myBtn.addEventListener(MouseEvent.CLICK, myBtnClick);

function myBtnClick(e:MouseEvent):void{
  EventManager.fireEvent("myBtnClicked");
}

Okay, so it’s not much shorter, in terms of amount of code, but what this does is enable myBtn to not have a care in the world. All it does now is say “I was clicked!!”; it is no longer responsible for making sure that all of the necessary components that care about it being clicked do their business.

Now, of course, the background still has to change and the music still has to change, and those are handled within their respective components. Thus, backgroundMC would look like this:

EventManager.registerInterests(this, new Array("myBtnClicked"));

function catchEvent(e:String, args:Object) {
  if (e == myBtnClicked){
    changeBGColor(0xFF0000);
  }  
}

And musicPlayer would look like this:

EventManager.registerInterests(this, new Array("myBtnClicked"));

function catchEvent(e:String, args:Object) {
  if (e == myBtnClicked){
    changeSong("newSong.mp3");
  }  
}

Now, if you guide out musicPlayer or backgroundMC, everything else works as expected, no errors. It also makes all of your components very self-centered and independent. Another benefit to this approach is that it sets things up very nicely for good and proper unit testing.

All of this is “Timeline” code for simplicity’s sake. But I’m sure you’ll find that adopting this approach into your classes is very easy. This is also a very simple example and there are a lot more practical demonstrations of this concept, however I hope this sheds some light for you and you see the benefits of taking this approach.

I’d be more than happy to share some more on this subject if anybody is interested.

Alas, I did it, I made a horrible pun on an over-punned subject matter. But the real reason for this post is to enlighten and enlighten I will. The subject? How to easily share cookies across multiple domains. To some, this may seem like a simple subject: “oh yeah, you just do this and that…”, but after Googling “Share cookies across domains” I didn’t find a very useful article, so I decided to impart my knowledge upon the world.

I recently just completed a project where I needed to share data from Site A to Site B without any sort of API or anything I could really tie into. I had no access to backend code on Site B, and had to do everything on the front-end. So the task at hand was: how do I get a user’s sharing ID that was generated on Site A, from Site B?

After some pondering, the answer was quite simple. All I needed was a single <script> tag to be embedded in Site B. The src for said script tag being something along the lines of: “http://www.domain.com/js_api/user_info.php”. If you’re a quick learner, you’ve already figured out the rest, but for the rest of you, read on.

So, what are the contents of “user_info.php”? Perhaps something like:

<?php

$user_info = unserialize($_COOKIE['user_info']);

echo "var user_info = array();";

foreach($user_info as $key => $val){
  echo "user_info['{$key}'] = '{$val}'";
}

?>

Yep folks it’s that simple. And now you have all of your cookie data from Site A in JS array form on Site B. Of course, this makes several assumptions on how you’re storing data, etc. but I’m sure you’ll be able to adapt this example to fit your needs. Also, please don’t use this method to retrieve sensitive information, as it is unsecure.

You could also use this same method using backend logic on Site B using a file_get_contents() or curl call.

Off to a conference call…

So, I inherited a project from a contractor that was supposed to help me out by writing all the code for a Tournament Brackets project we’re (or should I say I’m) working on over here at the Berg. After several weeks of slow progress, we finally let him go and I decided to finish the project myself. When I finally got around to opening up the main TournamentBrackets.as class, lo and behold I found out that finishing this project would be quite an adventure. And I would have to brush up on my knowledge of ancient Africa in the process… Here’s the code that I found in that class: http://pastie.org/522429

Now, onto my rant:

I have high standards for myself and others. I write clean, understandable code, I use consistent syntax, and I comment where necessary. I also program considerately, I don’t use abstract or foreign words/concepts and I put extra effort into naming variables and functions. However, on the other side of the spectrum, I don’t obsess over doing things exactly this way or exactly that way. I adapt to situations and mold a solution around a problem; I don’t try to shove the problem to fit into my solution.

Why do I do this? Because I think it’s necessary, and it helps me sleep better. I take great pride in my work and I don’t find it acceptable if others have to point out flaws in my code or correct anything I do. As a matter of fact, I refuse to let other people fix my code (unless absolutely necessary due to a looming deadline or something). I do this not because I think they are going to screw it up, but because if I did something wrong, I am responsible and obligated to fix it.

I’m not trying to say I’m perfect or talk down to others, but I feel that a lot of developers are too lax and casual about the code they write; leaving temporary variables and methods inside of Classes, hacking something together “just to get it working” only to not fix it later, etc. The bottom line is that more developers need to take the “perfectionist” approach towards programming. A lot of people would benefit from it, especially in tightly nit groups and large projects.

And if you’re solely working on things that only you will ever have to touch, then do whatever you want to do, code how you want to code and utterly disregard what I’m saying (unless you are as self-obsessed as I am).

So, as gone over in my prior post, I decided to set about building an AS3 jabber client using the XIFF API in Flash CS3.

Now, the main barrier here was getting Flex classes to work inside Flash CS3, and while not the most elegant of solutions, it’s actually fairly easy and simple to get working.

The only thing you’ll need is the Flex SDK so you can compile your “Flex Classes Library”… Also a basic understanding of Runtime Shared Libraries and how to use them.

With no further adue, here’s how to go about it:

1) Create a new AS class file, call it whatever you want. Populate it with the following code:

package{

  import flash.display.Sprite;
  import mx.collections.ArrayCollection;
  import mx.rpc.IResponder;
  import mx.rpc.events.ResultEvent;
  import mx.rpc.events.FaultEvent;
  import mx.utils.Base64Encoder;
  import mx.rpc.http.HTTPService;
  
  public class Library extends Sprite{
    
    public function Library(){
      
      mx.collections.ArrayCollection;
      mx.rpc.IResponder;
      mx.rpc.events.ResultEvent;
      mx.rpc.events.FaultEvent;
      mx.utils.Base64Encoder;
      mx.rpc.http.HTTPService;
    }
  }
}

My file is called Library.as, you’ll notice that I import the classes and then reference them in the constructor, this is because the compiler only compiles those classes that are actually used in your class (which is a good thing).

2) Create a compile.cmd file inside the same folder as your .as class file. Populate it as follows:

@compc -source-path . -include-classes Library -output=./library.swc
@mxmlc -source-path . -o ./library.swf ./Library.as

3) Run the file. What this does is compile two different files, a .swc file and a .swf file. The .swc file is for compile-time checking. The .swf file is what will actually be used for your classes.

4) Copy the .swc into the same folder as your .fla file.

5) In your library, create a new MovieClip called FlexLibrary (or whatever your preference). Check import for runtime sharing and link it to the path of your .swf file.

6) Use the classes contained in your flex library .as file as you please and as you would like nothing funky was going on!! i.e. just a plain ol’ import mx.rpc.events.ResultEvent in any of your classes referenced by your .fla file.

GOOD LUCK!!

Let me know if you run into any issues or have any problems.

- Taka

Alright, so I have a week to write an AS3 chat client that uses jabber.

I have just finished setting up the Jabber server so now it’s time to start hacking away — I’ll keep you posted on the status.

For the server, I am using OpenFire, which turns out to be pretty nifty (and did I mention free?).

And I’m using the XIFF API from Ignite Realtime as well. So without them, I’d be going down a path that I would feel much less confident about. Using something like Unity2, or even building my own retarded backend for serving chat, which would inevitably bog down due to server load from the retardedness of constantly hitting the server every 2 seconds to check for updates. I could probably come up with a decent solution if I had more time, but 1 week isn’t enough to write your own chat server, I don’t care if you’re Superman (or Superwoman).

However, now this is interesting — the XIFF API is only supported for Flex, and though I have tons of experience in Flex, this is something I really have to accomplish outside of Flex. I think I have a really good solution to this without even having to touch any of the API code itself, if it all works out I will post the solution. If all goes as planned, and I do get this working, I will post a mini-tutorial/how-to on how to get a jabber flash client set up, from start to finish using the Flash IDE (not Flex).

So, I feel good, I’m curious to see how this will progress and turn out in the end.

Yes, I know the XIFF API is still in Beta, but so what? I’ve come to realize that most of the sites I build get a lot less testing than any of these API’s and still they get pushed live.

As long as it works consistently and stable in the end, I’ll be happy.

Happy coding,
Taka

I started a blog a while back in Blogger (which quite frankly, blows). I guess I was just lazy at the time and didn’t want to set up a new DNS entry and yadda yadda on my server, but I finally couldn’t take it any more and now I’m using WordPress, whoopdie doo.

I’ll be migrating over all of my content from my other blog.