We Love Choice

Adobe has launched a campaign to share some facts about what the flash player can do and how it will allow developers to build apps without limits.

I can't help but think this has something to do with Apple, but they are putting it out there as a way to inform people about the player.

Adobe and Apple

In addition to being my two favorite technology companies they are also in quite the feud. It has been hard to watch two companies that I have so much respect for have such a hard time coming to terms. The because the iPod, iPhone, and iPad do not support the Flash Player and will not be allowed Steve Jobs posted his "Thoughts on Flash" to clarify his position. Jobs stated reasons including performance, multi touch support, and feature adoption as to why Flash would not be included. I don't think it is Apple choice to say that a developer can't use a tool or not. If Flash has some limits and developers want to use it anyway, we should be able to.

One point I am surprised I have not heard is that Apple is restricting Flash to grow the Objective-C community. The number of Objective-C developers that know how to write Mac apps has always been small, but since the iPhone those numbers have been growing rapidly. If developers that know Flash can port their exiting apps to the iPhone they would not need to learn Objective-C. To me that is the real reason Apple has been holding up a front against Flash. They want a large community of developers that know how to write Objective-C apps because those developers will also know how to write apps for OS X. Job says, "we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform...". 

Kevin Lynch states in his rebuttal to Job's blog that Adobe is no longer going to work toward Flash support on the iPhone, iPod, or iPad and in turn is going to focus on the Android and other mobile devices.

Flex Databinding

If you have done Flex development you are probably no stranger to databinding. Data binding will update a property any time the bound property is modified. What it is updated with is another story. I will list various ways to use databinding beyond just mapping one value to a property.

One variable:
The variable can exist in the MXML or a class it inherits.
text="{total}"

Or it can be inside an object. If so Flex will detect changes to the value and assignments to any of the objects in the binding.
text="{model.total}"
text="{model.products.total}"

A variable and text:
The property is not limited to only a bound or non bound value. You can insert the binding into a constant.
text="Your total is: {total}"

Multipule variables and logic:
Slightly more advanced we can use more than one value in a binding. In the following example flex will fire the binding if either "a" or "b" is changed.
text="{a} + {b} = {a+b}"
visible="{a || b}"

Functions:
My favorite trick. If the logic is complicated, use data binding to call your function when the variables change. The function will be called any time the variables are changed and the result of that function will be applied to the property defined.
text="{getCustomMessage(itemCount,userName)}"

Day of Mobile

There is a Mobile conference in Chicago called Day of Mobile on March 6th.

Topics From the Day of Mobile Agenda:
Jay Freeman - Navigating through the politics of the mobile development community.
Robert Fuentes - History of mobile development
Dave Cutler - How businesses are looking at mobile development
J Schwan - 30 tips to get started with mobile development
Chris Grove - Strategies for developing multi-platform applications
Rhishi Bhatia - The next generation of SMS and its impact on advertising
Sean V./Vince R. - Connecting your apps to the cloud: mobile CMS
Mark Murphy - 30 business models to make money in mobile development. Focused on the Android Platform.
Cory Foy - Blackberry development 101
David Whatley - From hobby to business: making big money in the iPhone App Store
Jason Shah - Multimedia on the Android platform
Robert Martin - Dynamic Langauges are the future
Jeff Norri - Growing an iPhone application with an internal open source project.

Flash iPod apps

There is still no sign of Apple supporting flash in the iPhone / iPod touch web browser, but we can use it to build apps. Adobe has enabled Flash CS5 to export flash apps as native iPod apps. This means that you cant put an app out on a website, you will need to go though Apples method of distributing though there app store.

Check out some samples:
http://labs.adobe.com/technologies/flashcs5/appsfor_iphone/

I have noticed that there have been complaints about performance of the graphics. If you read comments about the apps in the apple store people say that the FPS are low, but I think those are things that Adobe and developers will work out.

This is a big win for Flash developers.

Flex Image Centering

I was trying to get an image that was scaled to be centered on the screen and realized that Flex has some issues doing this. Using horizontalCenter="0" verticalCenter="0" will not work because whether you set the width and height or the maxWidth and maxHeight the image will fill the whole space. So, it an image is taller than it is wide it will still be left aligned.

To fix this I came across guille’s blog and after reading the comment "Anyone got something cleaner" I gave it a shot.

Here is my fix.
I consider using the maxHeight and maxWidth to be the appropriate method and I assume that you would also like to stretch the image out to fill the box. If you set the maxWidth and maxHeight then you can use add the following as the compete listener ( complete="onImageComplete(event)" )

protected function onImageComplete( e:Event ):void
{
 var image:Image = e.target as Image;

 var ratio:Number = Math.min( image.maxWidth/image.contentWidth, image.maxHeight/image.contentHeight );
 image.width = ratio * image.contentWidth;
 image.height = ratio * image.contentHeight;
}

If you don't want the image to stretch out, then just add 1 as another argument into the min function. The ratio will never be greater than one and the image will never be made larger than it was.

protected function onImageComplete( e:Event ):void
{
 var image:Image = e.target as Image;

 var ratio:Number = Math.min( 1, image.maxWidth/image.contentWidth, image.maxHeight/image.contentHeight );
 image.width = ratio * image.contentWidth;
 image.height = ratio * image.contentHeight;
}

Working Example

Flex Code Behind 2

In my last post I talked about separating layout and code using a code behind method. There are some more tricks you can use, and some standards I follow to keep things consistent. To recap a little I refer to a code behind class as an ActionScript class that is extended by a MXML class.

MainForm

Because every flex application has to have one MXML class that extends Application, and not a class that inherits Application, it can't have a code behind. To get around this I create one MXML class with a code behind, call it MainForm, and put it in the Application. I use that MainForm.mxml to lay out the main components and it can have a MainFormClass.as code behind. The MainForm is the only thing in the Application.mxml and I never touch the Application.mxml again.

Example Application.mxml:

<?xml version="1.0" encoding="utf-8"?>

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"

 xmlns="view.*"

 layout="absolute">

 <MainForm height="100%" width="100%" />

</mx:Application>

Data bind everything

If you want to display a response in a label don't set the label's text property, instead create a bindable string in the code behind and bind the label's text to that. If later you want to switch to a Textarea you can just change the MXML and not the definition in the code behind.

Good Example (using binding):

mxml

<mx:Label text="{confirmation}" />

as

[Bindable] protected var confirmation:String;

...

confirmation = "Add to cart qty:"+qty;

Bad Example (not using binding:

mxml

<mx:Label id="confirmation" />

as

public var confirmation:Label;

...

confirmation.text = "Add to cart qty:"+qty;

Avoiding IDs in the code behind

Data binding everything helps, but in the event you want to get information from components you will need to use ids, but that doesn't mean you need them in the code behind class. In my last post I broke this rule to show that you can refer to components by id in a code behind class. In stead of grabbing the text from the component in the submit function, pass the text to the submit function from the MXML.

Good Example (no IDs in as file):

mxml

<mx:TextInput id="qty" enter="addToCart(qty.text)" width="33" />

as

protected function addToCart( qty:String ):void

{

 confirmation = "Add to cart qty:"+qty;

}

Bad Example (IDs in mxml and as file):

mxml

<mx:TextInput id="qty" enter="addToCart()" width="33" />

as

public var qty:TextInput;

...

protected function addToCart():void

{

 confirmation = "Add to cart qty:"+qty.text;

}