Anyways, let’s get right to it.

The ApplicationFinder ANE is something I created to help you find other Applications on your Android system. You can get information 2 ways.

isAppInstalled(package:String):PackageInfo

This method looks to see if a particular application (by app id) is installed. If the application is installed ApplicationFinder returns the name, package id, version number, and version name of the application. If the app isn’t installed you get null.

getInstalledApps():Array

This method just returns to you the entire list of installed apps. Go nuts, search and find what you need. Like the isAppInstalled you get the name, package id, version number, and version name of the application.

Later I’ll add things like also returning the app icon, possibly some app management methods (startup, shutdown, etc).

I’ve included my test app here so you can run it, and then the ANE also. Enjoy!

Test Application (FXP)
ApplicationFinder.ane

Thanks to Adobe AIR and Flex this process was extremely simple. Feel free to poke through if you have a Netflix account. This new version uses the newest versions of Flex and AIR.

Feel free to leave comments and let me know your thoughts.

Below are our slides, feel free to ask questions about the presentation.

This app is a “semi” playable version of the game we are creating tentatively called “Red Carpet Rumble”.

If you have an Android device you can use this link to get the game.

Disclaimer: By no means do we feel that this application is completely done. Yes, we have the full intention of continuing to work on this game and get it out. If you have comments feel free to let us know.

At the point of writing this I’m actually really happy with where Queue Manager has gone.
- Queue Manager has almost 50k users
- Queue Manager is listed highly in the Android Market
- Queue Manager is listed as the top Air for Android app on AppBrain
- Queue Manager is listed highly in AppAware
- Queue Manager is awaiting acceptance into the BlackBerry App World
- Android Central listed Queue Manager as a top pick in October and it was stated “it [Queue Manager] has proven to me the viability of Adobe Air as a development platform for Android”

All this success has not been due to my efforts though, I feel that my efforts have only hindered the application’s success rather than bolster it. I’m going to go through the things that I’ve done – or have been done to me – that have hurt Queue Manager and what I have done to fix my mistakes.

Some of these mistakes are embarrassing to admit, especially from a developer that has made multiple applications / products before, yet the old issues still creep up if you let them.

Releasing Too Early
This issue was due to my ego more than anything else. I wanted to have the first Air for Android application on the market and guess what? I did it. The second that Air was pushed to the market I followed right up with Queue Manager. What issues did this cause? You can assume and assume correctly that the initial release was buggy, feature depleted, and could have used some good ole’ optimization. In subsequent releases I fixed up these bugs but due to my buggy release I ended up on triage duty for the first week.

To Do Item(s):

• - Release when the app is ready, not based on some other date

Frequent Releases
Part of this issue was due to how far I needed to go to compete with other Netflix applications on the Android market, part of this issue was that I was trying to have a specific feature set out by Adobe Max, part of this issue was that I wasn’t testing thoroughly enough and had to constantly release bug fixes, and part of this issue was that every time I finished a feature I wanted it out to the market as fast as possible. All of these “parts” lead to one thing: upset users. While some users appreciated the frequent releases most told me that they would have preferred if they weren’t quite as frequent as I was making them. As time has gone on my releases have been less frequent as the amount of changes needed to the application have decreased. Along with that I have been testing more on my application prior to release – not just testing the feature that I worked on. Finally my app has grown to a very stable state so the bugs have been worked out over time.

I currently sit on releases a day or two just to feel good about them.

To Do Item(s):

• - Plan releases
• - Test throughly so that you’re not having to follow up a feature release with an immediate bug fix
• - Even if you have good code to release, spread it out and possibly merge feature releases

Work closely with your API provider
This has actually been one of my biggest problems and a problem I am completely helpless to – hopefully the app that you make isn’t dependent on a public API.

The issue is that Netflix provides me X amount of calls against their servers in one day. If Queue Manger gets featured somewhere or a bunch of people decide to use Queue Manager for an extended period of time and Queue Manager hits it’s Netflix limit then the application starts giving back an error from Netflix. Each time this has happened I have contacted Netflix and they have given me a bump in my limit, yet another few weeks pass by and I start hitting my limit again. I feel for my users, they just want an application that works, yet this is an area that I am completely hopeless.

