Category Archives: flash builder

Flash Player 11, AIR 3, and Flex/Flash Builder 4.6

Posted on by
6

Today is a pretty big day for Adobe developers. We’re officially announcing Flash Player 11, AIR 3, and Flex 4.6 and Flash Builder 4.6. The bits will be available in early October, but we’re announcing things today to help provide developers with information on what’s coming. I’ve been at Adobe for 4 years now and it’s been a very interesting 4 years as the landscape has evolved. It’s definitely been an up and down ride for Adobe developers, but the world has never been a better place for interactive developers, and these set of releases provide a ton of functionality aimed at helping Adobe developers create content in the most cutting edge places.

Gaming

We’ve been doing a lot of work to help enable console-esque games on top of the Flash Platform. Flash Player 11 includes Stage3D, which is going to open up a whole new world for game developers. Zombie Tycoon and Tanki are initial examples of what can be done and I can’t wait to see what comes of it. I’m reminded very much of the early days of Flash where a bunch of creative people were given a technology that was pretty open-ended and poked and prodded to create a bunch of very cool things. I think we’ll see that kind of revolution with Stage3D because of the ubiquity of Flash and the creativity of our developer community. Also in the gaming bucket is a framework we’re working on called Starling, which leverages Stage3D to create a super-fast way of doing parts of 2D games. It’s a great merger between the underlying technology/performance benefits of Stage3D and the kinds of things people want to do in 2D games. I think it’s also going to see some traction beyond games as agencies start to use it to enhance 2D content.

Mobile Applications

Flex and AIR have really found a great place in mobile applications. The performance enhancements in 2.7 made building native-experiences with AIR possible and we’ve seen some great examples of that in action including Machinarium and Caltrain Times. I’ve been impressed with performance on my 100 Days of Exercise application on iOS. I’m incredibly, incredibly excited by what this means for Flash. There’s a definite need to create mobile apps that can be deployed to multiple application stores. The Flash Platform provides a way to create great looking, high-design applications with near-native performance that can run on multiple devices. That’s a big deal.

And this release of AIR 3 goes where we haven’t gone before on the Flash Platform with native extensions. Now if there are features that aren’t included in AIR, like access to a credit card reader, you can build those extensions in native code and then link them to your AIR applications and leverage those libraries. It’s a great mix of native for specific use cases and AIR/Flash for fantastic user interfaces. It’s a big, big, big deal to be able to extend the platform and it’s a huge step.

I also think we have one of the best mobile-tool chains out there. Flash Builder 4.6 is going to help with creating those native extensions while also enabling the use of captive runtime in AIR so your applications don’t need to rely on the external AIR runtime on Android. Combine that with the enhancements that are coming in Flex 4.6 and it adds up to a world class mobile development platform that lets you reach more devices that matter. Flex 4.6 is especially exciting because of the new components that have been added. Flex and AIR are far and away the best toolset for interactive developers or any mobile developer who needs to create content for multiple devices. The apps you can build with Flex and AIR are going to stand out from the boring, standard apps that have started to litter app stores. Creativity will win the day and creativity is at the core of Flex/AIR.

Beyond

So this is a huge release, and I’m excited. But I’m also excited about the future of Adobe and how we are responding and will continue to respond to the evolving marketplace. As Danny Winokur, VP and GM of the Flash Platform, said recently:

“We’re not so concerned about what the right technology is for that as long as we’ll be able to deliver those experiences. We’re working with Microsoft and other members of the HTML community including Google, Apple, and others to enable rich experiences on HTML5.”

This is not a technology war. Adobe is about enabling developers to build the best possible experiences with the technology they want. We want to build tools and services that cater to that ethos. That takes the form of cutting-edge gaming features like Stage3D and world-class mobile app features with Flex, AIR and Flash Builder. But HTML5 is exciting for a lot of reasons, and Adobe will help developers there as well. If you’re an interactive developer, the future is very, very bright for you.

So you better get a good pair of sunglasses.

Enabling iOS/BlackBerry/Android After Creating a Flex Mobile Project

Posted on by
Reply

I just noticed this today and figured it might be helpful. If you create a Flex Mobile project with Flash Builder 4.5.1 and choose to only enable one or two of the platforms, you can always go back and change your mind later on using the Properties Panel under Flex Build Packaging. Just select the platform you want and check the “Enable this target platform” box.

SourceMate 3.0 Released

Posted on by
1

SourceMate was by far my favorite plugin for Flash Builder 4 and they’ve been just as busy with Flash Builder 4.5. They just released SourceMate 3 today and it looks like it’s going to be very helpful for Flash Builder 4.5 users. Definitely check out the full feature list but some of the ones that look most interesting to me are:

And the localization features look really helpful for anyone building applications that need to make use of resource bundles for localized apps.

Major props to the SourceMate team.

