• Learn how to do better OOP in Lua
• Learn how to extend the base Corona GUI classes like Group
• Learn about collision detection via their Box2D implementation

Mutha-grabbin success.

I set out to re-build 1942. It’s the perfect Corona game in that it has a lot collisions, sprites, and simple bitmap animations. I want to talk about what I learned in my 2 days. If you’re not familiar with Lua and know some ActionScript, hit my Lua for ActionScript Programmers Crash Course and check out a more simple example first. Here’s a quick sample video. You can download/follow the code on Github.

OOP in Lua

No one agrees on the best way to do OOP in Lua, specifically for Corona development. The official Lua docs give at leaste 2 different ways, and only 1 shows inheritance. This isn’t to say you can’t do inheritance with the first example, but this is a recurring theme I’m seeing: a blasé approach to OOP in Lua. Whether this is because the use of polymorphism and inheritance is seen as “over kill” for a lightweight scripting language, or is too old skool for a functional language, has seriously made it challenging for me to feel secure in what I’m doing.

ActionScript had a pretty standard path with only a few disagreements un-related to the actual result.

1. in Flash 5 & 6 with ActionScript 1, we used Object.prototype. While prototypes were mutable, most purists didn’t edit them at runtime. These were basically classes and is how some classes are implemented in JavaScript. Calling a prototype extension a “class” offends some people, but it works. You get sub and super classes with inheritance and polymorphism.
2. in Flash 7 & 8 with ActionScript 2, we had classes that looked like Java. While it compiled to AS1 prototypes, the advent of proper packages helped us scale larger class structures.
3. in Flash 9 & 10 with ActionScript 3, we have classes where the prototype is immutable, and we now have enforced access rights via private and protected.

While the Rebel Alliance had their own implementation of YourClass.prototype, and no one to this day agrees on how you create a Singleton, at least it’s pretty easy to tell if you’re doing something “the AS3 way” or not.

Contrast this with Lua specifically in a Corona context. So far, the 3 approaches I’ve found are:

1. Use metatables (from the main docs). Notice no easy way to call super in the inheritance example.
2. Another example which also has a fake prototype (also whack sub-classes compared to what I’m used too). If you liked AS1, you’ll totally understand their example… until you to try to sub-class it.
3. Use one of the 3rd party libraries like middleclass (thanks for the suggestion, Jim!)

You can read all the examples of just one particular site if you’re so inclined to do a deep dive.

Me? I just want re-usable objects that are DRY. It seems Lua is all about the re-usable and flexible objects, but how you implement DRY has no consensus.

For now, I’m using factory functions with no inheritance. This seems the most straightforward. When all else fails, you can use the Decorator pattern to add behavior you need without inheritance, and just “remembering” the interface via convention. I don’t know if any of you Flash Devs remember Flash MX’s DataProvider, or even the DataSelector; it would overwrite the Array.prototype and your Class’ prototype so you could implement the Observer pattern with a simple Array. Basically the same thing here; add the methods you want on a class at runtime since everything’s dynamic.

A word of warning for you Flash devs: you’re going to start to find all the old problems un-solved. I say “un-solved” and I’m sure there is some Lua veteran going “what problem…?” in his/her head. Specifically all the scope issues we had in AS1/AS2 using Activation Objects, and Delegate. Functional afficiandos’ think it’s neat… until they have a deadline (which they don’t).

Factory Functions & Closures

Factory functions in Corona build things for you. Factory functions as I implement them in Corona are similar to attachMovie back in the AS1/AS2 days in Flash. Instead of doing “new MovieClip()”, you’d go attachMovie(“your gui thing”, YourClassToMergeItWith). In this case, we’re creating the GUI thing, then decorating it with functions and public variables we need. It’s quick, it’s encapsulated, and calling the function gives you the object as a return value if you need it.

Closures are basically functions within a function. People go all Lady Gaga over them and I’m not sure why. They are convenient when quickly prototyping, yes, but once you do a DRY run over your code, they tend to disappear… *ahem*. Anyway, Lua has a lot of scope in common with JavaScript and ActionScript 1 in regards to nested objects and functions. I’m still learning the finer rules of the difference between functions functionName() and functionName = function() (huge difference in AS1 that only academics care about), but bottom line, you can define additional class like behavior on existing objects at runtime. The closures, or “functions within a function” are that additional added functionality.

Here’s an example of how I create an explosion animation when an enemy plane is shot in my simple PlaneShooter game:

function createEnemyDeath(targetX, targetY)
	local si = sprite.newSprite(enemyDeathSet)
	mainGroup:insert(si)
	si.name = "enemyDeathSetYo"
	si:prepare()
	function onEnd(event)
		if(event.phase == "loop") then
			event.sprite:removeSelf()
		end
	end
	si:addEventListener("sprite", onEnd)
	si:play()
	si.x = targetX
	si.y = targetY
	return si
end

Notice we’re taking a Sprite sheet animation, and handling loop event (called “sprite”) inline. This, as opposed to burdening whoever is calling the createEnemyDeath function. We also do some non-factory function stuff like assume mainGroup is already created and ready to have DisplayObjects added to it.

Ok, that’s a simple use of a closure, but let’s show how you add behavior to existing Corona object classes via closures with intact scoping (yes yes… more on scoping in a bit). There’s a lot of code in this next snippet; just scan it, I’ll go over the relevant pieces below.

local function createPlayer()
	local img = display.newImage("plane.png")
	mainGroup:insert(img)
	img.speed = PLAYER_MOVE_SPEED -- pixels per second
	img.name = "Player"
	img.maxHitPoints = 3
	img.hitPoints = 3
	
	physics.addBody( img, { density = 1.0, friction = 0.3, bounce = 0.2, 
								bodyType = "kinematic", 
								isBullet = true, isSensor = true, isFixedRotation = true,
								filter = { categoryBits = 1, maskBits = 12 }
							} )
								
	function img:move(x, y)
		self.x = x
		self.y = y
	end
	
	function img:onBulletHit(event)
		self.hitPoints = self.hitPoints - 1
		setHealth(self.hitPoints / self.maxHitPoints)
		if(self.hitPoints <= 0) then
			self.isVisible = false
			audio.play(playerDeathSound, {loops=0})
			createPlayerDeath(self.x, self.y)
			stopPlayerInteraction()
			endGame()
		else
			audio.play(playerHitSound, {loops=0})
		end
	end
	
	function img:tick(millisecondsPassed)
		if(self.x == planeXTarget) then
			return
		else
			local deltaX = self.x - planeXTarget
			local deltaY = self.y - planeYTarget
			local dist = math.sqrt((deltaX * deltaX) + (deltaY * deltaY))

			local moveX = self.speed * (deltaX / dist)
			local moveY = self.speed * (deltaY / dist)

			if (self.speed >= dist) then
				self.x = planeXTarget
				self.y = planeYTarget
			else
				self.x = self.x - moveX
				self.y = self.y - moveY
			end
		end
			
	end
	
	return img
