It’s been 2 years since I wrote a native iPhone app and successfully launched it to the App store. I have been working with native Android off and on since July of 2010. Learning (really playing) with these respective platform technologies has been challenging and fun. In researching some new platform strategies for litl, I needed to start checking out some ‘write once’ technologies. I started looking at Corona and AIR especially. Ultimately, my familiarity and access to AIR led me to dive into reusing my Flash chops.. for now. The results, so far, have been staggeringly easy and exciting.

This demo app is pretty simple, using Touch events, some Flex Spark effects for animation and sound playback. The example is less than 100 lines of code. The devices you see are the iPad2 and the yet-to-be-released Samsung 10.1 Tab distributed at GoogleIO.

Overall, the performance on both devices is impressive. I’ve noticed a few more bugs on the Android side, mostly resulting in quirky touch handling and disappearing sprites. Also, the sound takes a little longer to load on the Android tablet. Aside from these issues, it’s been great showing these results to colleagues. I’m hoping to build out the demo app into an actual game. Also, I’d love to get my hands on some other devices (the Playbook and Nook Color) to test this process out more.

Here is an account of the steps I took to complete this experiment, along with approx times. Note the quickness getting this on my Android tablet vs the lengthy process of setting up my MBP to deploy to the iPad2:

Packaging apps for Android (from FlashBuilder):
http://www.adobe.com/devnet/air/articles/packaging-air-apps-android.html

Packaging apps for iOS (from FlashBuilder):
http://www.adobe.com/devnet/air/articles/packaging-air-apps-ios.html

The provisioning and certificate steps from Apple’s iOS dev center:
http://developer.apple.com/devcenter/ios/ [account required]

AS3 Touch Event handling:
http://help.adobe.com/en_US/as3/dev/WS1ca064e08d7aa93023c59dfc1257b16a3d6-7ffe.html

In this video, I review Adobe’s AIR for TV Developer Kit and discuss where it could have great potential for developers getting content and apps on TVs. Also demoed is a 3D Flash game Kevin Suttle and I originally created for litl’s accelerometer-driven set top box prototype. The ported version of the game relies on AIR for TV’s simplified d-pad control.

Watch the video on Vimeo.

Since CES, I’ve been following the TV App space very closely. I launched a new blog back in January called TheZSpace.com which allows me to cover the various TV developer platforms as they emerge. ["The Z Space" refers to the depth of interaction between the user and the TV.] Even with litl no longer launching the TV set top box, I’ve remained very interested in how Google TV and the major TV brands (Samsung, Panasonic, LG, etc) are building their own SDKs to attract developers and apps. As I mention in the video, AIR for TV may have excellent potential in this space as the individual TV brands represent a very fragmented opportunity to developers — much more so than mobile or tablets.

Also mentioned in the video is my agenda for presentations on the topic. I’ll be presenting at Rocky Mountain Adobe User Group tonight. Then, in June, I’ll be presenting at the exciting Flash And The City.

If this topic interests you and you’re excited about developer opportunities on TV, check out our blog at http://thezspace.com and follow us @thezspace.

At FlashAndTheCity, we officially launched our Developer Center at http://developer.litl.com. You can now sign up for the SDK, which is in private beta. To date, we’ve approved 75% of developer signups based on Flash experience, and more importantly, ideas for channels developers want to build. The latter is important to ensure we dedicate support early on to those developers most interested in building compelling channels for our users.

We have decided that while coding with the AIR-based Simulator included with the SDK package is sufficient, having a webbook to test and play with is much more fun. Upon signing up for the SDK, developers can get a litl webbook (plus FREE remote) for a subsidized/discounted price of $199.

Visit http://developer.litl.com to sign up, learn more, get your discounted webbook and start building fun channels for our users.

My HTC Intredible shipped with a Twitter app built-in called Peep. It was cool, but lacked some polish I enjoy with Seesmic’s Twhirl AIR app on my desktop. Being new to Android, I didn’t realize that features like taskbar notifications were available to other apps — so I was really impressed when I saw a little ‘birdie’ icon whenever someone replied/dm’d/or included me in their tweet.

Days after I got my Incredible, I learned that Twitter, themselves, had launched their own Android app. I downloaded and fell in love. Not only did it beat Peep in terms of usability, navigation and ‘Android’ integration, it also surpasses Twhirl. It’s got me wondering now, when will Twitter put out its own desktop-integrated app (not counting the web site) as an alternative to existing 3rd party apps. And if they do, what will the makers of Twhirl, Tweetdeck and many others have to say about it.