Using The PlayBook AIR SDK with Flex “Hero” Mobile Projects

Posted on by
4

When I first started doing PlayBook development with Flash Builder “Burrito” I found it kind of confusing how the PlayBook SDK installed itself. During the install process, the PlayBook AIR SDK installer prompts you for two locations; one is the location of your Flash Builder installation and the second is an existing AIR 2.5 SDK installation. If you’re using Burrito, it drops a new SDK into the sdk folder of the Burrito install (blackberry-tablet-sdk-0.9.x) and then defaults to the 4.5.0 sdk in the next screen as the AIR 2.5 SDK.

If you’re used to doing Android development then the first thing you probably did was go to create a new Flex Mobile or ActionScript Mobile Project using the PlayBook SDK. Unfortunately you’ll get this screen:

Luckily, when you selected the existing AIR 2.5 SDK (assuming you put it in the default 4.5.0 folder or any version of the “Hero” SDK with mobile components) the PlayBook installer has already linked the PlayBook SDK to that sdk. So when you create a Flex Mobile project with the Flex Hero SDK set you’ll see the required QNX .swc files already linked:

But I ran into an issue when I tried to upgrade. My colleague Mihai has a great runthrough of how to migrate from the 0.9.1 PlayBook SDK to the 0.9.2 SDK. But after I tried to upgrade all of my Flex Hero projects kept referring to the old 0.9.1 SDK. And any new Flex Hero projects I created would reference the old 0.9.1 installation. What I discovered was that something during the install process wasn’t overwriting the link in the 4.5.0 folder to the old SDK.

It seems like there is a bug that won’t overwrite the reference to the 0.9.1 correctly but the SDK is referenced in the Flash Builder preferences under Target Platforms. I just had to change it from 0.9.1 to 0.9.2 and all of my old projects as well as all of the new projects started using the new version.

Skinning PlayBook Components

Posted on by
9

I’ve been having a lot of fun with the PlayBook. It’s really nice to be using ActionScript 3 to write a “native” application and the QNX components have been really good. One of the things I wanted to do right away was skin them to customize them for the Pintley app I’m building. Luckily, if you’ve spent any time doing Flash, it’s pretty straightforward. The main issue is that the SDK is still fairly new so there were some small things I had to figure out.

There are basically three ways you can skin components on the PlayBook: with a Flash Professional SWC that contains the graphic objects, with images, and using the AS3 drawing API. I’ll show off the last two.

Skinning with Images

What I wanted to do was skin a TextInput and a Button for my login page. The PlayBook SDK has a few classes that are specifically for skinning, which I was able to check out via the documentation. There’s an entire package qnx.ui.skins that has classes for skinning. It looks like, based on this page, that most of the default skins, are images. So I tried that first. What I found helpful was to grab those stock images, bring them into Photoshop, and start tweaking them.

I create three different PNGs for each of the states the TextInput has: up, down, and focus. Once I have those, I embed them in my custom skin class and use the specific QNX APIs to set the look and feel. The class extends the qnx.ui.skins.text.TextInputSkin class, which is the base class for creating a TextInputSkin. Using the attributes on the Embed tag you can set the numbers to make the nine-slice scaling work for your image.

The method to override is the initializeStates method. That’s the best place to register properties for states with the QNX component model. Then there are two other methods to use in that method. The first one, setSkinState, just associates a specific skin with a specific state. The last line of code, showSkin, takes a skin class and that’s what the component will use as the default skin.

That’s pretty much all there is to it. Here’s the class:

package com.pintley.skins
{
     import flash.display.Sprite;
 
     import qnx.ui.skins.SkinStates;
     import qnx.ui.skins.text.TextInputSkin;
 
     public class PintleyImageTextInputSkin extends TextInputSkin
     {
          protected var upSkin:Sprite;
          protected var downSkin:Sprite;
          protected var focusSkin:Sprite;
 
          [Embed(source="/assets/skins/TextInputUp.png",
               scaleGridLeft="22",scaleGridRight="350",
               scaleGridTop="18",scaleGridBottom="38")]
          private var UpGraphic:Class;
 
          [Embed(source="/assets/skins/TextInputDown.png",
               scaleGridLeft="22",scaleGridRight="350",
               scaleGridTop="18",scaleGridBottom="38")]
          private var DownGraphic:Class;
 
          [Embed(source="/assets/skins/TextInputFocus.png",
               scaleGridLeft="22",scaleGridRight="350",
               scaleGridTop="18",scaleGridBottom="38")]
          private var FocusGraphic:Class;
 
          public function PintleyImageTextInputSkin()
          {
               super();
          }
 
          override protected function initializeStates():void
          {
               super.initializeStates();
 
               // Up State
               upSkin = new UpGraphic();
               setSkinState(SkinStates.UP,upSkin);
 
               // Down State
               downSkin = new DownGraphic();
               setSkinState(SkinStates.DOWN,downSkin);
 
               // Focus Skin
               focusSkin = new FocusGraphic();
               setSkinState(SkinStates.FOCUS,focusSkin);
 
               showSkin(upSkin);
          }
     }
}

