Pulse Particles MXP

Published on October 23, 2009 in Uncategorized. 1 Comment

Sorry for a lack of posts recently, been really busy with project work. I’m on vacation next week, so I’m trying to get caught up on posts today.

Dominik Pesch over at 11com7 has created and sent me a .mxp package for Pulse Particles. This package adds the particle explorer as a new window within the Flash authoring environment and makes the component available from the standard libraries.  This could really make it easier for designer-types to use.

Download PulseParticlePackage.mxp (4mb)

Thanks Dominik!

Arduino fun

Published on September 7, 2009 in Uncategorized. 2 Comments

This morning I got to play with a recently purchased arduino board.  Let me tell you, these things are amazingly easy to use.  Everyone should give it a try at some point.  I’m not going to try to write a how-to or a tutorial right now, but let me illustrate just how easy this was.

1) Plug board into USB
2) Install Arduino software
3) Select example blink sketch (application) and upload

And suddenly you have a blinking LED (one is build onto the board).

So then I plugged in a little servo I had lying around, found the servo library.  Wrote a little sketch, and I was able to make the servo go to any position by communicating with my desktop computer over USB.  Total time, maybe half an hour.  Controlling servos isn’t the easiest thing in the electronics world since you have to worry about timing signals & whatnot.  But Arduino boils all that down to 2 or 3 lines of code.  Wow.

So next I set off to grab as3glue, which includes a serial port/tcp gateway so you can control the arduino through flash.  After maybe 20 minutes of tinkering I have an amazing high level API I can use in flash to control the board. (I ended up using arduino2flash instead of serproxy since serproxy wouldn’t work for me.)

Here’s a little AS3 snippet that uses a utility class I wrote to control 4 LED’s attached to the board from flash.

  1.  
  2.   arduino = new BuildBoardArduinoController(); 
  3.   TweenMax.to(arduino, 2, {led1:255, yoyo:0, ease:Quad.easeIn});
  4.   TweenMax.to(arduino, 2, {led2:255, yoyo:0, delay:1, ease:Quad.easeIn});
  5.   TweenMax.to(arduino, 2, {led3:255, yoyo:0, delay:2, ease:Quad.easeIn});
  6.   TweenMax.to(arduino, 2, {led4:255, yoyo:0, delay:3, ease:Quad.easeIn});
  7.  

That code causes each LED to fade in and out over and over. Wow… tweening physical computing? Neat.

3896960836_fa12762040

I had long been thinking about tinkering with one of these. If you have too, just do it. $30 for the board, and an hour of your time will get something working.

Next up, building a Build Notification system that will read in our CruiseControl status at work and let people know what’s going on.

Implementing interfaces in MXML

Published on July 27, 2009 in Uncategorized. Closed

This is probably old news by now, but I just found out you can implement an interface in an MXML component. In the past I’ve always made a base class that implemented the interface and had the MXML inherit from that. A big waste of time for small components.

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml"
  3.    implements="com.roguedevelopment.schedule.ui.ApplicationView">
  4. …
  5. </mx:Canvas>

You just need to add an “implements” attribute to your root tag and specify the full class name. I’ll stick to the base class for large components, but this is the way to go for small, quick things.

Learning Flex 4…

Published on July 18, 2009 in Uncategorized. 3 Comments

I’ve been learning some Flex 4 stuff over the past week. One word… wow. Even without Catalyst, this is going to speed up my development a lot. Things like skinning a button with a complex code generated skin is now easy. I’ve been working on a site for my Wife’s budding photography business over at: Jessica Hughes Photography

It’s still a rough site, but I figure Flex 4 took me about the same amount of time to make it as it would have in Flex 3, but that includes learning about all these new features.

Profiling experience

Published on July 13, 2009 in Uncategorized. 4 Comments

Today, I happened to have Activity Monitor open while I was working on AgileAgenda and noticed something peculiar.  It was sucking up 200% of CPU time (multiple cores…)

So I fired up the application in the Flex profiler.  Let it sit for a minute, clicked the “Reset Performance Data” button, waited another few seconds, and then clicked the “Capture Performance Data” button.  The result was odd.

Nothing was actually in code I could touch and didn’t explain why it was happening.  There had to be something going on to peg out the CPU like that.  So I hit up the Flex preferences panel and found something I had forgotten about.

