If you are interested in learning about Mobile Applications I will be giving a the first half of a 2 part lab in conjunction with Asfusion!

We will start with the application basics and go as far as using custom Native Extensions and Density Aware skins. It’s quite a learning event.

If you haven’t signed up for Adobe Max, do it now!

Make sure to sign up for the labs, they are filling up very quickly!
(First Presentation) Lab, Tuesday at 8am
(Second Presentation) Lab, Wednesday at 4pm

The same content will be shown at each of these labs. The 2nd half presentation presented by Asfusion hasn’t had it’s times set yet, keep watching out for it!

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.

Check out the Adobe Edge article I wrote!

Coming up in March Dedo Inc. will be presenting on going multi-screen at SXSW. Christian Cantrell of Adobe, Andre Charland of Nitobi (PhoneGap), along with Danny Dura of Dedo Inc., Mark Miller of Dedo Inc. and myself will be showing off different techniques and platforms of how to go multi-screen.

In April, I will be presenting along with Antonio Holguin at 360Flex on Mobile development techniques. We’ve developed a slick game for mobile devices and will be discussing every part of it’s creation, from initial idea to release. This presentation will be very important to you and any group you are working with that may be planning to go mobile soon. This will also allow you time to ask us questions as you prepare for your new project. Antonio will be focusing on the design aspect of new mobile development and I will be focusing on the developer side of mobile development.

I am highly anticipating March and April!

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’ll say now, the Samsung Galaxy Tablet is a keeper.

There have been some scathing reviews of the Galaxy tablet but for my needs I’m very happy with the tablet as a lightweight productivity device. When I first thought of the iPad – before ole Stevie actually announced it – this is what I thought of as a device. Cameras, Geolocation, Accelerometer, connections to the entire internet, lots of good apps, and a device I can program for. Based on that list Stevie has failed on multiple points.

I will say that I’ve spent time with the iPad and liked it – I’m not completely jaded. I just didn’t see any point to buy it due to many shortcomings at the hardware level. Software can be updated – with incomplete hardware you’re stuck and the iPad was incomplete. I know iPad round 2 will have cameras but the system will still be unfriendly to me as a developer and for that I’m still looking to Android based devices.

Physical Specs
You can find the exact specs online in a million places but here are the specs as I felt them.

The size of the tablet is awesome. It fits in most of the pockets of my backpack and I can easily hold it securely in one hand. I say this because the larger size of the iPad makes it so you really can’t put an entire hand around it. So if something were to slip… crash. I’m paranoid like that though. The size makes it also so you can turn the device into portrait view and type with two hands like a big phone. This is a big performance improvement over other larger tablets.

The weight of the device is great. It isn’t so light that you’d forget it was a piece of hardware when moving things around on your desk yet it isn’t so heavy that you’ll get tired using it with just one hand. On top of that the device feels solid, seriously solid. I’m not terribly worried about it breaking on me while I give it a toss to the couch.

Maybe it’s just me but the 4 android buttons are causing me troubles. That is probably because the Evo that I use everyday is set in a different order – which feels more logical to me. Basically I keep hitting home when I go for what I think is menu and vice versa. It’s nit-picky but something that keeps annoying me.

Peripherals
Many people have bashed on the device for it’s camera quality and I have to agree. The camera has great quality, but I’d like it to be a bit more – especially since my Evo has a higher quality than the tablet. However if you look at a specific competitor: 2 cameras > 0 cameras.

I ran a few different applications on it to test multitouch, accelerometer, and GPS capabilities and all of these had stellar capabilities. The multitouch was spot on without dropped or switched touch points even with many touch points running, the accelerometer was spot on and the GPS was very accurate.

One thing that many people laugh at is the fact that the Samsung tablet actually has phone capabilities built in – especially when they put the device to the side of their head and laugh at how stupid it seems. Try adding a bluetooth headset to your device and you’re good to go.

Battery Life
The battery life is beyond amazing! I have gotten to the point on my Evo that I have to charge it twice a day to keep continual use. It’s a fact that I have come to accept and often just let my phone die off in the evening hours. Now working with the Samsung tablet I am amazed that I played with it for multiple hours on the first evening and didn’t even reach half way on my power. Without powering down and with moderate to heavy use it was nearly 3 days before I even had to plug it in for power. This made me very happy.

