Learn from my mobile mistakes

This blog post could also be “how to lower your stars in the marketplace”. I say this because now looking back at having an application in the marketplace for a few months I see many places that I have screwed up and things that I could do much better next time.

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