By default, the profiler excludes a whole bunch of flex and flash related classes from the profiler.  So I removed those exclusions and unchecked the box.  Went back to my profile window and low and behold, this is what I saw:

So now I had an idea of what was happening.  It looks like that indeterminate progress bar (which wasn’t on the screen anymore by that point) was sucking up some render time.

So I peeked at the ProgressBar flex code.  They’ve got a timer in there that gets started, and is stopped when the progress bar is set to invisible.  But that doesn’t end up accounting for cases where we just bump to a different parent object in a view stack.  So that timer sits there, happily spinning and consuming resources.

I added some code in to manually set the visiblity of the 2 indeterminate progress bars I had and ran.  Bamn, success.

So I learned (or re-learned?) two things today.

  1. When profiling, if you don’t see anything happening check your filters.
  2. Be very careful with indeterminate progress bars in flex.

Note: I got similar results both in the debugger (ADL) and when running the application stand-alone as a bundled application.

Nudger – my latest mini-project

Published on June 26, 2009 in Uncategorized. 2 Comments

A lot of times I find myself opening up Photoshop just so I can paste a screen shot of an application I’m working on in there and move some elements around to see where they look best.  I might grab a button and nudge it over to one side until it lines up somewhere.  And I use that info to go update my app.

Photoshop is way overkill.

So say hello to Nudger, a little AIR app I whipped up with ObjectHandles, Flex 4, and Moccasin

Nudger.air (1.3mb)

To use it, take a screenshot.  I use Skitch on OSX and just hit Print Screen on my Windows machine.  Then drop or paste that screenshot onto Nudger.  It’ll load up the image.  From there you can click & drag to define an area to nudge.  Then move it around with the handles that appear.  You’ll get feedback while you do it.

Here’s some screenshots (I’m working with a screenshot of the Flash CS4 splash screen here)

Step 1, right after pasting it.

Next, I select an area of the image with the mouse.

And finally I move it around.

The grid below the selection tells me the original location/size of the selection, the new location/size, and how much that differs from the original.  If this were an app I was working on, I’d know I need to bump those objects over by 221 pixels and down 5.

Of course you can make multiple selections and move lots of stuff around.

Why I like my proposed catalyst workflow

Published on June 25, 2009 in catalyst and flex. 6 Comments

I’ve been an advocate of compiling from Catalyst to a swc in a two previous blog posts.  (A Flash Catalyst / Builder workflow method , Compiling FXP->SWC, a Catalyst workflow) I’m hoping to explain why I prefer that workflow here.  With big pretty pictures!

First, let us look at the catalyst workflow that’s been all the rage in the demos online that introduce catalyst (like this one).  Refer to the diagram below.

workflow1

Pros:

  • Super simple

Cons:

  • Limited to one designer and one developer
  • Limited to a single catalyst project
  • Developer can’t start until designer is finished
  • Once the designer has handed off the file, they can’t make edits.

If your software development process can handle those cons, this “super simple” option will rock for you.  But for anything beyond the most trivial of projects, those restrictions will be a deal breaker.  I consider this workflow similar to editing Actionscript in keyframes on the timeline in Flash.  It works, it’s simple, sometimes it might be the right way of doing things, but most of the time it’s like shooting yourself in the foot.

Something that hasn’t been as widely discussed, but that is still part of the official offering from Adobe goes something like this diagram:

workflow2

In this scenario, the developer creates a plain old Flash Builder project.  While he’s doing that, the designer creates a .FXPL file.  The developer takes that .FXPL and imports it as a Flex Library project, which he then references from his main project.  (Just import the .fxpl like a .fxp, the correct type of project is auto-created) Later, the designer can make changes in Catalyst.  Then the designer exports a new .FXPL file and the developer can re-import it (re-import steps below).

Optionally, the developer can move the classes into a package structure inside Flash Builder.  If there will be more than a single .fxpl imported, this is required since there will be name conflicts.  Currently, the refactor in Flash Builder doesn’t work 100% for this as the skin references aren’t updated, hopefully that’s just a beta-bug and will be fixed.

This is a huge improvement over the previous workflow and will probably work out great for most people.