end

This function does a lot. It takes an image and adds TONS of behavior to it. Notice how I take the image that Corona builds for me from a simple PNG, and immediately add a speed variable to it. This does 2 things. The first is it allows me to later access this variable from internal “Player” functions via self (like ActionScript’s “this”). Secondly, I basically create a “PlayerClass” that has a public speed variable. Since everything in Lua is basically a Table, and a Table is basically an ActionScript Object, it’s dynamic, so we can add whatever we want to it at runtime.

Ok, so that’s properties. Now onto methods. I add 3 here: move, onBulletHit, and tick. Each is unique. Notice the format of move.

function img:move(x, y)
	self.x = x
	self.y = y
end

I take an instance, img, and add a method to it called move via the colon (lol!). This is a simple utility method, but shows how you can add simple utility methods inline. If things start to get duplicated, you can use the Decorator pattern mentioned above to dynamically add them later in a single space. Notice too that he has the use of “self” inside of the function. You can have faith that if he’s called correctly (more on that correctness later), he’ll have the self pointing to the img instance.

Let’s take a look now at “tick”, an impl method, also known as “an implementation method of an interface”. The interface here is “Jesse Warden’s convention of having all game loop participatory objects implementing a tick method which he’ll assume is there later and if not via an error in the console, then he’ll fix it”. People who like dynamic languages to make a living are strange.

function img:tick(millisecondsPassed)
	if(self.x == planeXTarget) then
		return
	else
		local deltaX = self.x - planeXTarget
		local deltaY = self.y - planeYTarget
		local dist = math.sqrt((deltaX * deltaX) + (deltaY * deltaY))

		local moveX = self.speed * (deltaX / dist)
		local moveY = self.speed * (deltaY / dist)

		if (self.speed >= dist) then
			self.x = planeXTarget
			self.y = planeYTarget
		else
			self.x = self.x - moveX
			self.y = self.y - moveY
		end
	end	
end

Also this game loop method doesn’t make use of the time, we’ll ignore that for now. Just focus on a few important details. First, yet another function I’ve added dynamically to player sprite to emulate a class that has methods. Second, it has self, just like the others so it knows about itself and is independent from other instances without the need of global variables. Third, it makes use of local variables, just like var variableName used inside of ActionScript functions. Third, I still have access to all the basica Corona functionality, in this case the math.sqrt function. Fourth, because of self access, it too can access instance variables as well.

Normal stuff, right? Ok, now the 3rd, an event listener like ActionScript ones (has the “on” prefix, and the 1 and only parameter as event).

function img:onBulletHit(event)
	self.hitPoints = self.hitPoints - 1
	setHealth(self.hitPoints / self.maxHitPoints)
	if(self.hitPoints <= 0) then
		self.isVisible = false
		audio.play(playerDeathSound, {loops=0})
		createPlayerDeath(self.x, self.y)
		stopPlayerInteraction()
		endGame()
	else
		audio.play(playerHitSound, {loops=0})
	end
end

The only thing to notice here is that I'm calling global functions. I didn't use "local" in front of setHealth, createPlayerDeath, stopPlayerInteraction, and endGame so they are global functions; meaning anyone can call them (like $global in PHP).

Again, standard stuff, right? So how do we ensure this "self" variable works and doesn't break...?

A Quick Intro to Lua Scope

You can read more about it at Stackoverflow (scroll to the bottom where jhocking answers it). Basically, the rules of accessing Tables (Objects for you ActionScript devs) goes like this:

When reading and writing properties, use a dot.

When calling functions, use a colon.

Why this is a feature of Lua, I'll never know, but ActionScript 1 and JavaScript have the same "feature" (read: problem if you're a Flash/Flex dev).

If use a dot, you have to manually pass in scope. If you use a colon, then when you use self inside the function, it points to the object you're calling the function on. Usually; again, it depends on 1 of the copious ways one can define functions. If you do it like I do above, you'll be fine.

Callback Weirdness

There are some callbacks where more advanced functional programmers will want to put a closure as their event listener handler. This is because some of Corona's events require a pointer (no, I don't know why). Let's take Box2D's collision, for example (Box2D, while a completely separate physics engine, treats Corona objects like any normal object). Here's the collision code for an enemy bullet:

function onHit(self, event)
	if(event.other.name == "Player") then
		event.other:onBulletHit()
		self:destroy()
	end
end

img.collision = onHit
img:addEventListener("collision", img)

Notice the collision pointer to the function. Also notice I define it as onHit vs. img:onHit... and self is the 1st param. Confused yet? Just know that those edge cases WILL give you self as a 1st param. If not, you can wrap it in a closure like so:

obj:addEventListener("touch", function(event) self:onCustomHandler(obj, event) end)

Collision Filters

Box2D, and thus Corona, comes with this nice feature for collision detection. Instead of having a ton of if/then or switch logic in your collision handlers, you can instead apply filters so that only certain objects trigger collision events when they collide with certain objects. In my game, the player's airplane can collide with enemy planes and enemy bullets, but not with other player airplanes, nor with his own bullets. The enemies cannot collide with each other, nor with their own bullets.

The problem is it makes my head hurt. Apparently others as well. So this cool guy named Brent Sorrentino made a great explanation + chart.

It helps you identify who can collide with what, and you end up with 2 numbers to use in your code, called category bits and mask bits. OT OT OT

Here's the Google Spreadsheet I made to determine what bit filters I needed for my game:

From that, I can implement the filters for my enemy bullets (just look for the filter option):

physics.addBody( img, { density = 1.0, friction = 0.3, bounce = 0.2, 
	bodyType = "kinematic", 
	isBullet = true, isSensor = true, isFixedRotation = true,
	filter = { categoryBits = 8, maskBits = 1 }
} )

