AIR 2 – Going Native!

-

Friday, June 18th, 2010

Wahoo!  AIR 2.0.2 and Flash Player 10.1 have officially been released.  These two releases have been a long time coming.

The AIR 2 update makes AIR a much more viable option as a desktop software platform.

Flash 10.1 seems like it is actually a whole new beginning for Flash because it has been cut up, optimized, and expanded on a ton.  Exciting times in the Flash world.

With so much going on with the new releases and the cool features they have (multi-touch/gesture, mobile, networking, etc) it is easy to over look the Native Process.  I definitely overlooked it when I was looking at the AIR 2 Beta 1 release notes.  But since then I have been playing with Native Process in a few different projects.  And it is FAST!  In one project, Flex is calling a shell script and receiving/parsing 200k + line items in … oh around 10 SECONDS!

So lets take a look at an examples of what I am talking about and a stumbling block that I came upon.

Example 1 – AIR to Shell Commands

For the last two years I have learned to love my favorite Application on my Mac — Terminal.  I love it because it is so powerful, and already has so much functionality built into it.  And even if it doesn’t do something, there is probably a Linux or OSX user out there that has created a script to do just what I am looking for.  So being able to tap into shell commands directly is… well…really cool and opens up a lot of possibilities.

A great example of this is already pre-baked and packaged for us by Adobe.  SearchCentral is an app that uses some native file listing and shell commands to search for files on your computer.  Not a revolutionary app — it basically just mimics Spotlight.  But it does show some good examples of how to interact with a Native Process.  If you want to tinker with NativeProcesses, that is the place to start.

The Stumbling Block – Chunked Up Data

A major issue came along when AIR started requesting large data sets over Standard In/Out.  The issues is that the system only sends a chuck of data at a time.  And this chunk may not be a complete object, line item, or whatever you are sending.  For example, if we have a response with 300 characters, maybe only 200 of those will get put into the output.  If so, the last one hundred will come across on the next event cycle.  How do we know if we have a complete object?  The solution I found was to separate each object with a defined separator and hold onto data until we have its full data-load.  To you networking guru’s this may sound very familiar, because it is the same concept as packet splitting on the OSI layer.  Here is a simple way to handle this “chunked up” data on a STANDARD_OUTPUT_DATA event handler:

private function onOutput(e:ProgressEvent):void {
	// Read our bytes from the native process into the buffer
	np.standardOutput.readBytes(processBuffer, processBuffer.length);
 
	// Keep a remainingOutput class variable for orphaned data
	// append that to a temp holder and clear remainingOutput
	var tempOutput:String = remainingOutput + new String(processBuffer);
	remainingOutput = "";
 
	// Orphaned data + whats new in our buffer
	var l:Number = tempOutput.length;
 
	// Look for our bufferSeperator class variable's last index in out output
	var lastIndex:Number = tempOutput.lastIndexOf(bufferSeperator) + bufferSeperator.length;
 
	// If the end of our buffer doesn't end on the end of our current buffer string
	// then we have some orphaned data that we need to hold onto
	if(lastIndex != tempOutput.length) {
 
		// Grab the orphaned data
		remainingOutput = tempOutput.slice(lastIndex + 1);
 
		// Grab everything before the orphaned data
		tempOutput = tempOutput.slice(0, tempOutput.lastIndexOf(bufferSeperator) + 1);
	}
 
	// Clear out our buffer so we don't get an overflow
	processBuffer.clear();
 
	// the tempOutput var is our final set of data that includes any previously
	// orphaned data and the rest of what we could find in this latest buffer
	// load.  So we can dispatch out an event or set a var to keep track of this
	// tmpOutput; // Do something with this
}

In conclusion, AIR 2.0 is awesome. And Native Process, while not as sexy as some of the other new features, is a game changer for what AIR Developers can build!

Why an iPhone developer should consider Android development

-

Tuesday, June 15th, 2010

Google and its cadre of device manufacturers are doing an amazing job at establishing Android as a major smartphone platform. In addition to new possibilities created by the addition of the Flash Player, Google’s free open source tools (that use an established programming language) make the barrier for entry lower than developing for iOS. Most importantly Android is set to catch up with iOS device sales this year making Android’s market bigger thus enlarging the pool of potential customers.

The Ubiquity of Java

Building your app for Android might be easier than you think. For one, Android apps are built in Java which has become a ubiquitous language for server side web development, embedded systems programming and cross platform application building on the desktop. Most developers have done a bit of Java if they learned to program at college. You can pick it up fairly quickly if you are familiar with Object Oriented principles. In the case that you need a resource to port your app, there are many Java developers that may be lured into mobile development. Additionally, the APIs are well documented on Android and there is a growing corpus of material for beginners. From a technical perspective Android devices support the same media formats as iPhone and OpenGL (if you happen to need realtime 3d rendering).

A More Open Place to Sell Your App

The Android Marketplace has fewer restrictions than Apple’s App store. There are still rules but you won’t find anything remotely like the App Store EULA that has sent waves through the industry and turned many potential developers off to the idea of making an app for iOS.