Pros:

  • Developer and Designer time can overlap
  • You can have multiple designers and developers (by repeating that middle bit in the diagram
  • Can use a package structure
  • An “official” Adobe method

Cons:

  • Developer is not allowed to edit the Flex Library project that is imported, he can only use classes/assets from it in his main project.
  • Every time a new .FXPL comes out, the developer must (I bet some of this could be automated!):
    1. Delete the current Flex Library project
    2. Import the new .FXPL
    3. Modify the main project to reference this newly imported project
    4. Move the classes in the Flex Library project into a new package structure
    5. Rebuild the swc
    6. Rebuild the app
  • Does not retain the Main class from catalyst, so all work must be done in sub-components

That’s doing a lot better in the scalability department.  It’s doing a bit worse in the complexity department.

What if we could automate some of the process of turning a .FXPL into a .swc?  Or even better, what if we could turn a .FXP into a .swc?  Then we’d have something that looks very similar to the previous workflow, but with one important difference:

workflow3

Pros:

  • Developer and Designer time can overlap
  • You can have multiple designers and developers
  • The script automatically converts the Main catalyst component from an Application object to a Group object so you can use it in your project.  (Coming Soon!  The next version of my script will)
  • Automatically uses a package structure

Cons:

  • Developer is not allowed to edit the Flex Library project that is imported, he can only use classes/assets from it in his main project. (But he only ever sees a swc now, so no worries)
  • Every time a new .FXP comes out, the developer must somehow get the new .swc (more on this below)
  • Requires a script to run (requiring whatever environment that script was written in)

That may seem like a fairly minor difference, but imagine how much better it scales.

Instead of a single developer and a single designer, picture a whole team of them.  If every developer needs to go modify their workspace every time any designer makes a new .FXPL, they’ll end up spending too much of their time just managing their build environment.  The more people you add, the worse it gets.

If that script can be run through a command line script, it can be automated.

Most teams that consisting of more than a couple people use a version control system.  That system can be used to distribute .swcs that are generated from the catalyst projects.  Many version control systems have hooks integrated into them so they run a script whenever a certain file or directory is modified.  If yours doesn’t have than a simple scheduled job could do it.  This can simplify the process even further to:

  1. Designer checks .FXP into version control
  2. Script runs, automatically generating the .swc
  3. Developers sync up, getting the new .swc

That means, once it’s set up there is no additional work that needs to be done.  The designer works in his tool.  The developer works in his.  Assets are magically propogated.

If you don’t use a version control system, scheduled jobs and a shared network folder could do the same thing.

This solves the scalability problem.

workflow4

All that is good-and-well, but that script to generate the .swcs must be awfully hard to do, right? Wrong. It was easy. It’s done. Go give it a try.

Blog post describing the script.
Download: fxp2swc.rb

Any windows based Ruby developers want to take a crack at updating the script to work correctly on windows?

My wish: type Checking in CSS

Published on June 12, 2009 in Uncategorized. 1 Comment

I wish there was type-checking in CSS for Flex applications. Way too many times have I come across a style that either:

  1. Uses a style attribute that’s not valid for the component type
  2. Uses a value for an attribute that’s the wrong type

These are the types of issues that should be caught at compile time.  I’m not sure if it’s possible to do with CSS since it’d be a really complex problem to try and solve.  Especially with “nested” styles where a style attribute is specifying the stylename of a sub component.

Hell, maybe I am really wishing for something other than CSS for flex apps.  I wonder what a nice type-safe format for specifying style information might look like.  It’d have to retain the centrally-located benefit of CSS, and probably not sacrifice much of the flexibility.

ByteArray writeUTF vs. writeUTFBytes

Published on June 6, 2009 in Uncategorized. Closed

I just got bit by using writeUTF instead of writeUTFBytes, I knew they worked differently, but it took me a couple google searches to figure out why.

writeUTF appends a 16 bit length, and then your actual data
writeUTFBytes simply appends your data

So why does writeUTF work like that?

When you read data back in, readUTF can get how long the string to read is, and then read exactly that much in. On the other hand, readUTFBytes just reads everything back. Seems like a minor difference, but imagine these two scenarios.

This works perfectly:

  1.  
  2. myByteArray.writeUTF("Hello World");
  3. myByteArray.writeFloat(100);
  4. …
  5. a = myByteArray.readUTF();
  6. b = myByteArray.readFloat();
  7.  

This next example does not work because the readUTFBytes also reads in that float we wrote, so the readFloat call has nothing to retrieve:

  1.  
  2. myByteArray.writeUTFBytes("Hello World");
  3. myByteArray.writeFloat(100);
  4. …
  5. a = myByteArray.readUTFBytes(myByteArray.length);
  6. b = myByteArray.readFloat();
  7.  

On the other hand, the writeUTF method can only handle strings up to 64k float. So if you have an arbitrarily sized string it’ll eventually failed. This is what I ran into.

So here’s a couple simple rules for choosing which to use:

1) If you need to write arbitrarily sized large strings, use writeUTFBytes, but don’t write anything after it.
2) If you need to write multiple items to your byte array and read them back that way, use writeUTF, but don’t exceed 64k strings
3) If you need to create a byte array with no “header” of that leading length, use writeUTFBytes (like if you’re making a stand-alone file to inter operate with some other system)