Now my collision events are like "Dude, I hit players only, so... simple if then statement, yo!".

Conclusions

I still haven't found the Branden Hall, Dave Yang, nor Colin Moock of Lua. All the blogs I read are humble opinions from smart people. While nice, we need leadership with someone to put their foot down on how OOP works in Lua for Corona. At least we don't have a module problem like JavaScript.

Maybe they exist and my 5 day Corona/Lua excursion just hasn't found them yet.

Many of you have asked what my draw is to Corona. Mainly the built-in Physics engine with collisions, other built-in gaming API's that'd require a bit of work in Flash/Flex, ...and Lua is a nice change of pace. I give her crap, but it's fun.

I encourage you to take a visual scan at the left side of the API page, I'm sure you'll find something you'd like to play with.

If you’re not familiar with SoundCloud, it’s a website where artists and DJ’s can upload music.  Users can then see, listen, and comment on this music.  I personally use it for following others who search the site regular and favorite music they like, as well as my favorite DJ’s.  Since I follow them, I find new music that is hand picked by people who have styles similarly to me every week.

I use many music services like Pandora, YouTube, and online radio stations like di.fm and soma.fm.  For my phone, however, I couldn’t get SoundCloud and the existing apps didn’t do what I wanted.  That, and I needed an excuse to build an Android app.

Technical Details

I’ve tested it on a Google NexusOne and a Droid 2.  What was great is that they ran the same.  This was the biggest problem I saw when doing Flash Lite 2 & 3 development for Symbian devices is that they were widly different, and some things worked on one device didn’t work the same, or at all, on others.

I started the application as a pure ActionScript 3 project because I couldn’t figure out what I was doing wrong with the Flex tooling until I was half-way done.  For fun, I ported it to Flex 4 midway through just to compare the performance.  There wasn’t a huge noticeable difference like I thought there would be.  The only things that were noticeable was that the ActionScript 3 one starts up way faster, and the Flex one uses a lot more RAM.

I built the components on top of Keith Peter’s MinimalComps.  I put a ton of my own hacks on top including invalidateProperties to be consistent with the Flex API, as well as a simple state system also similar to Flex for the larger, composited components.  I utilized Robotlegs for the architecture on top of the Views, which will make it a lot easier to port to iPhone/iPad since I’ll just change the GUI code.  For connecting to SoundCloud’s API, I utilized Dorian Roy’s SoundCloud AS3 wrapper.  I had to hack it a little for GET requests, but Dorian knows about it.  I used Intellij in the beginning for about 1 week, and later Flash Builder 4 and mxmlc to test locally, and just ran the command line Terminal on my Mac to create the APK (application files used to install on Android devices), and install to the device connected via USB.

I designed everything in Fireworks, created the site in Dreamweaver, and crated some visual assets in Flash.  Adobe discourages the use of the drawing API on AIR for Android, so some of the things I just made dynamic MovieClips in Flash.

I spent 2 weeks on it in my spare time; 5 minutes one night, 4 hours another, and weekends.

Challenges

There were a lot of challenges.  First off, no one seemed interested in helping me get Flex up and running on the forum.  When Renaun & Joe finally figured out what I was asking, they pointed me to some older setup docs which do work… but are seriously ridiculous.  This isn’t the fault of Adobe; the tooling isn’t ready yet.  However, if it ISN’T ready by the time they launch, they won’t get much traction.  You should be able to just “create an Android Project” in Flash Builder.  The whole create a Flex web project, and then delete your main file, create a pure AS file, and then add AIR nature is just too much hassle.

Secondly, Flex bias is apparent.  Whether they are afraid “slow Flex apps” will give AIR for Android a bad name, they’re still angry at Adobe not treating pure AS3 developers like first class citizens, or are frustrated at all the young whipper snappers who don’t appreciate their pain from the Flash Lite days, it’s pretty clear there are 2 camps.  This isn’t healthy, but I don’t know how to fix it.  On the web, it’s different.  If you have large clients creating large applications, you use Flex.  If you have agency clients, you use Flash; it’s pretty black and white.  On mobile, I reckon we’re still figuring things out.

Third, I was pleasantly surprised by ActionScript’s performance on the devices.  It was the actual refresh rate/frame rates that were depressing.  I’m getting the same FPS I was getting 4 years ago on a Nokia 6680 using ActinScript 2 on Flash Lite 2.1.  That, folks, is depressing (no optimization in both cases).

Fourth, some of the optimizations you’re required to do seem unrealistic and unreasonable.  For example, I get creating bitmaps at the size you’ll actually use them.  But creating bitmaps as powers of 2, manually stopping events from bubbling, and adding final onto your functions everywhere just seems ridiculous.  The cacheAsBitmap, cacheAsBitmapMatrix, and scrollRect uses are still reasonable, although, still challenging in creating applications.  For the bitmaps, it’d help if Adobe created tools to help you ensure you’re bitmaps are optimized for devices size wise, whether export dialogues for Photoshop/Fireworks, or import dialogues for Flash/Flash Builder.  For event bubbling, no clue what Adobe can do.  For the final and other ActionScript optimizations, they just need to make adt better; optimize AS3 for the devices.  This is round 1, so they TOTALLY get a free ride till version 2.  Remember, AS3 for Flash Player 9, while insanely faster than AS1/2, still had a ton of optimization done for it in 10 and even more in 10.1, so clearly they have room to improve here.

Fifth, designing for mobile is hard.  It’s like 2004.  For example PPI, pixels per inch, affects how big your buttons and graphics should be.  The devices we’re running on have insanely high resolutions.  This means that while the graphics may look like Fisher Price (over sized, kid like) on your screen, they can actually be quite small on your phone.  Since the current Android devices I use have horrible touch interactions that aren’t as sensitive nor as responsive as iPhone/iPad, you really need to make buttons larger than the recommended 46×46 to ensure your app is usable.  I recommend 72×72, minimum.  This puts a strain on an already real-estate constrained interface.  You don’t have a lot of room to start with.  Combine those challenges with the need to support rotated interfaces; either you scale your interface, you change it’s look and feel, or you go a step up and change functionality entirely when someone rotates the device to landscape.  Finally, I have to completely redesign the same app for iPhone since they have different GUI guidelines… and iPad because it’s larger…  dear god…