When this happens I usually end up with a string of 1 star comments in my market reviews.

This is particularly bad when I put out a new release because everyone goes and plays with the app to see what has changed. A quarter of my user base could easily put me over my API limit.

To Do Item(s):

• - Give good feedback to the user
• - Limit calls to the server

Condense your trips
Mobile is great because it is on the go however you can quickly come across places that on the go doesn’t equal on the web. With this spotty service possibility even the smallest service call may take quite a long time to fully get back. I learned this the hard way with my initial release.

On my testing computer I received each service call I made almost instantly and the computer was quickly able to parse and visualize the data. When my users started working with my application the initial comments I got back were that they didn’t know if anything was going on. Even after adding visual loading indicators I had users complaining that the application was “sluggish” and the data was taking too long to get back.

This lead to another place for optimization and I spent some long nights working on reorganizing the service calls that I made to the Netflix service. This reduced the data that I was receiving from Netflix, sped up the application and especially the loading time. I still have users that say it takes to long, but eventually there is only so much that I can do about the network, their location, and their device.

To Do Item(s):

• - Give good feedback to the user
• - Reduce the amount of data you rely on

Double check your app id prior to release!
I thought that I would be the only person to hit this but alas my good friend FlashCanon also fell prey to this. Prior to releasing your app to the Android Market double check your app id in the application descriptor file and make sure you are perfectly happy with it BECAUSE YOU CAN’T CHANGE IT LATER! The name of the app, the programming, the colors, and basically everything else about your app can change between releases but your app id will stay the same and can’t be changed.

I know there are rumors that you can contact Google and ask them to help change your app id but I would recommend just getting this right from the beginning.

If you need to change the app id you will just have to put up a new application with the right id and get your users to reinstall the new app. Obviously you will lose the stats and whatever else from your initial release but you will get the id that you were wanting.

To Do Item(s):

• - Double check your application id!

Double check your application descriptor prior to every release
With every release you can remove your application from the Android Market based on the options that are in your application descriptor. There was about a two week period that I removed Queue Manager from the Marketplace because I updated my Flash Builder version and the application descriptor changed just slightly. This slight change altered the filtering options on my application and even my users couldn’t find the application in a search.

Always check your application descriptor and the application manifest. These details lead to filtering in the Android Market.

Now prior to every release I read through my application manifest, double check that the install location is set to auto, and that my user permissions are set properly.

To Do Item(s):

• - Double check your permissions
• - Make sure that the install location is set to auto for app2sd functionality
• - Ensure that your icons stay consistent between releases (and exist)

Have error tracking code
As I hinted at earlier there are many things that may go wrong with an application. The device may malfunction, the internet signal may fade, or – the most obvious – your code may break. Your users will probably be quick to tell you that your application sucks or has failed but be unclear as to what happened. As I am limited and don’t know what has happened on the server side (delivered by Netflix) I have an entire section of my application that I am unaware of any issues.

That being said I’ve had to construct an error tracking system within my application to give the users details as to what happened and ultimately deliver to me the error. All this extra work is very helpful to narrowing down the problem. As an added bonus, if you make error reporting very easy on your users they are more apt to sending you the generated error report.

To Do Item(s):

• - Give good feedback to the user
• - Make it easy for the user to submit bugs/issues

Have statistics gathering code
I love statistics gathering code because once I know what my users are doing on a statistical level I know where to focus my efforts for development. I’ve recently learned that my users do two things: search for titles and browse through new instant titles. That’s it. Knowing this I can focus my development practices around making sure that my application can do what my users want.

Where did I fail on this? Well I didn’t put in my tracking information till recently. If you are working on an application I recommend GA for Flash.

To Do Item(s):

• - Add in code to gather use statistics
• - Don’t gather more information than is necessary, this just will cause extra unneeded application chatter

Optimize Visuals
My good friend Dimi would be proud of me and all the work I did on the icons. Just for the record he designed most of the app and how it looked, I just pieced it all together. The issue was that some of the icons came out as “crunchy” (thanks Antonio).

I knew to not scale the images yet the icons still came out as “crunchy”.