Added Software
I’m not talking about the software added by Tmobile here, that needs to just be uninstalled and let me enjoy my device. I’m talking about the tablet specific software that was created to maximize the larger screen size usage. Yes all your favorite Android apps are there and they look really nice, but now there are new productivity apps that use the larger size. If you are used to the iPad you will notice lots of similarities to the larger apps provided with the iPad. My only complaint is that there aren’t more apps like this provided for the Tablet. The ones that are there are great, now we just need more.

Games
I played a few games on the tablet and they all ran so smoothly that they were fun again – yes I’m talking about a few racing games and Angry Birds. They all worked well, the performance of the running app was slick on the device, and the larger screen size made it so I could enjoy the details that may have been lost previously on smaller screen sizes.

Overall Thoughts
The coolest things that I didn’t even think about trying was figured out by Danny in the office. He was packing his pockets for a meeting and he just threw the tablet into his coat pocket after also sticking it into his pants pocket. Pocket test passed.

Ultimately the issue comes down to what are you intending to do with your tablet. For some the screen size will just inhibit your workflow too much – like a programmer on a small laptop screen. But if you are needing something very mobile with more power and productivity than your standard smartphone – this tablet is made for you.

And regret the decision to not show up to Adobe Max 2010 you should!

I’ve been going to Max for a few years and this was the best one by far. Only since my first Max have I been so excited to pop out of my bed after a long night of “networking” and make it for the early morning sessions. This year the sessions were spot on, the technology was new and exciting, summit was great, and the keynotes were memorable – and of course the networking is the best you’ll ever have.

Sessions
To all the speakers presentations that I saw, GREAT JOB. Ryan Frishberg, Hans Muller, Sebastian Marketsmueller, Jason San Jose, Renaun, Chiedo, Deepa, and Grant Skinner.

There were a few other sessions I attended that didn’t have videos but when you go to Max make sure to find sessions lead by the actual senior developer of the product. These are the sessions that will blow you away beyond belief. This year Adobe really showed off how smart some of the people are that work at the highest (and deepest) levels of the Flash Player. Seeing this level of knowledge really grew my confidence in the platform.

New Technology
New technology abound this year! Tablets, mobile devices, phones, tvs and all these devices ready to run in the device lounge at Adobe Max. I personally went around and installed my Queue Manager on every device I could get my hands on. This was such a learning experience and also so much fun to see how well my application responded on a variety of devices. For anyone that has an app or just wanted to see the difference between the different devices this was a great time to do it.

I was also one of the lucky one’s to sign up for the Air for TV labs that got to walk away with an AIR development box for my tv. People walking around with these boxes became the envy of other conference goers. I’m currently working on my first Air for TV app due to what I learned at Max.

Summit
For those that don’t know Summit is an event for community managers, this includes User Group Managers and Adobe Community Professionals. I’m not going to go too far into it but Rachel, Liz, Tammy, Aaron and all the other Community Leaders did a great job bringing all of us together.

If you want to join in at Summit next year I would recommend starting a user group in your area or if you feel like you are ready for it, join the few and become an Adobe Community Professional.

Keynotes
Let’s not kid ourselves, the keynotes caused the hate mail and texts mainly because of the droid2 and google tv giveaways. And I am very thankful for them!

Last year was Flash Catalyst and Flex 4, this year was all about technology and AIR. Adobe did a great job showing off all the places that AIR is available now. Developers everywhere can easily now develop for so many different devices and screens that are reach is limitless. I’d actually say that this is the first year that the Open Screen Project has proved it’s worth.

For designers, this year displayed the new tools and how easy it is to create amazing creations targeting a variety of playforms – sans developer.

The Keynotes can be found here.

Networking
Finally, the best reason to come to Max is for the networking. If this was your first year at Max (or you are thinking about next year) just find out what hotel everyone is going to and go there. You don’t have to be a drinker to join (thought it helps) but just come and hang out. I’ve never seen a larger group of people that are as open as the Adobe community. Quickly you will be swapping stories of projects long gone, tech headaches, and how William Shatner seemed way too confused and way too cool at the same time.

Usually I would add a big section about the Max Bash and talk about how cool it was but this year it wasn’t. It was nice don’t get me wrong – the Max Bash just didn’t blow my socks off. Basically this year they had a giant tent with food and a band that only true music lovers would know of. It was nice to walk around and talk to friends but pretty quickly we left to go find a place to sit and a bartender to attend to us.

Overall I’d say that this Max was one of the best I’ve been to in a while. I know that I’m going to Max next year…

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.