Turns out, Twitter is already fostering some bad blood among its own developer community. Up until now, I think developers integrating Twitter APIs felt they had the franchise on building 3rd party, OS/Desktop/Mobile integrated apps. To see the service company now build/acquire apps and offer them as their own is sending the wrong message to developers. It says, “we appreciate you doing what you did and helping grow our user base to millions. Now let us take it from here…”. This is a dangerous message for a service providing company with an abundant platform like Twitter to send.

Members of the developer community have been voicing their opinions starting around Twitter’s developer event “Chirp” (see
“Tensions Rise for Twitter and App Developers” and “Why is Twitter suddenly making its own apps?“) and you can see there’s something interesting brewing here. I’m interested to see how this pans out. While the ‘mashup’ scene has all but faded over the past few years, building apps around 3rd party APIs remains hot. Other companies who have no intention to compete with their developers, as Twitter seems to be doing, will need to make it super clear to avoid potentially negative comparison.

I started writing a lengthy comment in response to brother Kevin Suttle‘s very concise and well-written celebration post on the announcement of AIR for Android and Mobile. Please read that first here: http://kevinsuttle.com/2010/02/15/air-mobile-will-spark-the-era-of-contextual-applications/

In response to that post and many other announcements today, I have a lot of thoughts and questions I’d like to air out post. Before I get into this, I feel the need to state now that I love AIR. I’ve loved building AIR apps, coding with both CS4 and FlashBuilder. I am thrilled that Adobe is pushing this further into the mobile realm and hope the adoption skyrockets! I think it is the future of the Flash platform.

And now, some of my thoughts/questions and issues:

A. Aside from the use of a common language and platform in Flash, how can/will building AIR mobile apps be a unified advantage over building native apps on the device? As Ryan Stewart noted, “Depending on the device, you may want to make some small modifications, but you’ll be able to reuse your assets and a bulk of the code to quickly create cross-platform mobile applications with AIR mobile.” As we know some of the pave-over pitfalls of building AIR apps across Mac and Windows, there are some conditionals required to handle things like docking and alerts. My hope is that Adobe can continue to offer more seamless pave-over/common solutions that will let us tap into unique device platform features with a unified code approach.

B. It’s hard for me to envision how the same windowing, alert and docking functionality I’ve implemented in a desktop-based AIR app will appear/function on a mobile platform and smaller screen size. Assuming the mobile device/platform implementation of AIR supports this, will they work in a familiar way so the user knows how to handle them? Example: Twhirl. On Android, will the identical AIR app (if supported verbatim) actually load multiple windows for each of my Twitter accounts and lists? Will the app’s taskbar/docked icon (or mobile equivalent, if there is one) blink or bounce when I have a new tweet? Will a notification window popup over whatever app I’m using (or if/when I’m on a phone call) with new tweets? Hard stuff to imagine, but very exciting possibilities.

C. How will the AIR API proxy unique device functionalities like GPS, Accelerometer, orientation (landscape/portrait), touch/mult-touch, etc? Will we see separate classes for each, or something similar to the Flash Lite implementation of System.Capabilities.hasStylus? Furthermore, if I write such functionality into an app, will AIR ignore or intercept such calls if the same app is installed on a device without that functionality?

D. Most important (to me, anyway) of all, is the issue of distribution. There was an exchange earlier today between Ted and Scott about distribution and monetization. If AIR-built apps are to be listed in respective ‘app’ stores on different device platforms, will that require the developer to build/package the app for each device they wish to distribute too? Will there be a unified certificate or similar approach to protect source and assets from onedevice/store/platform to the next?

I’ve got more questions, but I’ll leave that for another post. Forgive me as I know the announcement is super fresh, and I’m sure many of these questions will be answered soon. My excitement has me desiring many answers and discussion now. If you have any thoughts or answers, similar or on other aspects, please post them and let’s get a dialogue going here. (Feel free to direct responses/comments to brother Kevin Suttle’s post.)

