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.

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

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

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

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.

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.

Just quickly throwing this out. This week 2 examples of the Netflix AS3 API were added to Tour De Flex. These two examples show off some basic service calls and authentication. Hope this helps others if they are wanting to create an application with Netflix/Video information.

Here on this blog you will see some more examples coming shortly and hopefully a few working apps using different popular Flex frameworks. If you have any questions feel free to ask.

You can also see the announcement here.

Let’s put it together.

The View
As with each of these framework examples I start with the same exact view.

Which produces…

PureMVC Application

Time to start those engines… soon
One bit of annoyance that I have with PureMVC is the MASSIVE amount setup, basically we have to build the engine before we can start the car… a large complex engine. So let’s start building…

The Application Facade
The Application Facade is your starting point and main singleton object that is your connection to all of your models and mediators. As important as this sounds the Application Facade is actually a very simple starting point and it’s main job is to start up the application. My Application Facade is as follows:

As you can see the Application Facade registers the startup command and waits for the startup function to be called. The real magic is what happens when this startup command is called, the entire application comes to life, the listeners are all registered, proxies are created, and the view is prepped for user interaction. How does this work exactly?

Application StartUp Diagram

Application Startup Command

Model Prep Command

View Prep Command

Views and Mediators
What is interesting about PureMVC is how the view is disconnected from the machine itself and run via events sent to mediators. Mediators hold references to the views that they control, sends/receives notifications from the rest of the application, and finally listens for events from their connected view to send notifications and execute methods. This separation of view and controller is paramount to proper MVC development and keeps your views clean of logic.

When putting together your mediators it is easiest if you keep to a process for the layout of your mediator.

1. Create your Mediator Class

This will create:

Honestly, there are many other functions that are created, but these are the basic ones that you need to get going.

2. Next, name your mediator by adding a constant variable that we typically label “NAME”.

3. Add in local references to proxies that this mediator will need access to…

Then add notifications that the mediator has interest in…

Next add in some code to handle the notifications that the mediator is listening to…

The rest of the code that you need to add will be the listeners and methods needed to run the view. You can view my final Application Mediator. This mediator controls the main Application view file. You will see that I prefer to have references to my view’s components as getters in my mediator.

Remember on of the main principals of application development: KISS. Mediators usually keep a 1 to 1 ratio with views, so when you are naming your mediators keep your view’s name in the mediator, this will keep it easy to see which mediators are attached to which view. Example: Application.mxml :: ApplicationMediator.as

Proxies
Proxies are your data centers of the application and act as stand ins for your data. This is really nice because you won’t have the issue of data not being available, causing wonderful runtime “null” pointer errors.

Again, let’s follow a process and put together our proxy.

1. Create the class

This proxy we are setting up to handle a service call, that is why we included the IResponder interface (which provides us access to the result and fault methods). We also make sure to name our proxy with a NAME constant so we can access it later through the retrieveProxy method. Our current class looks as follows:

Our proxy will need a method to call the service and a getter to retrieve access to the proxy’s data. Our changed proxy looks as follows:

To complete the proxy we need to add in a delegate (more on delegates next) to actually make the service call in the load method, then add in the logic for our result/fault methods, and finally return the data in the data getter function. One thing to remember is that proxies include a data property to actually store the data that the proxy represents, so when you retrieve/set/access data, store that data in your proxy’s data property. Finally send out notifications to our engine that lets the rest of the application know that our service has received a result/fault.

The final proxy is here.

Our Service Connection, the Delegate
Delegates are simple classes that hold a reference to the responder class that they will respond to (that is why our proxy implements the IResponder interface), a service reference, and methods that will actually connect with the service. Below is my AutocompleteDelegate. Usually I try to keep one delegate per service. Many services will include multiple methods, so my delegate will have one method per service method. Some people also like to have one delegate per service method, the choice is yours.

Back to the view
We have now outlined all the parts to the PureMVC framework setup, now we just need to see how the view connects to your new beautiful machine.

Start your engines!
Now when your application starts up the framework is waiting for one command to get going:

With this startup method called your engine is running and you are ready to go!

Final Application
This is the final PureMVC Example and the source.

PureMVC Application

Below is the Flex 3 application that I will be making using Mate, it should look very similar to the cairngorm application made in the last blog post and will serve as the basic design for each of our applications.

I am going to try to refrain from making Cairngorm references but will say that both workflows feel very similar.
event > event collector > executing code > return/fault handlers > data storage

Mate Application

Bubbling Events
What makes the Mate framework “magic” is the fact that Mate relies on Dependency Injection and Flex Event Bubbling. What does this mean for you? This means that anywhere in your Flex application, fire off the event and the event will be picked up by your designated “EventMap” as it bubbles upwards from your subcomponent and then the result will automatically be injected into your view.

What is really nice about the Mate framework (and what every Mate developer will say first as a Mate strength) is that the Mate framework’s events are actually just Flash Events. Nothing special, nothing framework added, just a regular Flash Event.

The designated “EventMap” will then handle the event as it has been instructed, run a function, a service call, or whatever your application needs. In the case of our application we send off service calls, this is handled by Mate as such:

This code will accept the AutocompleteEvent event and call for the AutocompleteService service loader.

Big Note! If you aren’t using a straight httpservice or remoteobject Mate will require some Mate specific programming. The next code segment will show you the file necessary to transform your custom event to a Mate acceptable event.

package com.unitedmindset.extensions
{
    import com.asfusion.mate.actionLists.IScope;
    import com.asfusion.mate.actions.AbstractServiceInvoker;
    import com.asfusion.mate.actions.IAction;
    import com.netflix.webapis.catalog.TitlesService;
    import com.netflix.webapis.catalog.params.CatalogParams;
    import com.netflix.webapis.events.NetflixFaultEvent;
    import com.netflix.webapis.events.NetflixResultEvent;
    import com.unitedmindset.events.AutocompleteEvent;

    public class AutocompleteServiceLoader extends AbstractServiceInvoker implements IAction
    {
        private var service:TitlesService;
        public var term:String;

        public function AutocompleteServiceLoader()
        {
            service = new TitlesService();
            currentInstance = this;
        }

        override protected function run(scope:IScope):void
        {
            innerHandlersDispatcher = service;

            if(resultHandlers && resultHandlers.length>0){
                createInnerHandlers(scope,NetflixResultEvent.RESULT,resultHandlers);
            }

            if(faultHandlers && faultHandlers.length>0){
                createInnerHandlers(scope,NetflixFaultEvent.FAULT,faultHandlers);
            }

            var params:CatalogParams = new CatalogParams();
            var e:AutocompleteEvent = scope.event as AutocompleteEvent;
            params.term = e.term;
            service.autoCompleteService(params);
        }

    }
}

Can I get a Manager over here?
With our event being fired off (from anywhere in our application), the Event Map has now received the call and taken action – in this case, gone to get the service. Now we need to do something with the return. This is where we deal with our data, Managers.

Managers work by having a set of functions to receive the set data from a service or other function. The manager with do the work it needs to accomplish and wrap itself up. Basically, managers “manage” your application’s data.

Injection what?
Dependency injection in it’s most simple form should remind you of data binding. You set a variable that is plugged into a listener, when that variable is set, it triggers and sets another variable somewhere else in your application. Where are these variables? In Mate, within your managers usually. Where can you set a variable, anywhere else in your application. This is a very helpful construct that simplifies how data moves around your application. An injector example is provided below.

With all of our code put together in the Mate framework you can now see that we have a Mate application that acts exactly the same as our Cairngorm application. The file downloads and source are provided below.

Mate Application