Tag Archives: Adobe

Open Source Media Framework Marketplace

Posted on by
4

If you’re doing anything with video you’ve probably heard of the Open Source Media Framework (OSMF). It’s one of the cooler projects at Adobe and provides a component that can be customized and extended for whatever you want from video delivery.

OSMF includes a robust plug-in architecture that lets developers extend it and add features. The OSMF team has put together a marketplace for tutorials, white papers, and plug-ins for OSMF. It looks like it’s a great resource for all things OSMF and a bunch of the Flash media rockstars have already contributed content. The guys at Realeyes Media have put up an example plugin that lets you track analytics when using OSMF. Almer/Blank has a reference card that covers the important parts of OSMF. And Jodie O’Rourke has a getting started article for an introductory look at OSMF.

I think it’s a cool way to expose a bunch of developer-related content. If you’re knowledgeable about OSMF, definitely think about contributing some content. And if you’re just wanting to show video, take a look at some of the plug-ins and documents that make it easy. And everyone should check out the StageVideo Plugin for using StageVideo with OSMF.

PlayBook Development: Flex Mobile Framework or the QNX Components?

Posted on by
4

Flex or QNX

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.

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.

Setting Custom Labels on Lists with the PlayBook

Posted on by
2

By default, it seems like the only property that the QNX List class can display as a label is label. In Flex I was used to being able to set my own label property or my own custom label function but it doesn’t look like that’s possible in the QNX List. Luckily, it’s not TOO hard to set up a class to do just that.

First step is to create a class that extends CellRenderer. There’s a lot that seems to go on in CellRenderer but I’m just starting to dig into it so I’ll save that for a later post. The easiest method I found was to override the setter for data and then use the setLabel function there. You can pass in whatever string you want to that setLabel function and it will display as the default label with the default font.

One of the issues I’m having is trying to figure out exactly when the data gets set on the CellRenderer component. Some of the other things I tried (setting it in the constructor, setting it on the drawLabel method) all didn’t work because the data object was still null. So I’m trying to figure out exactly when data becomes available. Hopefully I’ll have that for a followup post that goes into more detail on creating custom renderers for the list class.

Here’s the code I used for my example:

package com.pintley.components.listClasses
{
import qnx.ui.core.SizeUnit;
import qnx.ui.listClasses.CellRenderer;
import qnx.ui.text.Label;
 
public class BeerItemRenderer extends CellRenderer
{
     private var _beer:Object;
 
     public function BeerItemRenderer()
     {
          super();
     }
 
     override public function set data(value:Object):void
     {
          _beer = value;
          setLabel(_beer.beerName);
     }
}
}

Motodev Podcast on December 16th

Posted on by
Reply

motodev_podcastOn December 16th, I’ll be participating in a podcast with Randy Ksar from Motodev to talk about Android, Motorola, and the year in review along with some Adobe AIR talk. It’s going to be done live so you can tune into the stream (and RSVP here). With the Motorola Tablet being in the news lately it seems like a very fun time to recap everything in anticipation for next year.

Getting Started with the BlackBerry PlayBook and Adobe AIR

Posted on by
11

As I’ve mentioned, I’m excited about the fact that RIM has wholeheartedly embraced AIR for their PlayBook. That means if you’re a Flash or Flex developer you’re going to be able to easily target this device along with all of the other phones and tablets that support AIR.

And there is no reason you can’t get started right away. RIM just released a new version of the AIR SDK that you can use along with their simulator to get stared building apps. I did a quick tutorial embedded below that shows the steps needed to get going. It’s pretty easy to get a jump and the emulator gives you a feel for how your application will behave on the device.

I’ll be talking a lot more about development on the PlayBook over the next couple of months and I’ve got a few projects that will be specifically targeting the 7″ form factor so I’ll be talking about those and showing some best practices.

What Happens When Your Users Install an AIR For Android Application Without AIR

Posted on by
12

I’ve gotten this question a couple of times so figured it might be worth a blog post (because I wasn’t sure until I tested it). Now that the AIR runtime is on the Market, there are going to be apps that need it. If you’re one of those application developers who creates one, what’s the user experience for someone who hasn’t yet installed AIR for Android? It’s actually pretty nice.

The application will install just fine without any issues. When the user tries to run that application, they’ll be presented with this screen:

After that, they can click the install link and it will take them to Adobe AIR in the Android Market where they can download and install it. After that, the application will work just fine.

The Camera API and Geolocation Exif Data on AIR for Android

Posted on by
4

As part of my MAX session, I’ve been playing around with the camera API and wanted to pull some of the Exif data around geolocation. My first thought was that I could use the geolocation APIs in AIR to inject Exif data into the image from the camera. But the way that the AIR for Android Camera API works (which makes sense) is that when you take a picture, it creates a MediaPromise, which is a new class in AIR for Android that is similar to a FilePromise. That code includes a bunch of Exif data that Android adds. The only issue with the GPS coordinates are that they’re in sexagesimal format and need to be converted into decimal.

There are actually two ways to get images into your AIR application. The first is using the flash.media.CameraUI class. That brings up the camera controls and lets the user take a picture directly. When the user clicks “OK” on the camera, it saves the file to the SD card and then passes the file reference back to AIR where you can program an event handler to respond:

public var cameraUI:CameraUI;
 
protected function onCreationComplete():void
{
 
if(CameraUI.isSupported)
{
cameraUI = new CameraUI();
cameraUI.addEventListener(MediaEvent.COMPLETE,onComplete);
}
 
}

Then all that has to be done is to call the launch() method and that pops up the camera controls. When the user confirms the photo, the MediaEvent.COMPLETE handler deals with the photo. Or in this case, the file reference.