If you want to use a 3rd party library you may, as long as the license for that library permits you to include it in your app. You can use 3rd party tools to help you build your application. This is something of a gray area now with the Apple App Store. Apple is mainly targeting Adobe with this move but I don’t see how they could selectively enforce it and not have a lawsuit on their hands.

Additionally, with Android, you aren’t tied down as to the type or amount of analytics you can collect in your app. In the name of making privacy a bit more transparent Apple has introduced a few extra guidelines. This is probably good but it restricts the kind of data you can get. Additionally if the user declines to send you data you will receive no stats about their usage.

Android’s Market Catch-Up

This is perhaps the newest reason to develop for Android is market share. Within the last 6 months Android sales have taken off. Credit Google for continuing fast-paced development of the OS. Credit Motorola and Verizon for pimping the Droid. Take into account the extra carriers that carry Android devices, the extra manufacturers making Android devices and those factors are obviously at play as well. The biggest reason to develop apps for Android over the next year is market share. The Android market is growing faster than iOS.

Drawbacks

Having presented the case for porting an app to Android there are still plenty of caveats. Currently the Android marketplace has more piracy than the iPhone market. This is because its easy to ask for refunds on app purchases and you can restore the returned app from a backup.

Another “gotcha” for developers is market fragmentation. Google has done a good job of making the Android OS open and documented. This doesn’t mean that the carriers or device manufacturers aren’t muddying things up with their poor implementation or customizations. Large portions of the market haven’t updated from version 1.5 of the OS. The latest stable available from most manufacturers is 2.1. If you are lucky enough to have a Nexus One (blessed with Google’s right hand) you can run Froyo (2.2) and get all of the latest features and speed improvements.

Fragmentation is a legitimate reason to not develop on Android. If you are making a game or some other significantly complex application, the extra effort to get it to run on multiple devices could be too costly. Several articles have been written about Android’s market fragmentation recently and I find it alarming that Google seems lax about dealing with the problem. For now its up to app developers to handle poor implementations of Android on certain devices. Maintaining many branches of code for compatibility’s sake can be debilitating for a one-man-show or a small development team (especially if these developers are looking to maintain their product on 2 different platforms). This is a problem that involves multiple actors to resolve. Handset manufacturers are tasked with releasing the updates, but the carriers have their hand in it too. The result is endlessly delayed updates or potentially being orphaned with an old version of Android if the manufacturer/carrier decide to get lazy.

Another problem with Android used to be speed. Java has a reputation of being slow (too slow to use for game development). Google improved performance for Android devices markedly with Android 2.2 (aka Froyo). The new version includes a rebuilt JIT that executes much more efficiently. Performance is in some cases 2-5x faster than 2.1 according to Google. This is great news for developers that want to make games for Android; but yet again they have to consider market fragmentation. If there isn’t enough hardware with the right capabilities to run the game developers are unlikely to recoup their development costs.

Conclusion

Each developer will have to weigh the costs of developing for Android. There are a number of reasons to port your app to Android but the biggest reason is that the market is growing. There is less competition so its the perfect time to stake your place as a premier Android application.

GitX: The Git GUI for the Mac

-

Monday, May 17th, 2010

Before you get too far into this quick intro, I highly recommend knowing Git well from the command-line facet of the application. A GUI is terribly helpful for oft-used tasks, but it hides the goings on well, and certain things will be confusing unless you’ve run them from the command line.

Having said that, I’m falling in love with a new Mac tool called GitX. GitX is a native Mac app meant for Git repository management and workflow. While the main project can be downloaded here, I heartily recommend snagging Brotherbard’s experimental GitX fork here.

Brotherbard’s experimental fork adds a number of killer features to the already-great GitX setup:

• Greatly enhanced sidebar & source view.
• Remote operations: fetch, push, pull, add remote, clone, and clone to. It works well with multiple remotes, allowing you to push local branches out to different remotes.
• Commit operations: merging, cherry-picks, and rebases
• Diff: You can show the diffs between branches and HEAD and specific commits and HEAD
• File browser selections now persist between commits

Check it out and you won’t be disappointed.

Queue ‘N Cache 360|Flex Slides

-

Friday, April 23rd, 2010

As promised, below you can find the source code and slides from my Queue N Cache presentation from the 360|Flex conference. For those who were there, thanks for coming. I really enjoy learning with you all and being able to share when I can.

First, the sample application for queuing and caching. Keep in mind that images loaded into the application will be cached in the browser, so depending on what you’re wanting to test you may need to clear your browser cache between tests. Right-click the application to access the source.

Second, the presentation slides. Here they are as a “slidecast” but they’re a little different than the live ones. I think the live video will be made available shortly so if you’re looking for that check back later. Also, this slidecast was made through SlideShare and their audio-syncing tool is a little limiting so the audio might get unsynced for a moment. In any case, enjoy!

Slides from 360 Flex presentation

-

Friday, April 2nd, 2010

Here are my slides from my 360 Flex presentation, “Golden Nuggets: Finding and Keeping Top Developers.”

Best of luck in building your own dream team.