Skinning with the Drawing API

Another way to skin the components is using the drawing API. This one is mostly similar to using images with a couple of minor changes. Create the variables in the same way, and override the initializeStates function. Skinning with the drawing API also uses the same methods as the images. setSkinState works the same way and showSkin sets the default skin.

The main difference is that there is an external function in this example, which is where the drawing takes place. Since the different states of the component will look generally the same, I pass in some variables to change the appearance based on which state it’s being drawn for. The method gets called in the initializeStates function after the skin sprites are initialized. You could also just do the drawing in the initializeStates method, but this is a bit better in terms of code reuse.

package com.pintley.skins
{
     import flash.display.DisplayObject;
     import flash.display.Sprite;
     import flash.filters.DropShadowFilter;
     import flash.geom.Rectangle;
 
     import qnx.ui.skins.SkinStates;
     import qnx.ui.skins.text.TextInputSkin;
 
     public class PintleyTextInput extends TextInputSkin
     {
          protected var upSkin:Sprite;
          protected var downSkin:Sprite;
          protected var focusSkin:Sprite;
 
          public function PintleyTextInput()
          {    
               super();
          }
 
          protected function drawSprite(item:Sprite,lineThickness:int,shadow:Boolean=false):void
          {
               var innerShadow:DropShadowFilter = new DropShadowFilter();
                    innerShadow.distance = 10;
                    innerShadow.angle = 40;
                    innerShadow.strength = .15;
                    innerShadow.blurX = 25;
                    innerShadow.blurY = 25;
                    innerShadow.inner = true;
 
               item.graphics.beginFill(0xffffff,1);
               item.graphics.lineStyle(lineThickness,0x3c2414,1);
               item.graphics.drawRoundRect(0,0,350,30,5);
               item.graphics.endFill();    
               item.filters = [innerShadow];
 
               if(shadow)
               {
                    var dropShadow:DropShadowFilter = new DropShadowFilter();
                         dropShadow.distance = 0;
                         dropShadow.blurX = 21;
                         dropShadow.blurY = 21;
                         dropShadow.angle = 0;
                         dropShadow.strength = 1;
                         dropShadow.color = 0x3c2414;
 
                    item.filters = [innerShadow,dropShadow];
               }
          }
 
          override protected function initializeStates():void
          {
               /**
                * UpSkin
                **/
               upSkin = new Sprite();
               drawSprite(upSkin,2);
               setSkinState(SkinStates.UP, upSkin );
 
               /**
                * DownSkin
                **/
               downSkin = new Sprite();
               drawSprite(downSkin,3);
               setSkinState(SkinStates.DOWN, downSkin );
 
               /**
                * FocusSkin
                **/
               focusSkin = new Sprite();
               drawSprite(focusSkin,3,true);
               setSkinState(SkinStates.FOCUS, focusSkin );
 
               showSkin( upSkin );
          }
     }
}

One last example that I have uses the image method but skins a button instead of the TextInput control. One thing I’ve noticed about the QNX controls is that some of the components (like TextInput) have their own skin files that can be subclassed, while others, like Buttons, have skins that look like they just subclass UISkin. So instead of calling super.initializeStates() like I did with the TextInput, with the Button, I just override initializeStates() and put the code there.

Update: Thanks to a comment below, I realized that when you extend UISkin, the skinned objects have to be of type DisplayObject, not Sprite.

package com.pintley.skins
{
     import flash.display.DisplayObject;
 
     import qnx.ui.skins.SkinStates;
     import qnx.ui.skins.UISkin;
 
     public class LoginButton extends UISkin
     {
          protected var upSkin:DisplayObject;
          protected var downSkin:DisplayObject;
          protected var selectedSkin:DisplayObject;
          protected var disabledSkin:DisplayObject;
 
          [Embed(source="/assets/skins/LoginButtonUp.png")]
          private var UpGraphic:Class;
 
          [Embed(source="/assets/skins/LoginButtonSelected.png")]
          private var DownGraphic:Class;
 
          [Embed(source="/assets/skins/LoginButtonDisabled.png")]
          private var DisabledGraphic:Class;         
 
          public function LoginButton()
          {
               super();
          }
 
          override protected function initializeStates():void
          {
 
               // Up State
               upSkin = new UpGraphic();
               setSkinState(SkinStates.UP,upSkin);
 
               // Down State
               downSkin = new DownGraphic();
               setSkinState(SkinStates.DOWN,downSkin);
 
               // Selected State
               selectedSkin = new DownGraphic();
               setSkinState(SkinStates.SELECTED,selectedSkin);
 
               // Disabled Skin
               disabledSkin = new DisabledGraphic();
               setSkinState(SkinStates.DISABLED,disabledSkin);
 
               showSkin(upSkin);
          }         
     }
}