protected function btn_clickHandler(event:MouseEvent):void
{
cameraUI.launch(MediaType.IMAGE);
}

The other way to get access to photos is to pull them from the phone’s memory. You can do that with the flash.media.CameraRoll API. It’s a very similar process to the CameraUI. Instead of a complete event, listen for a select event, and to bring up the library of images, call the browseForImage() method.

public var cameraRoll:CameraRoll;
 
protected function onCreationComplete():void
{
if(CameraRoll.supportsBrowseForImage)
{
cameraRoll = new CameraRoll();
cameraRoll.addEventListener(MediaEvent.SELECT,onSelect);
}
}
 
protected function btn_clickHandler(event:MouseEvent):void
{
cameraRoll.browseForImage();
}

Now once the image has been taken or selected, we can pull the Exif data from it. Both the complete event and the select event will look the same because they both create a MediaPromise. I’m using the Exif library here, which uses the load() method and an event handler to deal with the Exif data when it loads.

protected function onSelect(event:MediaEvent):void
{
var request:URLRequest = new URLRequest(event.data.file.url);
var exif:ExifLoader = new ExifLoader();
exif.addEventListener(Event.COMPLETE,onExifComplete);
exif.load(request);
}

The parsing of the Exif data is pretty straightforward. Once it has been parsed, pulling out the specific tags by name for Latitude and Longitude, all that is left is to convert the sexagesimal latitude and longitude to decimal degrees.

protected function onExifComplete(event:Event):void
{
var exif:ExifInfo = event.currentTarget.exif as ExifInfo;
var gpsIfd:IFD = exif.ifds.gps;
 
// get the array of GPS coordinates from the Exif data
var exifLat:Array = gpsIfd["GPSLatitude"] as Array;
var exifLon:Array = gpsIfd["GPSLongitude"] as Array;
 
// get the decimal degrees for latitude/longitude
var latitude:Number = convertSexagesimalToDecimal(exifLat[0],exifLat[1],exifLat[2],gpsIfd["GPSLatitudeRef"]);
var longitude:Number = convertSexagesimalToDecimal(exifLon[0],exifLon[1],exifLon[2],gpsIfd["GPSLongitudeRef"]);
}
 
protected function convertSexagesimalToDecimal(degrees:int,minutes:int,seconds:Number,reference:String):Number
{
// do the conversion to decimal degrees
var decimal:Number = degrees + (minutes/60) + (seconds / 3600);
 
// figure out whether we need to use negative latitude or longitude
if(reference == "S" || reference == "E")
{
return decimal * -1;
} else {
return decimal;
}
}

So that’s a crash course in using the camera API on AIR for Android and then extracting decimal degrees out of Android’s existing Exif data.

RIM’s PlayBook and Adobe AIR

Posted on by
4

Yesterday RIM announced their tablet computer, the PlayBook, with an impressive set of specs and what looks like a great form factor. But what I thought was the coolest part of the announcement is that Adobe AIR is going to play a central role in application development on the tablet. While there will be support for Java eventually and developers can use C++ to tie into things like OpenGL, Adobe AIR is the primary way to develop applications for the tablet.

In fact, a lot of the work on the tablet is already being done in AIR. The browser, the application launcher, and a lot of the default applications have been built using Adobe AIR. One of the cool things is that this is just one step in a long evolution of Flash. The company behind the tablet OS, QNX, was acquired by RIM back in April. QNX has long been a partner of Adobe and is one of the experts on porting Flash to different pieces of hardware. So they’ve got a ton of experience working in the guts of Flash and it sounds like a lot of that knowledge went into the AIR integration on the PlayBook.

So if you’re building AIR applications then this is one more place you’ll be able to bring those skills. You can get a jump on development by heading over to the labs page we have set up for the BlackBerry and of course, there will be a lot more good stuff at MAX, so you’ll want keep an eye on news coming out of LA for the latest.

Flash Player “Square” With IE9, Native 64-bit Support

Posted on by
3

Flash Player SquareToday you can go download the beta of IE9 and from what I’ve seen it looks like it’s pretty damn impressive. We also released a version of Flash Player, codenamed “Square” which not only has support for IE9, but includes a bunch of code collaboration that we did with Microsoft to create a really streamlined experience. The Flash Player Team Blog has a bunch of info:

As part of our collaboration with Microsoft’s Internet Explorer team over the past few months, Flash Player “Square” has been enhanced to directly support the hardware-accelerated graphics capabilities in the newest version of IE. Flash Player “Square” leverages the new GPU support available with Internet Explorer 9 Beta to deliver a faster and more responsive user experience with Flash-based content. In our internal testing, we’ve seen significant improvements in Flash Player graphics performance – exceeding 35% in Internet Explorer 9 Beta compared to Flash Player running in previous versions of IE. While the performance improvements will vary based on the type of content and how it’s created, bitmap-heavy content for Flash Player will experience the greatest benefit. Flash-enabled content that’s embedded as transparent (wmode=”transparent”) will also run more efficiently given the benefits of offloading the HTML and Flash content compositing to the GPU. Try it out by downloading the Internet Explorer 9 Beta and the Flash Player “Square” preview. We’d appreciate your feedback and observations on performance.

So right off the bat with IE9 you get hardware support for Flash. We’ve also (finally) got native 64-bit binaries for Mac, Linux, and Windows. It’s been a long time coming, but we hope you get a chance to test these versions out and give us feedback.

We’re only a couple of months from MAX, and this gives you a taste of some of the things we’ve been working on. Between the work on HTML5 with Dreamweaver and Illustrator and the work the Flash Platform teams have been doing, it’s going to be an incredible year for RIAs and for Adobe designers/developers.