I am working on a little AIR application that stores data both locally (SQLlite) and on a web service (PHP/MySQL) that I’m building in parallel. When the app starts, it requests initial data to populate a pair of DataGrids in the AIR app. I’m sending a URLRequest against a URLLoader with simple params and getting back XML. I am then looping through the items in the returned XML and adding them to an ArrayColletion that acts as the data provider for each DataGrid in the UI.

To bridge the data, I’m storing each item in a value object, so it is easier to reference the item’s properties when viewing and modifying data chosen (and moved around) in the DataGrid. I’m using a nifty trick which seems to be working great for mapping the XML child’s value right to the value object property. Take a look and see if this works for you:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

private function resultHandler(e:Event):void
{
	var resultXML:XML = XML(e.target.data);
	var items:ArrayCollection = new ArrayCollection();
	var item:itemVO;
	// Convert XML to ArrayCollection
	for each(var itemXML:XML in resultXML.item){
		item = new itemsVO();
		for each (var itemProp:XML in itemXML.children()) {
			//Use XML node name to reference matching property in value object				
			item[itemProp.name()] = itemProp;
		}
		items.addItem(item);
	}		
}

Of course, this only works if you create properties in your value object that match the xml nodes you are returned (or that are being returned) from the web service’s XML.

I’ve heard rumors that over a hundred were turned away from my session today at FOTB. I’m happy to say that my debut presentation at Flash on the Beach was super fun and very successful. The stereo microphone demonstrations were flawless. All in all, the questions and audience participation were the best I’ve ever experienced. Tons of positive feedback!

Presenting at FOTB Brighton from Chuck Freedman on Vimeo.

Even after I was done, nearly 20 folks lined up to meet me, ask deeper questions and talk some more on stereo microphone usage and ideas. Thankfully, I had a bunch of Ribbit shirts and Moleskins to give away.

I also noticed a bunch of very respected community members in the audience. To a speaker at any level, it’s always great to see other fellow speakers interested in what you’re doing.

In light of the fact that so many people had to miss my sesison due to limited space, I hope to have a bigger room next year. But, as FOTB organizer John Davey pointed out, the intimacy between speaker and audience that the FOTB Pavilion provides is often a very coveted thing. I loved it and hope to experience it for years to come.

FOTB is living up to it’s amazing reputation, and per 2 Adobe attendees I’ve talked to, it’s now considered the best in the world!

After spending the bulk of my ‘personal coding time’ over the last 6 weeks on building my first iPhone game/application, I’ve moved on to another mobile coding platform. After 6 weeks of learning Objective C and Xcode (also my first time coding on a Mac), I’ve jumped back in time to a mobile platform called Flash Lite. Pretty insane. It’s a mobile coding mind bender. The developer’s equivalent to a gender transformation.

These are completely different platforms, and the approach, ‘vibe’ around them, and outcome couldn’t be anymore different.

With the iPhone, with each compile & build, seeing and feeling the app load on a my sleek iPod Touch, I felt like I was an Olympic swimmer, making a sleek dive off a precision diving board into a crystal clear pool surrounded by people sunning themselves and drinking vibrant cocktails.

On the other side, cracking open Flash Professional, coding archaic ActionScript 2 and compiling into the Flash Lite simulator they call Device Central, the experience was much different. It feels like you’re climbing up those wet and slimy stairs of a pool slide, making your way down the insufficiently watered and windy curves, somewhat burning your skin on the sides of the dry plastic, before getting dumped into a pool of a few senior citizens floating on foam noodles and sort of applauding at me.

Strangely… I still really love the latter experience. Why? Because it feels unique and un-crowded. The stuff I’m doing seems far more untouched, less shiny, yet way more revolutionary. And the stuff I build with the latter process can be published to a comparatively infinite number of brands and devices. The same Flash Lite (FP6 level) .swf I coded co-exists on both a Chumby, as well as my Sony PSP. (Pause for a second and imagine that. Two companies, produce two devices, meant for a much different purpose and market. Yet, they are bound by a common mobile platform that tells me, the developer, that I can WRITE ONCE!] I haven’t even tried my Flash Lite app on actual mobile phones yet. The thing is… I don’t need to. I know what I’ve done and accomplished. Feels good.

The app I built will be demo’d at http://developer.ribbit.com/blog in the near future.

While the process still needs a lot of help, I can see how Flash Lite (soon to be much grandeur Flash Mobile development) still has a huge place in this mobile application movement. And now that I’ve had my moment with Flash mobile coding, it’s back to iPhone to build another app that I hope thousands will enjoy — at Apple’s discretion, of course!