Sixth, coding user interactions for mobile is hard.  For the browser, we’ve never had good integration in Flash.  It took half a decade to get a decent SWFAddress, and even now, in 2010, there are a ton of Flash websites and Flex applications that don’t support the back button correctly.  This is no longer a technological problem, but a design one.  For AIR for Android, we have all the hooks IN the Keyboard code.  This is great.  However, it’s still hard to design components to support the Command pattern with undo so you can “go back”.  Going from a search results screen to a search screen is one thing, but making each part of the app support this, as well as supporting a global history management that can tell which state should go where is… hard.

Seven, there are a lot of weird things mobile does that the desktop does not.  For example, Flash Player 10.1 has optimizations so when you’re SWF isn’t in the foreground browser tab, it’ll use significantly less resources.  For mobile apps, you’re app does something similar when it goes to the background.  However, you have no guarantee it’ll stay there; the OS could decide it needs the resources.  Some people just do a NativeApplication.nativeApplication.exit() to stop the app entirely if it goes into the background; but some apps need to be paused in a certain state of the user gets a phone call for example, or my app which plays music.  I’ll be checking an email, take a call, and then go back to what I was doing.  Your app should support this workflow as well, EVEN IF it was shutdown.  Again, this puts a lot of challenge on your code to ensure your app can support starting up in certain states with data ready to go.  Another thing to is you need to ensure you don’t go below 4 fps (the current default) when you get an Event.DEACTIVATE since some network connects will drop if you go below that.  You can certainly set stage.frameRate to 0.01 if you wish, just make sure you don’t have any network connections you care about.

Eight, with the current build, audio skips when you use the phone, even to just browse/slide through your applications.  My iPhone, and others’, doesn’t do that with the iPod app, nor does it do it when you compile the exact same ActionScript for iPhone (which, technically isn’t ActionScript anymore, hehe).  Adobe knows about it, it’s logged, and they are I’m sure challenged with prioritizing focusing on features, new features, phone specific bugs, runtime specific bugs… I wouldn’t want their job.  While it’s disappointing a simple Sound sound class doesn’t work right while in the background, this is still early builds of a non-released product, so I’m positive they’ll fix it.  Again, once I saw the same code working the same on 2 completely different Android devices, I was sold.

I’m building applications, so these challenges are specific to apps, not really games.  They actually might have more challenges with performance that I didn’t have.

Marketplace: The Good and Bad

The Android Market is light years easier to sell your apps on compared to Apple’s insanity.  I won’t go into the business ramifications in this post, but I will say it’s no lie you can have your app, on a device for sale, in less than 3 minutes.  That’s just full of win.  Being able to immediately see my app for sale on my phone’s marketplace that quickly is just awesome.

The marketplace does have problems, though.  First off, these certificates provide no value.  None.  Using certificates in Android AIR development, again, is light years easier compared to the f’ing insanity you have to go through with iOS.  You just do 1 command line entry, or just publish from CS5, and then compile your app with that file.  However if the file changes, your entire app is considered “different”.  I had create an entirely new app for Android’s market place, for the exact same application, because I accidentally recompiled the cert.  With the exact same info.  The marketplace doesn’t care, either.  Worse, if the apps have the same package name id, it still thinks they are the same even though it just said they were different.  They even discourage you from using their soon to be deprecated licensing system.  Again, certs provide no value, and are a royal pain in the arse.  Screw certs, I hope they die.

Another problem is there isn’t an easy way to inform users of what’s changed in different versions.  In Apple’s AppStore, you’ll often see app updates that list what changed.  Android Marketplace doesn’t give you enough room in the description field to keep a running tally of changes.

Yes, the user feedback commenting system has the same problems Apple’s AppStore does.

Conclusions

All in all, it was an extremely pleasurable experience developing my first app for AIR for Android despite the Flex bias, tools not being ready, and having to suffer in pure AS3 vs. Flex.  It was also nice getting my first sale on the frist day it was posted! I’ll be porting this app over to iPhone/iPad, and then start on some other ideas.  I’ll definitely be doing my next app using Flex vs. pure AS3; even without Hero being ready, the Flex 4.1 SDK worked fine.  I’m not obsessed with getting all the exact user gestures down.

It was also pleasurable to spend just 2 weeks on a simple app vs. 6 months.  Since the applications for mobile can be smaller in scope, you get a quicker feeling of accomplishment.

Thanks to the AIR for Android team for their help, the people on the forum who put up with my mouth and helped, and Adobe for the devices to test this stuff on.

With all the economic and tech turmoil the past year, many have shown a yearning for something stable amidst it all. Some of the mobile & device hype has actually come to fruition without Flash Player taking a starring role. This has had harsh marketing/PR consequences for many peoples continued, or lack of, faith in the platform.  This is ecspecially true for those of us in the Flash community for awhile; we’ve been hearing for a decade about Flash on mobile, and have long since been tired of hearing it.

We’ve already seen some luminaries leave the platform for iPhone like Aral Balkan & Keith Peters, some for good, some returning (welcome back sexy man Keith). Others have thrown in their joy with Unity 3D. All the while we have HTML5 deceitful propaganda biting at the heels for those of us who have stayed.

What’s next? What technology is coming that we should invest our time in to ensure a continued prosperous career? Should we stay with Flash Player?  Is there something I can focus on that’ll help me find a niche and as an early adopter get a payoff?

Today, I want to layout what I think is coming the next 6 years to at least put your mind at ease if you’re a Flash/Flex Developer.  These are my projections based on what I’ve read, corroborated from talking to colleagues and other reading, and based on past experience.

What’s Next

Android. And some iOS.

Other Options?

We have a variety of options, for sure:

iOS: proven market, great existing devices with new ones with different verticals coming. Growing for B2B, not just consumer.

Unity 3D: Uses the wonderful language C#, targets PC, Mac, and iPhone, and has a lot of hardware acceleration hooks. Has shown much success in the past 2 years, and EA’s massive investment shows there’s a growing market there.

Windows Phone 7: Again, the wonderful C# language, best developer tools in the industry, and a similar story to Adobe: a runtime that allows for desktop, web, and device (in this case mobile) delivery.

