One of the nice features of the Flex mx:List component is that you can set the renderers to be editable without having to create a new itemrenderer. With the Spark List (s:List) that option is no longer available. Fortunately it is quite easy to create a custom editable itemrenderer for the List.
Select an item in the left column and change the value, you can see the change events being traced out. Right click to view the source code.
There are three steps making an editable itemrenderer for the Spark List component.
Create a custom itemrenderer with a TextInput and a Label.
<?xml version="1.0" encoding="utf-8"?>
<s:ItemRenderer xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx"
autoDrawBackground="true">
<s:Label id="labelDisplay"
text="{data.label}"
top="7" bottom="5" left="5" right="3"/>
<s:TextInput id="inputTxt"
visible="false"
top="1" bottom="1" left="1" right="0"/>
</s:ItemRenderer>
In order to toggle between the read and write states we need to add a click handler to the label and focusOut handler to the text input. You will notice that I simply set the respecitive components to either visible or not instead of uses the spark states. Using the spark states would require extending the list component to include an editHover state and for this example I wanted to keep things simple.
<fx:Script>
<![CDATA[
import spark.components.supportClasses.ListBase;
private function onChange(event:Event):void
{
isEdit(false);
}
private function onEdit(event:Event):void
{
inputTxt.text = data.label;
isEdit(true);
//set cursor postion to end
inputTxt.selectRange(inputTxt.text.length,inputTxt.text.length+1);
inputTxt.setFocus();
}
private function isEdit(value:Boolean):void
{
labelDisplay.visible = !value;
inputTxt.visible = value;
}
]]>
</fx:Script>
<s:Label id="labelDisplay"
text="{data.label}"
click="onEdit(event)"
top="7" bottom="5" left="5" right="3"/>
<s:TextInput id="inputTxt"
visible="false"
focusOut="onChange(event)"
top="1" bottom="1" left="1" right="0"/>
This is the not so obvious step. You need to manually dispatch an event through the List's dataProvider in order to notify the List and anything else that is using the data source that it's contents have changed.
private function onChange(event:Event):void
{
var oldValue:String = labelDisplay.text;
if (oldValue != inputTxt.text)
{
data.label = inputTxt.text;
labelDisplay.text = inputTxt.text;
//dispatch the data update event
var list:ListBase = this.owner as ListBase;
list.dataProvider.itemUpdated(data, 'label', oldValue, inputTxt.text);
}
isEdit(false);
}
And that's it. A basic editable list itemrenderer for the Spark List in 3 easy steps. Right click on the swf to see the source code.
Since Apple kiboshed Adobe's hopes of iPhones running Flash content, Android (Google) has stepped up and offered Flash and Flex developers a mobile platform to development and deliver content on. This has come as great news to Flash platform developers who want the opportunity to dive into the mobile environment. Many Flash (and Flex) developers I have spoken to about mobile development are still unsure about what it will take to deliver Flash player based content and applications to mobile devices.
The good news is the development and delivery process is almost identical to the current process. Use Flash or Flash Builder to create a swf file and then either deploy that to a website, to be served up via an HTML page or wrap it with the AIR runtime and packge it for installation on an Android phone as an native Android installer. Really the only difference in developing for the Android platform is the extra step required to create an '.apk' file if you want to create a stand alone application.
The bad news is the environment that the content and applications are running in is quite different from anything the vast majority of Flash platform developers have worked in. The screen is small, the bulk of user interactions are touch based, the screen can easily be rotated and tilted, the user is often quickly looking at the screen while interacting with the environment around them (ie texting and walking at the same time) and the processor doesn't have the juice most modern desktops and laptops have. This means that while the swf delivery and development process is quite familar the UI and UX development is anything but. Add in the processing constraints and most Flash platform developers will quickly realize there is a significant learning curve to developing Flash and Flex content for Android (and mobile in general) devices.
Below are two screen shots of the same Flash application running on a Google Nexus One and a normal desktop computer. The application is 480 x 800. The first image shows the screen as seen on a normal desktop computer with the screen resolution set at 1280 x 1024 (fairly standard desktop resolution). The second image shows the same screen scaled to the physical size as seen on the Nexus screen. It might seem obvious that the mobile screen will be smaller than the desktop screen but watch how screen resolution affects something that is the "same" size.
As you can see there is a huge difference in the physical size of the two screens even though the application is viewed at 480 x 800 pixels on both devices. Mobile devices have much higher screen resolutions than normal computers, 240dpi vs 72dpi. As you can see from the images above this makes a huge difference.
For mobile applications this has two very big implications.
First a smaller screen with a much higher resolution means you have much less physical real estate to work with when laying out the user interface. Designers need to be acutely aware of this when creating screens and views. Add in the fact the users are often quickly glancing at the screen which means screens can not afford any clutter and designers have a difficult task in packing a lot of meaningful content into a very small area.
Second, since everything appears much smaller on mobile screens things like text and UI controls (button, checkboxes, etc) need to made larger for readability and clickability (if a beer company can use drinkability I can use clickability). On a mobile device the main pointer is the finger tip which is a lot larger and less precise than a mouse pointer. In a desktop application the typical button size is around 25 pixels in height, on a mobile device 60 pixels is the norm, anything smaller than that and it becomes very challenging to click the button you want.
I couldn't help but be reminded of this Simpson's clip after my first experiments building a Flash application for the Android.
This leads to my second point.
Apple and the iPhone ushered in a whole new era of computer interaction. Sure 'touch' has been around for a long time, but it was Apple who made it mainstream. Point and click are things of the past, now it's point, flip, swipe, pinch, wipe. Sounds more like a heated game of rock-paper-scissors. The great news for Flash platform developers is that AS3 has full gesture support built in and ready to be used. Events are dispatched for a multitude of user gestures including tapping, swiping and rotating. AS3 also supports multi touch for instances where multiple touch points need to be tracked.
This is a whole new territory for Flash and Flex developers, we generally just interact with the mouse and keyboard, a few of us (myself included) have developed for larger touch screens, but not small mobile screens. Fortunately there is some good information to be found on designing for human interaction. Google has provided some guidelines for user interface design and Apple has some really good (and thorough) documentation on Human Interface design.
This is an area that will make or break an application. It won't matter how great the apps processes information or what information it displays or what it allows users to do, if the control is non-intutive and confusing users will drop it faster than a hot potato (and they may just throw their phone).
Most mobile devices have as many sensors and media inputs as swiss army knives have blades. There are GPS sensors, accelerometers, touch screens, cameras, microphones, video cameras, scroll balls, the list goes on. The trick for developers is figuring out how to leverage the various sensor inputs (and outputs) to create unique and pleasant user experiences.
For the Flash and Flex developer most (if not all) of these sensors will be available to AIR based applications and most of them will be available to browser based swfs. This an area where Flash applications will really be able to shine. Flash has supported camera and video input for a long time, working with these types of media inputs should be second nature to many Flash platform developers. Some of the other sensor inputs are new (ie accelerometer, microphone and gps) but Flash has the advantage of being able to access and use them, sorry HTML5 and javascript.
Personally I think Flash is uniquely positioned to offer mobile users amazing experiences based on the capabilities of the devices. Flash has been used for years to create amazing, immersive, media rich user experiences. With increased ways to receive and provide feedback between the user and device who knows what applications will start to look like and how they will function.
Performance, performance, performance. This is "allegedly" why Apple doesn't offer Flash on the iPhone/iPad. I don't buy it. I have seen Flash running on Android devices first hand, both in the browser and as stand alone applications and trust me it runs perfectly. Adobe has worked very closely with mobile manufacturers to provide hardware acceleration, reduce battery usage and deliver maximum performance with the upcoming Flash 10.1 release.
The critical issue for developers is to remember they are developing for devices that don't have the same processing resources of typical desktop and laptop computers. Special attention needs to be paid to optimizing performance as much as possible. Grant Skinner has a great presentation on Flash performance, where gains can be found and where trouble lurks. Garbage collection, green threading, blitting and generics are all areas that AS3 developers should understand in order to optimize and maximize the performance Flash can deliver.
The old computer mantra is "garbage in ...garbage out". If your application runs slow, freezes or crashes, don't blame the device, virtual machine, Adobe, Google, Android or your mother, first look at your code. This is where the majority of backlash against Flash performance should really be pointed. It's not the Flash plugin and runtime, it's the fact that anyone can "develop" a Flash application and many people that do, don't understand the performance and memory implications of what they are doing. With the ability to release Flash applications and content to mobile devices, Flash will be under increased scrutiny, do the community a favor and write clean, efficient code.
Who knows? The mobile environment is like the internet was 10-15 years ago, the wild wild west. A lot of really cool things will get made and a lot of dogs will come and go. The only thing I am sure of is that the Flash platform will have a large place in how applications and content get developed, deployed and used. It's an exciting time for Flash platform developers, especially after all the HTML5/Apple rhetoric. Get a mobile device, get some neat ideas or find someone who has them and build something amazing, I know I will be.
There has been a ton of hype, speculation and news recently regarding Flash's impending demise. I won't go into the details because it's been hashed over repeatedly and I really don't feel like beating a dead horse.
As a Flash and Flex developer I have a huge vested interest in where the Flash platform goes and whether or not it survives. I stumbled across this video interview with Jesse Freeman (aka the Flash Bum) where he talks about his take on Flash's future (skip to 10:20).
Personally I think Jesse is mostly correct. Mobile is critical to Flash's future success and it must keep evolving.
The world is moving to a constantly connected, mobile environment where devices quite different from the traditional desktop/laptop will rule. As someone who has been involved with early development using Flash and Flex technology on mobile devices I can say Adobe has done a good job with their recent push to get Flash running on devices (1000% better than anything Flashlite was), but there is still a lot of work to do. I'm excited and encouraged by the work they have done with industry leaders in the mobile arena via the Open Screen Project and I honestly believe Flash will be a large player in mobile development for the same reason it currently is in the desktop/laptop environment, they give developers a consistent platform to deliver applications and content with across devices, something no other company or open source initiative offers.
For Flash to succeed Adobe needs to keep the platform evolving. I have worked with Flash (and Actionscript) since Flash 4 was around, over ten years ago. Today's Flash is lightyears ahead of anything it was ten years ago. It has evolved from a simple animation program to something you can create complex websites and internet applications with. Actionscript is now on it's third major revision and approaches more traditional languages like C and Java in terms of usefulness and potential. As a developer (in any language) if you sit down and objectively consider what is possible to run in almost any browser today through the Flash plugin it is almost mind blowing the functionality and performance that can be delivered. Things that were only possible a few short years ago in full blown, heavy client applications that needed to be installed on a computer can now be delivered rapidly through the browser, anytime, anywhere.
Jesse seemed a little pessimistic about Adobe's ability to keep Flash/Actionscript from becoming stagnant and going the way of the Doodoo bird. I'm more optomistic, having seen where Flash, and more importantly Actionscript, was, where it is, and where it's heading. I think if anything, Adobe will put more focus on Flash and continue to rapidly push it ahead of competing technologies like Silverlight and to a lesser extend HTML5. Actionscript, as it becomes more rounded and powerful, will become more mainstream and entrenched, much like Java has from it's early days.
In closing, I could list out many of the things you can do with Flash/Flex/Actionscript but the video below does a nice succinct job and paints a better picture than anything I could say.
Derrick Grigg is a Rich Internet Application (RIA) freelance contractor based in Toronto, Canada. He specializes in architecting and developing applications using a variety of technologies, most notably Flash, Flex and Coldfusion.