One night I decided to sit down and figure out the problem, it didn’t take long. The icons that I was using was built at an odd size. Due to the odd size the device has having issues displaying the icon as the device also does some scaling of the icon. However when I rebuilt the icons with their size based on a power of 2 (specifically 36×36) the icon’s “crunchy” look went away and was smooth again.

To Do Item(s):

• - Look over all images, make sure they are a multiple of 2 (16×16, 36×36, etc)

Test on multiple screens
Testing on multiple devices is the bane of my existence. No matter how many devices I get my hands on there is always one more device that makes my app look just a little bit different and horrible at the same time. At a certain point you are going to need to decide for yourself how many devices is “good enough” and move forward.

I’d recommend testing on at least 3 different phones and 1 tablet. These different sizes and resolutions should help get most of the kinks out. When you see your app on these different resolutions and sizes you’ll probably realize the same two things that I did. Things that were “a bit” on the small size are unusable on some devices and things that “a bit” on the large size actually look okay.

For the most part I’ve been really happy with the look of my app across many devices. The Flex Team is doing a good job of keeping design stable across multiple screens.

To Do Item(s):

• - Get devices
• - Test on devices

Never accept “okay”
There are a few times that I’ve had to make the hard decision “I will cut a corner here so I can get this important bug fixed there”. I thought that my users wouldn’t notice and that they would be happy to get one bug fixed even if it meant that the update wasn’t very significant.

I was wrong.

My users did notice and they punished me for it. Users aren’t happy for incremental changes and they will comment and rate your application on two levels. The first is an overall score while the second is how much has the app improved from the last update. If the user doesn’t deem the update important enough you’ll get a nice 1-star rating for wasting their time with the update. Not nice but it is reality.

After seeing this phenomenon I’ve been very happy to rate applications that I enjoy with 5 stars, even if the updates seem trivial.

To Do Item(s):

• - Plan your updates
• - Realize that everything is significant and you can’t skip out anywhere

Accept that your users are going to destroy your app
This point was very interesting and something I didn’t expect. I had a user contact me that the app didn’t work for them. After a few more emails back and forth I couldn’t understand what the problem was and was left to just apologizing to the user. Then the user gave me a break through. He had a custom build of the Android OS that gave him a few extra abilities – including the ability to turn on and off permissions to applications.

Apparently he decided that my application didn’t need the ability to access the internet but was upset with me when the application couldn’t access the Netflix API.

The lesson? Sometimes there is nothing you can do.

To Do Item(s):

• - Accept defeat

Unit Test (where possible)
Don’t have to go far into this subject. Unit tests work, use them. Even if you think you’re a “good developer” they will help.

To Do Item(s):

• - Write your tests

Have a release checklist
This may not seem like very important but I’ve always found release checklists to be helpful. There were a few times in early releases that I didn’t follow any checklist and I accidentally left in debug information or my testing api key or a few other issues. All of these caused for some bad releases followed by an immediate secondary release followed by upset users.

I recommend writing a script for you to follow when you are making a release. Make sure all of your testing bits are in the script, any settings you have to change, and double check your application descriptor. Once your checklist is completed then make your release.

I originally didn’t do all this with my app as I considered it a “small” app and suspected I could remember all these steps off the cuff. I quickly learned that there is no such thing as a small app and every detail matters.

To Do Item(s):

• - Make a script
• - Follow your script each time

Include your contact information
Finally, give your users a way to contact you. I’ve found over the entire process that I have some very kind users and also some users that have great ideas and points for improvements. They appreciate that the ability to give feedback and contribute often. I receive roughly 10 emails a day from my users with ideas and requests.

To Do Item(s):

• - Include your contact information somewhere

In web and desktop development if something else happened on the user’s computer the user could simply switch windows to handle the interruption and continue their task. This happens so frequently that developers actually never think of this as a issue. However with mobile development there is always the chance of a phone call coming in, or email, or any other application that may take focus away from your application. While you application is not in immediate use you now fall prey to the operating system’s whim. If the OS decides that your application needs to close for memory or power reasons then the state of your application and any data it was holding may now be lost unless you have created an aggressive data persistance layer.

On top of that, the views within your application are created and destroyed quite frequently. That means if you were a developer that was used to grabbing data from offscreen or invisible views then your data will no longer be available when these other views are destroyed. Another reason why you need to be very aggressive about moving data into a proper data model and away from the view.