Web: As many businesses find new ways to make money online as well as off, reduce long term costs by investing in services both for themselves and their customers, this is perhaps the most stable place to continue to be since the technology will always work in some form on various devices and existing desktop hardware.  I’m talking the traditional HTML/JS/CSS stack with associated libraries here, regardless of your middle tier.

Why not those?

iOS: While our recent permission to re-participate on the platform has us all feeling like it’s tenuous, there have been a few key reversals from Apple recently that does a lot to show me there isn’t any turning back now (Google Voice, Lua based games, Unreal engine, etc).  There will be work for creating applications utilizing Flash & Flex for iOS devices. Specifically, iPhone and iPad using Adobe’s packager. And not JUST the iPhone packager… we can utilize a lot of the same code & assets for Android deployment as well.

Why do just iOS when you can do both it AND Android as well?

A few in the community claim to have made the transition to Cocoa just fine.  It’s clear Cocoa isn’t for me.  Many ran into the some challenges I had with Objective C, and it just wasn’t as fun as Flash & Flex are.  Now, we can still use Flash & Flex with shared code for other devices & OS’.

Unity 3D: Yes, I too dreamed of growing up, moving to Japan, and working for Squaresoft. Then games got cool. Then market pressure for more demand resulted in quality reduction and perceived consumer expectations being lowered. This in turn allowed many companies to validate that making sub-par games is not only ok, but profitable. Yes, there are many companies out there that believe in quality. What sells right now, and has for the past 6 years especially on the web en-masse, is git-r-done engagements.

No thanks, I prefer to build Porches, not Kias, and see no steady money there. That said, I still look on longingly.  My current skill set, and those of many Flex Devs, is best at delivering applications, not games.  That said, I’ve read of more than a few Flash devs trying and loving Unity 3D, some having half or all of their work come from that platform.  You can make $150,000 doing Flash games.  Some will even work on iOS/Android.

Again, Flex devs like me build applications, not games. I use MVP, not meta-tiles for reduced collision detection.

Windows Phone 7: It doesn’t exist yet in the consumer marketplace. We’ll know in January how it sold, and even then, I don’t think that’s a large indicator of it’s future success. That, and there hasn’t been a lot of press about other devices beyond mobile using Windows Phone 7. I’ve met some of the people behind this initiative, and believe Microsoft is making wonderful, and correct, strides here.

I just worry that the other half of Microsoft will actively sabotage the great things they’ve created.  The web and desktop teams are SOOO different in outlook.  I have no qualms being a late adopter here.  Right now, there isn’t a market for my clients to target yet.

Web: Uh, no. I love JavaScript, but I have enough challenges with lowering my project capability expectations for Flash Player on devices. I don’t mind lowest common denominator experiences as far as mobile concerned because at least with Flash player there are still features Flash Player can do that the browser can’t. The little things like with getting custom deigns implemented continues to set Flash apart in this regard even on devices.

When & Where

You can develop for iOS and Android today.  Yes, they work.  By Adobe MAX, hopefully everyone can participate in the Android sphere (Flash CS5‘s been available for awhile).

Since consumer phone/device/Operator contracts go in 2 year cycles, we’ll start to get early adopters next year as more and more Android’s devices proliferate.  This includes tablets, not just phones. Some of the design agencies will just opt for a Flash on iPhone/iPad experience when they need something a step up from the HTML/JS capabilities since there aren’t enough Objective C coders to go around.  Since we can share a lot of the same ActionScript code on both iPhone and Android, this’ll segue nicely for sales teams looking to provide their customers “solutions across both desktop, web, and mobile” even if the mobile story continues to be fragmented.

Additionally, as Jesse Freeman pointed out awhile ago, it’s really cheap to get a Flash Designer to prototype applications using Flash vs. Objective C.  Many companies such as T-Mobile have been using Flash to prototype for C on phones for awhile.

Some participation with existing, already on-staff skillets for experiences that are good enough for consumers will sell.

For service providers such as my company (we build software solutions for other businesses), I don’t think it’ll pop up as fast; maybe not till 2014. In fact, we may just get off loaded to by Agencies who don’t have on-staff competency for more of the CPU/RAM intensive projects that are non-game related such as data visualization, or the larger applications for a device and running into scalability problems.  Flash Player runs great on the web, yet I still often get scalability jobs regarding Flash Player web/desktop projects.

Where we WILL see work is when some companies, even for the wrong reasons, need mobile versions of their web apps.  If it’s built in Flash/Flex, it’ll need a mobile equivalent.  So they say.  If that mobile equivalent, or perhaps even a device other than a phone, supports Flash, then you can leverage a lot of the same code.  More importantly, though, some of the API’s that AIR allows you to hook into allow more features than a browser can provide, so there are also cases where it’s the right reason.

In 2012 there should be a slight up tick as people finally renew their aging phones for Android/iOS devices, and start bringing them to their workplace. It’ll only take another year for businesses to start seeing this (again), and start targeting consumer applications for devices. By then, Hero (Flex 5 SDK with mobile focus) will have matured, and Adobe will have learned what areas need improvement. By 2014, it won’t be considered “risky” to utilize the Flex SDK for a project vs. straight AS3; it’ll be the preferred method for people like me vs. the current way of using pure ActionScript 3.

Flash/AS3 Developers

You have it best right now.  You are the ones most capable to participate, today.  You really have a chance to make a name for yourself.  I’ve been following the Flash Lite email lists for awhile; the community is small.  Good opportunity.  You may get early adopter clients this year; next year things should start to pick up from many different types of clients as the brave ones start to explore.

Flex Devs

If you have the time, I encourage you to give the Android/iOS builders a try.  If pure AS3 isn’t your thing, give the native Android development a try; it’s very similar to Flex.  If you’re willing to drop back to pure AS3/small component libraries with no MXML, you could definitely prosper here if apps really do take off (as opposed to traditional games and other ad ware that will be inevitably be developed by the agencies; that crap is already proliferating on the app store and companies DO get paid to make it).

Any Negatives?  You’re being pretty positive here

Two.

First, I’ve been lurking on the Flash Lite email lists for about 5 years.  I watch developers who make content for mobile using Flash Lite (Flash 5 basically), and I learn about their development challenges.  The one thing that scares me is they have basic problems that shouldn’t happen.  For example, loadMovie (Loader/URLLoader/URLStream.load for those not in the know) just won’t work correctly… ON SOME PHONES. Others, it’ll work the same.

