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.

View full post on Digital Backcountry – Ryan Stewart’s Flash Platform Blog

One of the first decisions you’ll have to make when you start building a PlayBook application is whether you want to use the Flex Framework for mobile devices or the QNX component set that ships as part of the AIR SDK for PlayBook. Even if you’re a Flex developer it’s not a straightforward decision so it’s important to be able to weigh the pros and cons of each side. I’ve been talking to a number of developers about Flex versus QNX and wanted to put down my thoughts to help developers decide. If you think I missed something, let me know in the comments and I’ll add it.

Performance

I don’t yet have a PlayBook to test the differences on, but in talking to people that do, performance generally seems like a wash. There’s something to be said for the fact that the QNX team is working really closely with the hardware to optimize their component set, but I also know the Flex team has made leaps and bounds in performance for Flex Mobile. When I get an actual device I’ll update this section.

Component Set

This is an area where I thought Flex would have a decided advantage. And if you count the entire component set, it does. But if you limit the comparison to mobile-optimized components, Flex ends up a little behind. For both platforms the core components are there, lists, buttons, etc. Flex has a TextArea component while QNX doesn’t, but QNX has a slider component while Flex’s hasn’t been mobile-optimized yet. Where QNX ends up winning though is in the number of components that are being built to support UI features of the PlayBook. QNX has support for a number of different dialog components including the LoginDialog component as well as built in support for lists with sections. If you’re sticking to the normal base components, Flex is a perfect fit, but the QNX components are a bit higher level and provide some specific UI elements that your users will see across the PlayBook that you can then add to your own application.

The Picker component from the PlayBook AIR SDK

The Picker component selected

Layout

Flex wins this hands down in my opinion. The layout system that the QNX components employ works just fine, and it’s elegantly simple. It uses a container system and I’ve been told it’s similar to Java. I did a screencast on how to use it and it generally accomplishes most of what you’ll need to do. But if you want to do anything above and beyond, the Flex layout system still rules. Having to use things like a Spacer container to align a component in the middle of the screen just seems hacky compared to being able to set properties on a Group. Plus, with Flex you can very easily create your own layouts, which means you can create far more customized looking applications with Flex than with the QNX components.

Skinning/Designer-Developer Workflow

Currently I see this one as a draw. The Spark components of Flex offer a lot of customization and on the desktop provide some great integration with tools like Flash Catalyst, Illustrator, and Photoshop. The only problem is that you don’t really get those integrations if you’re building mobile Flex applications because for most components you won’t want to use MXML-based skins, you’ll want to use AS3 skins. Because all of the designer-developer tooling uses MXML, you won’t be able to pull out all of the benefits of Spark on mobile devices. On the other hand, the QNX components don’t really have any designer developer workflow either. I found the skinning model for QNX to be similar in a lot of ways to the skinning model of Spark. Either way, when you skin these applications you’ll be doing a lot of ActionScript and relying a lot on images.

Mobile UI Paradigms

The TabNavigator UI Paradigm

The Flex mobile team has done a fantastic job of building the framework from the ground up with mobile user interface paradigms in mind. A base Flex Mobile application gives you an ActionBar, which can contain global content, an easy way to add and remove pages from within the application (complete with default transitions between screens), and components for tabbed navigation. With QNX you’re going to be creating most of those from scratch. On one hand it means that you can build up your own mobile UI paradigms if for some reason you don’t want to use what Flex has to offer. On the other hand, the paradigms that Flex Mobile uses are ubiquitous at this point and I’ve found myself trying to copy them in my PlayBook applications.

Flex Mobile’s ActionBar Component

Native

This is one of those intangible things but I think it’s important to look at critically. Alex Payne noted some of the issues with AIR applications and how they compare to native applications (also read Ed Finkler’s post on the subject). One of the things I find most exciting about the PlayBook is that it’s the only platform where Flash is native. The QNX components that you use in the SDK are the exact same ones that are being used across the device. It’s very exciting to be able to build native UIs with my Flash/Flex skills. I’m obviously a big fan of Flex and AIR for a lot of things, but given the chance to build native apps, I’ll do it. And it couldn’t be easier for Flash developers to use the QNX components to create native PlayBook apps. That being said, the native APIs and device functionality are all exposed via ActionScript APIs so even if you’re building a Flex app you can still take advantage of the same native and device-specific functionality that developers who use QNX can. So it just comes down to how you want your application to feel compared to other applications on the device.

Another important consideration is being able to reuse your code to deploy to other devices. If you’re looking for a consistent brand across multiple devices and the ability to reuse big chunks of code, Flex is the only answer. You won’t be able to use the QNX components outside of the PlayBook environment so you’ll have to rewrite the application for iOS or for Android or for any of the other devices AIR supports.

Conclusion

I don’t really see a winner for either one of these because I think it comes down to developer skills and what kind of experience you’re going for. I’ve really enjoyed diving into the native QNX components because I like when applications have a native look and feel. If you’re primarily a Flex developer you’re probably going to miss some of the things that you’ll lose by moving to the QNX components. And someone may come up with a Flex skin that mirrors the look and feel of the QNX components so you can get the best of both worlds. Either way building applications for the PlayBook will be right up the alley of any Flash developer. It’s a device that has basically been built from the ground up to support Flash and I’ve been enjoying it immensely. I’m hoping to have a Pintley application out for the PlayBook at launch so if you’re a beer lover, check back here.

One good place to start hashing out the differences is to take a look at the developer documentation for each: Flex, QNX. That will give you a feel for some of what’s supported in each one. And again, I’ll be updating this post with comments so feel free to comment below or to drop me an email.

View full post on Digital Backcountry – Ryan Stewart’s Flash Platform Blog

This is a fairly straightforward topic but I did a quick DZone article on charting with Flex and PHP using the data-centric design wizards in Flash Builder. The wizards make it very easy to at least get the basics down and start using data in charts, and I covered some basic ways to add animations and interactivity.

I’m working on a more in-depth article with Zend that will cover grouping/sorting/etc on both the client and server side. It will provide some info on how to structure your data and make it more flexible for manipulating when it’s in the chart.

View full post on Digital Backcountry – Ryan Stewart’s Flash Platform Blog

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.

View full post on Digital Backcountry – Ryan Stewart’s Flash Platform Blog

My blog has been pretty dusty the past couple of weeks even though there is a lot going on in the Adobe world. Normally I try to stay away from the purely personal stuff so I humbly beg your forgiveness for this detour into Ryan’s life. I’ve been very preoccupied for the past week because on March 27th, my wife and I welcomed our daughter into the world. It’s our first and we’re having a blast getting to know her. I’m on paternity leave for another week so while I’m keeping up on what’s happening with Apple’s tablet, Flash Player 10.1, and Adobe AIR on devices, I can honestly say (maybe for the first time ever) that it’s not occupying much of my time.

I’ll indulge one small parental moment and share a couple of pictures of our daughter, Juniper Olivia Stewart. And I’ll be back to blogging next week. But probably a bit more sleep deprived and (even) less coherent than usual.

View full post on Digital Backcountry – Ryan Stewart’s Flash Platform Blog

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.

View full post on Digital Backcountry – Ryan Stewart’s Flash Platform Blog

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 an 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.

View full post on Digital Backcountry – Ryan Stewart’s Flash Platform Blog