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.