I can confirm that AIR for Android works great.  For Nexus One.  I haven’t tried it on other Android phones/devices, so I don’t know if fragmentation is a huge problem beyond the obvious performance one yet.  I also haven’t done a larger Enterprise esque’ project on it yet to truly battle test her.  I can confirm Flash Lite is also good technology, having a lot of fun with Flash Lite 2.x 4 years ago on a Nokia 6680.

That’s what scares me.  Operators do stupid things.  I’ve already read articles about Java’s fragmentation on Android phones (the device stats I’ve seen aren’t really that valuable yet) like some phones have 2.0, others 2.2, and even some of the 2.2 Froyo where the Operator hasn’t confirmed it’ll actually have Flash. *face palm*.  I haven’t gotten any insight if the JVM for various devices has any notable quirks like I know Symbian does for Nokia phones.  I have more faith in Google making Android than I do Motorola making a custom version of it with their bloatware, and us all hoping it works the same.  Time will tell (a hopefully positive story).

Second, if it takes off next year, this is more ammo for pure ActionScripters like Steven Sacks and Jesse Freeman to continue ignoring Flex for applications that should of been built in Flex instead of pure ActionScript.  Once the phones get powerful enough to run Flex, they’ll still swear by their Button being faster than a Flex Button, even though the user’s can’t tell.  Dammit.

Conclusion

If you’re a Flash/Flex Developer, and wondering what is next, it’s developing mobile Android and iOS applications using Flash and Flex IN ADDITION to your existing skill set.

It won’t take off as quickly as Flex did.  We have these things called “Operators who think they can draw well” and “Google without Designers” and “Cupertino Illusionist” and “recession” and “people who see beyond the hype” all collectively slowing it down.

I know it’s not as exciting as going from Director to Flash, or Flash to Flex, or Flash to Unity.  There’s a reason there aren’t any exclamation points in this post (yes, JXL blog post with no !… er, shit… there’s one).  At least, it doesn’t feel very exciting to me since the market just doesn’t seem to be there yet, and the current phones/tech is just slow compared to what I’m used to.  And I’ve been hearing about it for 10 years, and still won’t see a decent pay off for another 2.  I’m not seeing any signs it’s NOT going to be there in the timetables I mentioned above, though.

Seriously though folks, once Apple said we could play in their sandbox again, it actually increased the value of our ability to target Android as well.  Suddenly ubiquity via Flash is in play again.  It’s just on devices that are still slow, and Adobe’s only been optimizing for them for 3 years (maybe more based on Tamarin checkins).

Remember, too, a lot of web content is optimized for mobile, like this blog.  Optimizing for mobile is no longer a “omg, more work, less dough” scenario; it’s just expected that’s what you do.  There will be a lot of Flash content that will need to be optimized to run on Android device browsers as well in the desktop browser as opposed to making an application in AIR.  Keep in mind that’s not just “2 screens” either; it could be 3, or when one rotates/flips it.  That’s a lot of work that you can get paid for.

Breathe & Go Download Starcraft 2

So there it is.  Relax, you don’t have to learn HTML5 nor Objective C.  Unless you want to, in which case, pimp.  You can rely on the web for most of your income, and mobile/devices will eventually pay off your investment in it.  I wish I could make it more exciting, but the truth in this case, while cool, isn’t as cool as Starcraft 2.

The good news is, since technology changes so fast, there may be something epic-cool that comes out of this recession.  This one has been harsh, and recessions often spawn magic.  There’s no reason we couldn’t abandon the above plan and jump on whatever that new technology is.  I just haven’t seen it yet.

*** Update: Paul Taylor (@guyinthechair) has a more recent post on the same subject. ***

*** NOTE: I’m a n00b at Cocoa and Objective C. Unlike Python, I don’t like learning it, either. If you perceive something below is inaccurate, please comment, and I’ll update. ***

Preface

I was having a lot of fun using the iPhone packager. Then Apple changed their licensing to prevent people like me from using ActionScript for iPhone/iPad, and instead being forced to use their toolsets, or those unofficially approved. At first I was furious. Then I tried to get a simple list to scroll in AS3. Even using a fake mask, device fonts, and cacheAsBitmap for all items + container, it just wasn’t smooth, even with just 30 items, regardless of frame rate. If you use an out of the box UITableView in Cocoa, it “just works”.

I built my career on Flash Player because “it just works”. It doesn’t “just work” on the iPhone, and now it’s effectively illegal to use. That, and Adobe has apparently abandoned ship on the iPhone/iPad/iTouch portion, and instead are focusing on Android.

I was amazed at what I could do using Flash Lite 2 on my Nokia 6680 3 years ago. AS3 was all the rage, and yet I took the time to build a component framework in AS2 for use on devices because I felt it was “good enough” to build experiences for consumers. That market never materialized unless you targeted Japan (which I didn’t).

After finally getting my simple SWF to compile to the iPhone, I was estatic at how easy it was to design & code in what I knew, it just worked, and looked like I expected it to. Once I started moving things via TweenLite, though, it all went downhill. I don’t have these problems in Flex. If I use a List control in Flex, it just works; I don’t have to be an AS3 game developer to theorize on GPU acceleration possibilities to get the best list scrolling performance. I don’t have these problems, at least from what I’m initially seeing in my early learnings, with Cocoa.

So, I’m learning Objective C so I can execute the ideas I have for iPhone and iPad. Unlike PHP, Ruby on Rails, and Python & Django, this has been a pretty miserable experience. Python and Django are my choices for back-ends currently… but I don’t really have a “choice” for front ends on iPhone/iPad.

In an effort to reduce the pain for others as well as help myself retain this knowledge, I’m writing it down.

I understand it might seem strange since Android is a lot easier to develop for, and Flash Player 10.1 actually runs natively on the phone… and well, I might add. For me, there are 3 reasons. First, there is no market right now. Yes, I understand we help create it, but I own an iPhone and iPad. I love them, and so do others. I have a gateway to others right now via the app store, and want to empower them to use my apps. Secondly, if you’ve ever used an iPad, the additional screen real estate just fills you with ideas. Third, everyone wants an app right now. While the consumer data shows it’s hard to make money, it’s REALLY easy to make money for services; aka, a company hires you to build an app for them. This is especially true with the OS4 announcement of Enterprises having more control over deploying their own applications.

