As Ethan Evans kicked off AnDevCon 2012 this morning in San Francisco, California, attendees were given the chance to hear first hand from Ethan, the Director of App Developer Services at Amazon.com, about all of the key development mistakes that were made as Amazon developed their Appstore for Android and Fire.

And of course, when we talk about mistakes, what we’re really talking about are lessons that are learned from working hard, down in the trenches of Android application development. And what are some of the best practices we can pull out of the lessons learned through Amazon’s development process?

Lessons learned the hard way

Stick with one WebView is one lesson. Apparently Amazon initially played with multiple views, but the performance hit was terrible. Delivering a UI through a single WebView meant solving new problems, like how to get the back button to work properly, but the performance gained from using a single WebView justified the extra effort to figure out how to empower users to jump back a page or two.

And in fact, most of these lessons learned fell into the category of performance tuning. “People want a quick start” when they are accessing your mobile application, says Ethan. “People don’t want to wait as though it is a video game that is loading.” 

What's old is new again

Splitting IO bound and storage bound processes into separate threads that could run in parallel on multi-core devices was another strategy used to shave milliseconds off the response time of their Android store app.  Caching was another common strategy used for accelerating the mobile experience, although not every team at Amazon could agree on which caching mechanism was most effective, and which caching mechanism was the most sensible to use. But then again, why should the application architects at Amazon agree on these things when nobody else in the industry can come to an agreement on it either.

Smoke and mirrors performance tuning

Of course, some of the improvements were less technical and more about smoke and mirrors. Amazon found that providing visual cues about the progress of files that were downloading or images that were slow to render created a feeling that the application was loading faster when in fact, the performance remained the same. Even if the application was a bit choppy in how it loaded, creating the illusion of fluidity made the experience more enjoyable for the end user.

It's amazing how so often in this industry that what is old becomes new again. Caching, multi-threading and providing pertinent user feedback aren’t revolutionary ideas. It’s just that when the programming model shifts like it has towards mobile device development, a developer isn’t expecting the problems that went away ten years ago when users shifted away from 28 baud modems to rear their ugly heads again. But regardless of whether it's a new idea or something that's tested and true, it's worth reiterating if it helps new developers avoid some of the pitfalls that even the seasoned veterans working at Amazon fell into.