Getting into it let’s look at the PersistenceManager, what it is, and how we can alter it to do our bidding.

PersistenceManager
First off the PersistenceManager is a simple way to interact with an LSO (Local Shared Object). This is the default way to persist data across views and sessions. There are only a handful of functions to worry about to get use this class.

This makes it very easy to set and get data from the persistence layer.

Roll Your Own
Don’t like using LSOs? Prefer SQLite Databases or some other storage plan? No problem. You don’t have to roll your own completely if you don’t want to – though you could. You can still use the PersistenceManager, just make sure to use the interface: IPersistenceManager. The functions are all the same but now you can make your own and do whatever you want. This is a wonderful example of programming to an interface rather than an implementation.

While the simple functions provided by the IPersistenceManager may not be robust enough for your application then you can just completely write your own class. I prefer to stick to the provided interfaces because then other developers that help out don’t have to learn an entire new set of methods.

Looking at getting started with Flash Builder Burrito and the new Flex SDK? Check out this post on Flex Hero development.

Looking at getting going with non-Hero development or don’t have the new Flash Builder Burrito? Check out this post on getting started with Air for Android.

I created this app with Adobe’s Flex technology and Air for Android. I primarily test and develop on my Evo, but while at Adobe Max I was able to load my app onto the new Samsung Galaxy tablet. With 0 code changes the app just worked and looked really good.

You can find the Queue Manager application in the Android Marketplace right now.

Hero.. Slider… It is all Flex. And now a very optimized update to Flex that is specially created to work well on mobile devices. I’ve been rushing around the new framework additions to put together an app that shows off the new features and can be helpful. You can check out the app I made here: Queue Manager.

Let’s get started with the new mobile development options…

Everything I am writing about is available with the new “Burrito” Flash Builder releases given out at Adobe Max 2010.

Starting Up New Application
Once working with the new version of Flash Builder you will see some new options that weren’t available with earlier. The main difference from earlier Flash Builder releases is the addition of mobile projects, specifically: Flex Mobile Project and Actionscript Mobile Project.

I’m not going to go over the Actionscript Mobile Project as it is pretty easy to understand. You start right from scratch and can develop anything you want.

Flex Mobile Projects are different as there are many classes that Adobe has created to make your application development easier. We are going to start with the 3 different ways to start up your application: Mobile Application and TabbedMobileApplication.

MobileApplication
The first option you have is MobileApplication. This is the entrance point for your mobile application setting up your Actionbar and Navigator and firstView.

The Actionbar is more of convenience class than anything else. This is the bar on the top of your application with 3 distinct sections that you can use for navigation, action and title properties. Many mobile applications use this facility to help the user navigate the application and Adobe has set this up for you. You can also choose to hide the Actionbar or change how it overlays your application.

The Navigator is similar to a ViewStack. This is your main view manager that you can pop and push views onto in an array format. With each view pushed onto the stack or popped off you can have nearly limitless application navigation paths. This is your main way to handle different views.

The firstView is your application’s starting point – the initial view to push onto the stack. Later you can “reroot” your application by popping off all the views and set a new root view.

TabbedMobileApplication
The TabbedMobileApplication is similar to the MobileApplication except rather than having one navigator you have many. And each navigator has it’s own tab in the main TabBar connected to the application. With the TabbedMobileApplication you set up an array of ViewNavigators and determine each ViewNavigator‘s firstView.

Like normal Flex development with the TabBar the label field determines the label that will be shown on the TabBar.

By clicking on the Buttons created automatically with the TabbedMobileApplication, the user can switch between stacks. You will still want to store the visual data away from the view for safe keeping.

This sets up the basis for you application development.

Pushing and Popping Views
Once you have your firstView set and running the rest of the application is going to fall right into place. When you want to move to the next view you just need to “push” on a new view. This is done with the following code.

The data is an untyped object and anything you want to be available in the data property in the new view. This is a very easy way to pass data back and forth between views and helps maintain state.

If the user hits the back button the navigator will automatically do a pop for you – unless you event.preventDefault();. You can also do this programmatically by just calling the pop function.

If at any time you want to “rehome” your application and reset it’s view stack just pop all the views off and set the new view. This is helpful if you want to forget the history when someone hits the home button or after some complicated steps that you may not want your user going back to mess up.