Another good primer for me, Objective C for the ActionScript Developer, is Keith Peter’s five tutorials. He doesn’t really cover the UIKit, just Objective C in general which is a great first start.

1. AS3 to iPhone Tutorial 1
2. AS3 to iPhone Tutorial 2
3. AS3 to iPhone Tutorial 3
4. AS3 to iPhone Tutorial 4
5. AS3 to iPhone Tutorial 5

Introduction: Nomenclature

There are a lot of new terms to learn. I just want my code to run on the iPhone, yet I have to learn a bunch of new terminology to ensure I understand what it entails, as well as their “meaning”. For example, MVC means something different to Objective C guys than it does to us. Yes, it’s subtle, but when they say it, it’s assumed you mean “their” version. It helps to know what the nomenclature of the Cocoa community is to learn, so first up, here’s some common terms.

Cocoa: The API you code in for the Mac. It’s like saying “Flex”; it’s all the things that fall under “Flex” like the compiler, the sdk, the ide, the runtime, etc. However, it’s a lot more than that. For example, there are Human Interface Guidelines that Apple puts out that Cocoa apps need to comply with (I don’t currently know how this is enforced, excluding iPhone/iPad). For the sake of this article, all you care about is “Foundation” and “UIKit”, 2 libraries that make up a lot of what people know of as Cocoa for iPhone. It’s also built on the MVC concepts we’re used to. The main difference is Cocoa is huge; it is a layer atop an OS, whereas Flex is a layer atop the Flash Player.

Objective C: C like programming language you code in that borrows some cool things from Smalltalk, similar to how we code in ActionScript. It’s from the 1980’s, and boy does it feel like it. Anytime I start coding, I have Megadeth on in the background, my Pontiac Firebird Trans Am in the driveway does a turbo boost, and Fletch watches over me, commenting how it’s all ball bearings these days.

Foundation: Provides all the low level stuff you need and shouldn’t have to write yourself. This includes data types like NSNumber (vs using int/float yourself), sockets, etc. Basically, if you can’t see it in a GUI, the class is here. Everything is prefixed with “NS” for NextStep, one of the companies responsible for the early development.

UIKit: All your GUI controls including support classes. Things like UIButton, UIAcceleration, etc. The UI prefix stands for User Interface (duh). You’ll hear about references to Application Kit; that’s the desktop version.

Core Data: Basically the model layer of your apps. This is actually kind of cool, and what we should have in Flex (I know of 2 people who have tried to create an open source one, and then shortly thereafter abandoned the project… too bad too). Right now, there are things like it in LiveCycle, I believe, but only Enterprises can afford that, so its’ not for “everyday use”. Basically, you create ValueObject’s, and they can be persisted in local XML or SQL databases automatically, vs. you having to manually write Factories, parsers, and versioning. Pimp.

Xcode: The IDE that you code Objective C in. You can build & debug your iPhone/iPad applications directly from here.

Interface Builder: The IDE that you use to visually build your GUI apps. You can actually create variable & method definitions here, wire them up visually, and then have it code gen the classes for you. It can also read your header files (imagine if every ActionScript class had an interface class associated with it that defined what it did). As a n00b, I’ve found it really easy to confuse this program and make it explode. Also, someone forgot to add tab order when they made it.

Objective C

Objective C is the programming language you write your applications in. It is effectively an extension to ANSI C with Object Oriented syntax. In Flash and Flex, you utilize ActionScript 3. Objective C has a lot in common with C and C++, and some of the lamesauce as well, namely pointers. Objective C also has multiple environs it can run on while ActionScript runs in just the Flash Player.

If you know ActionScript 3, you can read C, and thus Objective C. Like Java, the type definitions are on the left instead of right, but other than that, they are extremely similar. Like another article mentioned, if C didn’t have pointers, PHP and C would be nearly the exact same. Since Objective C has a lot in common with C, they too are similar.

If you’re coding Objective C for the iPhone/iPad, you don’t get Garbage Collection, and have to manually get rid of your variables/objects. Once you get used to the syntax, it’s almost the exact same as cleaning up your mess in ActionScript. In ActionScript, you set your Object references to null; in Objective C it’s called nil. More on that insanity later.

You can read more here about here.

Yes, you code in Objective C 2, not 1. 1 is even more lame than 2 (thankfully?).

Objective C Syntax: Methods

Objective C has a lot of the same things that ActionScript 3 has. They both use the same bracket syntax, and have the same cuddled vs. not wars. They both end lines with semi-colons. There isn’t as much dot syntax. They both have methods. Here’s how you invoke one in ActionScript:

mySound.setVolume();

Here’s how you invoke it in Objective C:

[mySound setVolume];

Notice in Objective C, they use brackets to indicate the containment of a method call. You can nest these as well, but they recommend you only go 2 deep since it becomes un-readable after that.

Here’s ActionScript storing a return value:

volume = mySound.getVolume();

Here’s Objective C doing the same:

volume = [mySound getVolume];

Passing in parameters is a little different and takes some getting used to. This, to me, is the same thing that threw me off in Ruby, and where Objective C totally ignores how C does it. Here’s ActionScript:

mySound.setVolume(value);

And here’s Objective C:

[mySound setVolume:value];

Ok, not so bad… except, the 1st parameter is always the only one WITHOUT a named parameter. Observe the following ActionScript 3 function with 2 parameters:

mySound.setLeftAndRightPan(left, right);

…and Objective C:

[mySound setLeftAndRightPan:left, rightValue:right]

Notice there is no “leftValue:left” here, just left. The first parameter is always nameless, yet every one after it has one. I guess they wanted more obvious parameters during function invocations… except forgot to build in one for the 1st parameter. *face palm*

For example, here’s an ActionScript 3 function definition:

private function setLeftAndRightPan(left:Number=0, right:Number=0):void

Here’s the equivalent Objective C:

- (void)setLeftAndRightPan:(NSNumber*)left, right:(NSNumber*)rightValue

Notice 4 important things. First, the return type is in the beginning and wrapped in paranethesis (void in this case). Second, notice that Objective C doesn’t allow for default values for function parameters like ActionScript. Third, notice the type definitions for the function parameters are in the left side vs. the right (in this case NSNumber). We’ll get to the asterisk later. Fourth, notice the dash in the very beginning. That signifies that this is an instance method on the class. If you want ActionScript’s static, use + instead.