So hopefully that gets you started on skinning. As I get to more complicated components I’ll blog about skinning those as well, but the basic premise seems the same across most of the components.

Slides and Demos from FITC San Francisco

Posted on by
2

FITC was an absolutely awesome event. Props to Shawn, Rick and team for another great event. I’m looking forward to them coming back to San Francisco next year. Thanks to everyone who attended my talk. I got some great questions and as I said in the sessions, if you have anything cool you’re doing with mapping and Flash, drop me an email.

Below are the slides I used and I’ve also posted all of the code for the demos I did. I haven’t really cleaned them up at all, but if you have any questions, let me know.

Mapping and Geolocation on the Flash Platform
View more presentations from Ryan Stewart.

Flash Builder for Dreamweaver CS5 Users

Posted on by
Reply

Thanks to everyone who stuck out the preso on Flash Builder for Dreamweaver CS5 users. Clearly this isn’t my month for demos. I’ve uploaded the slides as well as the (working) source code. There are two directories: the Flex directory, which includes the source code for the Flex projects, and the html directory, which includes the HTML code.

Flash builder for dreamweaver cs5 developers
View more presentations from ryanstewart.

It’s got examples for using ExternalInterface, the Flex/AJAX Bridge, and FlashVars. You can grab it here.

Using Flash Builder 4 with your Flex 3 Projects

Posted on by
1

Flash Builder 4 has been out in public beta for a while and it’s been fun to see it progress. One of the things I noticed about the early betas was how some of the basic features like refactoring and event handler generation made a huge difference in my productivity regardless of whether I was using Flex 3 or Flex 4.

Now that Flash Builder 4 is out, it’s even more polished and you still get some of those benefits in your Flex 3 projects. If you’re currently in the middle of a Flex 3 application or you’re planning on targeting Flex 3 for a while, you can still get a lot out of Flash Builder 4. Andrew Shorten has a good rundown of how you can use Flash Builder 4 with Flex 3 projects. It’ll save you a lot of time and make your Flex experience that much better.

Flash Builder 4 and Flex 4 Released

Posted on by
5

It feels like a long road, but today we’re releasing the final versions of Flash Builder 4 and the Flex 4 SDK. If you were one of the attendees at Flash Camp Boston, you got the final versions on the DVD (but we had to call it a release candidate) so there’s no need to update. For the rest of you, make sure to grab the latest and greatest right now. If you’ve installed previous betas/prerelease versions, you will need to uninstall those before you install the new versions.

I’ve been a Flex developer for a long time, since version 1.5, and I genuinely think this is the most significant release in the history of Flex. We made some huge architectural changes in this version of the SDK. The new skinning model, which separates the logic of a component from the look and feel, is going to let you create some very complex and unique user interfaces. An improved states model along with a much more efficient transitions/effects engine mean that it will be easier to create multi-screen applications with meaningful rich transitions. And arguably the most important thing we did was optimize. The compiler is much faster, which means you’ll be spending less time compiling and more time building.

But the biggest thing about this release in my mind is Flash Builder. This tool has come such a long way and Flash Builder 4 is a home run. The added productivity enhancements like ASDoc support and event handler generation make it so much nicer to program. Throw in things like better refactoring and built-in unit testing and you’ve got a very powerful IDE on your hands. I’ve been using it for a while now, but when I step back and look at it, I’m very happy with what the team accomplished. Hopefully you also enjoy the new network monitor and the DCD features, which make it easy to connect to data and start building RIAs. And with the new leadership in place, the future of Flash Builder is only going to get better.

I’ve got a bunch of articles up on the Developer Center for using Flash Builder 4 with PHP. If you’re a PHP developer interested in testing the new features, these should get you pointed in the right direction. We’ve also got recordings up of all the talks at Flash Camp Boston, which cover a variety of Flex 4 and Flash Builder 4 features as well as some thoughts straight from developers who are going to be using Flex 4 and Flash Builder 4.

Congrats to the teams who made this happen. I hope you all enjoy the hard work that went into the release.

Flex Saving Flash

Posted on by
3

Interesting writeup over on PHPArchitect.

That is the most important thing that Flex brings to Flash: professional grade tooling. The Flex framework, which Adobe has open sourced, makes application development quick and painless for programmers familiar with event driven programming.

One of the things that fascinates me about the Flash Platform is the number of different types of web professionals it attracts. Those web professionals have very different goals so we largely try to stay out of the way and let them create what they want. But to make them productive we create tools and sell them. But trying to have one tool that does everything isn’t practical. Flex was always intended to be a developer-centric way to create Flash applications and I think Flash Builder 4 is going to show that off better than the previous versions.