Compiling FXP->SWC, a Catalyst workflow

Published on June 5, 2009 in catalyst, development and flex. 1 Comment

The other day, I blogged about an alternate workflow to Catalyst. It was somewhat confusing with a few steps involved. Towards the end of the post I had a couple wishes including:

  1. Let me select a package that components get created in.
  2. Export a swc with everything in it so we don’t have to go through most of this.

Last night I wrote a ruby script capable of doing exactly those two things.  I call it fxp2swc.rb.

Using the script is simple.  First open it up and set the two variables at the top.

  1. @flex_dir = "/Applications/Adobe\\ Flash\\ Builder\\ Beta/sdks/4.0.0";
  2. @default_package = "com.roguedevelopment.catalyst";

The flex_dir just tells the script where your Flex SDK is. The default_package tells it what package you want your catalyst based components made in.

After you edit that, put the script in the same directory as your .fxp files. Run the script and you should see output like this:

$ ./fxp2swc.rb
=== FCTest.fxp
 Extracting to FCTest.fxp.tmp
 Creating directory FCTest.fxp.tmp/src/com
 Creating directory FCTest.fxp.tmp/src/com/roguedevelopment
 Creating directory FCTest.fxp.tmp/src/com/roguedevelopment/catalyst
 Creating directory FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Copying Main.mxml
 Copying FCTest.fxp.tmp/src/components/Background.mxml -> FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Copying FCTest.fxp.tmp/src/components/CustomComponent1.mxml -> FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Copying FCTest.fxp.tmp/src/components/LoginButton.mxml -> FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Copying FCTest.fxp.tmp/src/components/LoginForm.mxml -> FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Copying FCTest.fxp.tmp/src/components/TextInput1.mxml -> FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Removing old source locations
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/Background.mxml
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/CustomComponent1.mxml
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/LoginButton.mxml
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/LoginForm.mxml
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/Main.mxml
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/TextInput1.mxml
 Creating swcconfig.xml
 Invoking compc -load-config+=swcconfig.xml
Loading configuration file /Applications/Adobe Flash Builder Beta/sdks/4.0.0/frameworks/flex-config.xml
Loading configuration file /Users/mhughes/Dropbox/fxg2swc/swcconfig.xml
/Users/mhughes/Dropbox/fxp2swc/FCTest.swc (1463574 bytes)
Deleting temp dir
Done!

You now have a one .swc for every .fxp file! As easy as that!

Take the swc, and plop it into the “libs” folder of you Flash Builder project, and you can start using the components from it. They’ll be in a package that starts with your default_package variable and ends with the name of the .fxp you compiled. So for my example FCTest.fxp, the package is: com.roguedevelopment.catalyst.FCTest

Here’s a quick example of what it looks like to use one of those components:

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
  3.      xmlns:s="library://ns.adobe.com/flex/spark"
  4.      xmlns:mx="library://ns.adobe.com/flex/halo"
  5.      minWidth="1024" minHeight="768"
  6.      viewSourceURL="srcview/index.html"
  7.      xmlns:FCTest="com.roguedevelopment.catalyst.FCTest.*">
  8.  
  9.         <FCTest:Background verticalCenter="0" horizontalCenter="0" />
  10.  
  11. </s:Application>

You can still use the composition or inheritance methods of using those components that I blogged about the other day. Here’s an example showing that with view-source enabled.

I’m on OSX using Ruby v1.8.6 with this script. Your mileage may vary on other platforms. Two things that will likely need to change for Windows users:

  • The compc call should use compc.exe
  • It uses the unzip command line utility, not sure if that’s a standard tool on Windows