Objective C Syntax: Variables

Variables are slightly different because Objective C has pointers as well of built-in helper methods to make memory management easier.

Here’s a variable in ActionScript, first defined using a String literal (pimp syntax) and the old school way:

private var name:String = "";
private var name:String = new String();

And here’s one in Objective C:

NSString* name = [NSString string];

There are a ton of caveats here. Notice we’re calling the string method on NSString; it’s basically a factory method to give us a string; similar to going new String(). When I did “” above, it’s called a String literal; the same as going {} vs. new Object(), or [] vs. new Array(). In ActionScript, each of those constructors has nice features, the effect is the same; you get a variable of that type back.

Notice the asterisk in the Objective C example. This means it’s a pointer to the String, not the actual String. Also notice since we’re calling the string method on the NSString class, it’s autoreleasing (similar to the Doom spell in Final Fantasy; it’ll die soon; ie he’ll get ejected from the Pool soon, more on that later). If you want the guy be like Number 1 and live forever instead of a Rico’s Roughneck, go:

NSString* name = [[NSString alloc] init]

Just keep in mind you have to manually call release on him later whereas the former, you don’t.

Objective C Syntax: Pointers & Memory Management

Variables are different because of a couple reasons. First, since Objective C is based on C, it has all the pointer baggage. We ActionScript Developers are spoiled because we don’t have do deal with this… or if we do, it requires little thought.

For example, in ActionScript, there are only 3 variable types that are by value, and thus don’t have pointers: Strings, Numbers, and Booleans. Yes, I’m including int and uint as Numbers here. Every other construct is an Object, and thus is passed by val. If you wish for an Object based variable to be removed from memory eventually, you need to ensure no more references exist, or in the case of circular references, that no one else knows about the circular relationship (the Mark and Sweeper from the Garbage Collector will get those mofos). For Numbers, Strings, and Booleans who aren’t local variables, you just remove their parent Object, and they’re toast. For local variables, they go away at the end of the function (usually… depends on how aggressive the Garbage Collector is at that moment in time).

For Objects, you just remove all references, usually by setting them to null, or in the case of dynamic Objects like Dictionary or Object hash maps, using the delete keyword.

Objective C’s iPhone runtime, and ActionScript’s Flash Player both operate using reference counting. This means, for Objects, an internal number is incremented for every person who “knows” about an Object. When that person later set’s his reference to null, that reference count goes down. When that reference count reaches 0, it’s eligible for Garbage Collection. The Flash Player also has a Mark and Sweep part to take care of circular references in the case where 2 Objects know about each other, yet no one knows in your app knows about them, and thus their reference count will never reach zero. If you’re running on the iPhone, you don’t have Garbage Collection, so need to call release yourself (which calls dealloc internally). In ActionScript, you’d either null the reference out, or call your own destroy method, THEN null reference out.

Objective C has this built in as a method called dealloc. You don’t call, it gets called for you when you (or someone else) calls release. In ActionScript, people will either use a convention of public function destroy, or those fu@#(* IDestroy marker interfaces that people NEVER implement fully (did I mention that’s annoying?).

In ActionScript, for a complex class, it may look something like this:

public function destroy():void
{
	if(timer)
	{
		timer.removeEventListener(TimerEvent.TIMER, onTick);
		timer.stop();
		timer = null;
	}

	if(icon)
		icon.bitmapData.dispose();
}

In Objective C, this is built-in to NSObject, one of the main classes you often extend. The Objective C version of the above would look like:

-(void)dealloc
{
   [timer release]
   [icon release]
   [super dealloc]
}

As learn about how getter/setters are built into Objective C, you’ll see there is a better, and more common way to do the above (article I link to at the bottom describes this), but I need to get the point across here that you’re expected to clean up your own mess since Garbage Collection doesn’t exist, and everything can’t be an autorelease variable.

No Local Variables, Hence Autorelease & T3h Pool

In ActionScript, we have local variables. Basically, instead of storing it in memory, it’s stored in temporary memory that the stack is using (the stack of functions currently running). When one stack item is done (your function is done), those variables are removed. In ActionScript’s case, this isn’t immediate, but basically ensures that no one has references to those variables anymore. Later, Garbage Collection will come along and eat’ em.

Objective C doesn’t have local variables. Yes, I know, I’m face palming as well.

*deep breath* There IS a common way to deal with it. Your first thought may be to create a bunch of member variables; basically what game developers do for simple Object Pooling. That’s ghetto, though. You may think you could just create variables on the fly… the problem with that is you have to manually release them, and for return values, they’ll die before they get returned.

This is where autorelease comes in. Remember before when I talked about the 2 ways to create variables? Let’s revisit it, and show again how you kill things.

This creates a variable you must manually remove:

NSString* name = [[NSString alloc] init];
[name release];

… and she’s dead. However, here’s one that’ll be added to a pool, or rather “a Pool”:

NSString* name = [NSString string];

This is the same as doing:

NSString* name = [[NSString alloc] init];
[name autorelease];

You can then safely return these variables from functions, knowing that the caller will get it. It’s also considered good practice to do, specifically for encapsulation. There isn’t really a language construct to say “Hey dude, this guy is going to send you a variable it also has a pointer to, so please make sure you call his release first”. Crap like that is insane; it’s just easier to get either copy’s of variables so you don’t inherit their pointer baggage, or use autorelease so you don’t piss off people getting variables from you, and causing leaks if they forget to kill you first.

Yes, all of that above is a shortened version of what you have to do because there are no local variables. Yes, I’m face palming again.

If you’re curious about what this Pool is, imagine if a static class was created every time you ran some code.. and Garbage Collection ran immediately when you null’ed out your variables. The first thing it did was keep a reference to any variable that has autorelease on it. Then, 1 frame after the stack has been complete (all your code has run, and the next enter frame runs), it kills all the variables it has stored. That’s the AS version of what an Objective C Pool is.

Conclusions

This sucks. I blame Adobe AND Macromedia for my suffering.

BTW, if you’re looking for some pimp tutorials to learn this stuff, my compadre Brian linked me to it, called “Cocoa Dev Central“, specifically this article.