Or you can go back to the original home and remove all the history by using another convenience function popToFirstView.

By default you get the slide to the left transition for all of these functions, but if you wanted to create your own transition or just have something different for your transition, each of these functions have a transition property that you can set for when the effect needs to play.

Performance Hints
Before you run off and start building all your amazing application there are a few things I’d like to pass on that I learned while creating Queue Manager.

Don’t do any work during transitions, you’ll slow down the transitions.
I seriously mean don’t do ANY work. I was sending off a call for data and that’s it and even that slowed down my application. No more hiding how long it takes to load data behind slick transitions.

Don’t forget the loading indicator.
Right now there is no way to show the user that your app is doing work. Make sure to program in a loading indicator to let them know something is going on.
I’ve been told in later releases Adobe will provide some helper for this.

Don’t set properties on the Actionbar till the transition is complete.
This is mainly an Max Preview Release bug. But if you do your Actionbar transition won’t finish and your view will look jacked.

Use your Splash Screen to hide the application loading
One way to make it seem that your app comes up quickly is to use the splashScreen property on the application. This just takes a normal image and stretches it over your screen. If you wanted to be really slick you could make it look like your home screen and hide how long it takes to come up.

Check your sessionCachingEnabled
Adobe has already programmed in a lot of session caching information into the Flex application. However their implementation may not work for you and your app. It didn’t work for my app. If this is the case and you want to ensure you aren’t caching data that shouldn’t be cached then make sure to turn your sessionCachingEnabled to false.

Roll your own session caching
The persistance manager by default uses shared object, however if you want to use local databases or some other persistance management technique then all you need to do is use the persistance manager interface and roll your own.

Cache Often
When working with mobile devices remember that at any moment your application can be interrupted. In the past you may have been lazy about storing user input as they are entering in the data but now that is more important than ever. Each keydown and text change needs to be stored so that if a call comes in and stops the process, you can still have the user’s info just in case the application was shut down.

Close your application
Users expect at certain times that when they back or home out of your application that the application should be completely closed and shouldn’t be taking any resources. Yet at other times they expect that they can skip away and check a text and then come back to the app the way they left it. This is up to you and your application, just be aware of when you should close your application and when you should leave it running.

Close your application with:

Watch your Activate and Deactivate Events
When you application’s view gets activated or deactivated from the OS due to user input you may want to set or cache some data. I would watch for these events from each of your views and respond appropriately.

Actionscript Skins
Unless you are dealing with the most simple skins, it’s best to keep them all Actionscript. No MXML yet.

Not all components are Mobile Optimized yet
Flash Builder will even give you ASDoc hints as to components that have been Mobile optimized or not. Watch for these hints as some components will not work well as they aren’t optimized – others just won’t work at all.

Text Fields
In your skins make sure to use the MobileTextField rather than RichTextField or others that don’t say “Mobile”. If you do use one of these non-mobile textfields you will not get any information from your textfield. Trust me on this, it’s annoying and not obvious!

If you are curious why I created this app then the answer is simple. I wanted to make an easier way for me to manage my Netflix queue. I am a Netflix fanatic and am constantly working with my queue.

Current State
If you are wondering if I feel the app is complete then the answer is NO! This is a work in progress and I hope you keep updating as I continue to make the app better. Right now I am trying to get through the bare minimum requirements, as I see them. Such as:
- viewing queues
- updating queues
- add/remove/view movies
- update movies queue positions

Donation Link
Like this app? Feel all warm and fuzzy and would like to fund a developer for his hard work? Use this link:

Planned updates
- Social connections
- Gesture support
- Search filtering
- Bluray support

Release Notes
I will keep this page going as a place for people to post comments and requests and a place for me to keep version update details. This way I can keep transparent as to my progress and you can see if your request is complete.

v1.0.0 – Initial Release
Basic queue viewing

v1.0.1 – Visual Change
-Updated browse to search as Netflix doesn’t provide category browse api

v1.0.10 – Queue Change
- Paging added to Disc/Instant Queues
- Updated Netflix API to allow Disc/Instant Queue Paging
- Bug fixes
- Loading bar added for visual feedback
- Updated closing the app when backing out of Main Menu
- Updated closing the app on logout