Internally, much of the company has been chanting “we are going beyond Flash and Flex”, but I don’t think the word ‘beyond’ is right to say. Maybe ‘to the side’. Definitely not ‘over’. Probably not ‘in a tangent’. However I can get myself to say it, Ribbit is about to offer the global developer community the ability to code our communications platform into their applications in more ways than just Flash and Flex. And this is a very good thing…

Since launching the initial SWC (now called our Flex SDK) back in August of 2007, the platform has enjoyed an incredible run as the leading provider of telephony, voice, messaging and user management services to developers. Our community of over 11,000 developers has built some amazing apps, many of which are hot contenders for our $100K Killer App Challenge, which culminates this week!

The RESTful API release is really an evolution for the platform as a whole. Unlike Flash Platform, developers will now be able to code machine to machine, schedule calls, perform advanced user management, create user tokens and so much more. The real gem presented in the RESTful API approach is that deploying this as a core platform API gives us the means to tightly wrap almost any other programming language (in demand) around it.

Essentially, you are going to see Ribbit offered to developers in languages like PHP, Javascript, Obj C, .Net, AS2 (for Flash lite development), Java, and pretty much whatever the community wants. The true potential for reaching the global community is unlimited and the wide array of language offerings means Ribbit apps can be built on almost any platform out there. And the RESTful API is going to go literally right under our Flash and Flex offerings, since those APIs can now leverage a much tighter data delivery protocol.

So, what does this mean for a lead evangelist (me, me) who wakes up and goes to bed dreaming of Flash Platform Apps? Well… if the Ribbit Platform was a chest of toys, I certainly have a much wider variety of things to learn, play with and show off to others! It also means I have access to another side of a web technology I still (sincerely) regard as the most innovative I’ve ever seen, touched or heard!

This news will officially come out from Ribbit while we’re at SxSw. There will be a special site launched (url to be announced soon) where developers can even go ‘vote’ on which language they want to see Ribbit release the most! And as for evangelism, I make my first non-Flash conference appearance in a week. It’ll be in Las Vegas. Sounds like MAX, ‘cept not spelled the same way.

A lot of Flex developers resort to Flex ‘states’ when adding interactivity and transitions to their applications. I built the sample below to show a colleague that using Flex ‘effects’ are some times easier and involve less code than ‘states’. This simple example (very beginner) shows how you could build a slide out menu bar without the use of states, which I consider a bit difficult to maintain and skin. The code is available for you just below the working sample.

Click the button on the yellow panel to see it slide out like a shelf.

You can cut and paste this code into your FlexBuilder project and test it out. Feel free to use this in any project or app you are working on.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" creationComplete="init()">
	<mx:Script>
		<![CDATA[
 
			[Bindable]
			private var bPanelStartX:Number = 0;
			private var bPanelEndX:Number = 0;
 
			//set position values for back panel
			private function init():void
			{
				bPanelStartX = frontPanel.x - 25;
				bPanelEndX = frontPanel.x - 100;				
			}
 
			public function movePanel():void
			{
				//set target of move transition
				panelMover.target = backPanel;				
				//determine direction of panel based on position
				if (backPanel.x == bPanelStartX) {
					panelMover.xFrom = bPanelStartX;
					panelMover.xTo = bPanelEndX;
				} else {
					panelMover.xFrom = bPanelEndX;
					panelMover.xTo = bPanelStartX;					
				}
				//play transition
				panelMover.play();				
			}
 
		]]>
	</mx:Script>
 
	<mx:Canvas id="backPanel" width="250" height="250" x="{bPanelStartX}" verticalCenter="0" backgroundColor="#FFFF00" backgroundAlpha="1.0">
		<mx:Button click="movePanel()" x="0" verticalCenter="0" width="25"/>
	</mx:Canvas>
 
	<mx:Canvas id="frontPanel" width="250" height="250" horizontalCenter="0" verticalCenter="0" backgroundColor="#FF0000" backgroundAlpha="1.0">
	</mx:Canvas>
 
	<mx:Move id="panelMover" />	
</mx:Application>

If you know or a more simple way to do this, please feel free to post it on your blog and comment the URL here. If you’ve got other examples of using transitions without states, feel free to post those as well.