v1.0.12 – New API Key Added
- Changed API key for higher daily rates

v1.0.13 – Requests Fulfilled
- Menu closes when focus away from menu
- Added Release Notes link in App Credits

v1.0.14 – Performance Release
- Updated title load order
- small noticeable performance increase
- transitions are smoother

v1.0.15 – Performance Release
- Reduced title calls by 1/5th.

v1.0.20 – Queue Management Release
- Reorder Disc Queue
- Reorder Instant Queue
- Menus go away on option selection
- Fixed Disc removal bug
- Fixed Queue update bug

v1.0.24 – Bug Release
- added opt-in error emails to me
- quick rerun error calls
- upped font sizes
- added scrollers in some places

v1.0.25 – Bug Release
- remove title bug fix

v1.0.31 – Browsing Addition
- fixed add disc bug
- added browsing support with subcategories

v1.0.32 – Browsing Addition
- browse by genre from title details
- browse similar titles from title details

v1.0.33 – Bug Release
- null pointer error for missing directors/casts/etc now handled gracefully

v1.0.36 – Bug Release
- working to fix specific user’s droid authentication issue
- fixed bug with adding and removing sessions. Loading indicator remained even though service was complete.

v1.0.37 – Visual Release
- moved paging buttons on screen, not behind menu
- updated timestamp code
- changed url encoding code

v1.0.38
- bug fix – timestamp fix for authentication
- visual fix – update to full lists not being visible
- feature – browse now allows x levels
- feature – added top level “new” dvd/instant/bluray
- added tag showing this was made with Adobe Flex Technology

v1.0.39 – Immediate Bug Fix
- fix – found null pointer error introduced in 1.0.31

v1.1.0 – Horizontal Lists
- App2sd now available
- Horizontal Lists
- Format Availability in lists
- Larger Coverart
- Cleaned up loading and splash screens
- Faster Login Process

v1.1.1 – Bug Fixes
- Fixed front page misspelling – I’m not a writer, I’m a programer
- Fixed browse bug that resets to first page on backing into titles list

v1.1.3 – Bug Fixes
- Horizontal list search selection bug fix
- architecture change (non-noticeable change)
- error logging fix for email errors
- instant/disc queue layout bug fix

v1.1.4 – Additional Development
- Added additional fault checks
- Fixed up main menu to be laid out a bit better
- horizontal similars list
- rearchitecture complete, all views simplified
- if an instant title will be removed within 3 months, the list view will give you this warning of removal date

v1.1.5 – Bug Fixes
- Performance fix for typing in search box
- bug fix for switching layouts causing improper sizing
- layout change for larger screens (tablet devices)
- bug fix for empty horizontal lists

v1.1.6 – Framework Upgrade

v1.1.7 – Bug Fix
- fixed bug stopping app from showing in the marketplace

v1.1.8 – Bug Fix
- fixed multiword search bug

v1.1.16
- fixing failed login issues
- updated icons
- bug fixes
- performance fixes

Donation Link
Like this app? Feel all warm and fuzzy and would like to fund a developer for his hard work? Use this link:

Known Bugs
- Phones not releasing Oauth Tokens effecting Logout. This is due to a Netflix logout bug.

If you are reading this then you probably follow my blog and have seen my series on Air for Android features. With each feature I’ve included all the code and explanations as to how to use the feature. If you missed the presentation and you’ve gone through my entire series then you’ve done my hands-on.

Below is the full list of links to my presentation’s many parts for getting started with your Air for Android development environment.
Setting up your Air for Android Environment
Hello World in Flash Professional with Air for Android
Hello World in Flash Builder with Air for Android
Managing your Air for Android Environment
Optimization Techniques for Air for Android

Feature Examples:
Geolocation
Accelerometer
HTML Web View
Home, Menu, Back, and Search buttons
Gestures
Screen Orientation
Text Messages, Emails, and Phone Calls
Camera and Camera Roll Access
Microphone Access

Also here is the Prezi presentation that I used at 360|Flex.

And finally the full project for download, including all the source code and ant build files.

You can also check out the “see” tag in each application to refer to the original post and the applications have the appropriate comments.

If you have any questions about these files don’t be afraid to ask.