After writing this very lengthy comment on Brother Chuck Freeman’s (@ChuckStar) blog post responding to Brother Kevin Suttle’s (@kevinSuttle) excelent blog post regarding AIR and Mobile devices, I thought I should really post here on my own blog and #keeptheblogchainalive as Kevin says. There are a great deal of questions regarding AIR and Mobile devices, and I have had a few rolling around in my brain for some time. Be sure to read Kevin’s post then Chuck’s post, and you’ll get all the context.

Brother Chuck,

First, these are all great questions. Some may be able to be answered now, while with others we will definitely need to get a hold of all the tools to really know.

Now, I can only state what I have found and nothing more. I am not an authority on the matter, and . So I’ll try to answer as best as possible, and probably ask some more questions.

A.
Native apps will always have an upper hand to any 3rd party API created apps. Let’s face it, Objective-C will have a better handle on iPhone dev then will Adobe’s Packager. ADT’s Java will be much better equipped to deal with Android apps than will AIR. *But* I’m a Flash designer. I know Flash. I love Flash. AIR will help me use my current skills to work on applications for iPhone, Android, etc. Which is great. If I really need to create a native app for whatever reason, I would look to work with someone who knows that particular language. But in the mean time, if I need to create an app “cross-platform” – without spiking budget too much higher – then AIR would (hopefully) be a very viable solution.

B.
This is indeed difficult to imagine as we just don’t have the devices and tools in hand to really test this fully. It’s unfortunate, but we’ll most likely have to stumble around a bit in the first leg of the road. There are just too many differences between platforms and a lot of unknowns. But I do agree: Exciting.

C. What I’ve learned with this so far is that devs will need to use some kind of conditional. For instance:

if(MultiTouch.supportsTouchEvents)
{
// Use Touch Events
} else if(!MultiTouch.supportsTouchEvents)
{
// Use Mouse Events
}

or something similar for each device functionality. (I’m not a real dev.) Fortunately, using API like Accelerometer, orientation, multitouch, gestures, camera roll, etc, all look like they perform the same (or close to) on all devices. The downside is that the conditionals and writing for different devices’ functionality will take a TON of extra time. But probably not more than having to create 2,3,4 or more different native apps.

There probably will be some functionality that works on one device differently than others. Then there is trouble as testing and fixing bugs will become a head ache. Take MultiTouch for example. Currently, unless you’ve gotten the OS update, the Nexus One and Droid don’t support MultiTouch, but MT is supported on the iPhone. This goes back to the conditionals, of course, but what if you need to use 5 touch points – like on the iPhone – and the Nexus only ends up using 3? Are you going to write separate code for the Nexus or use that as the “lowest common denominator?” UGH, such a pain.

D. Distribution? Now you’re opening a-whole-nother can of worms. AIR app certificates (starting at $400-500 for a two one year cert), iPhone Dev certificates, who knows what Google will require for Android devices? I assume AIR dev cert would be fine. But put it all together, and that is a BUTTTON of money, especially for small studios or sole devs/designers.

From what I’ve seen on Lee Brimelow’s iPhone Packager demo is that you should be able to hit Publish once for AIR app (or multiple AIR apps with the same cert. You can actually build as many apps on one cert as you want within the life of the cert), then again for iPhone app, all within 5 clicks or less. That should be easy. But how will that really go over with Google, Apple, PCs and Macs? Will it really be that easy. We’ll see.

Monetization is a HUGE hurdle. How do you get people to purchase your app if the common user expects that anything they get from the internet be free? This is especially problematic with desktop apps. iPhone and Android apps may have a marketplace each, but what if the user wants the desktop app? Are they going to freak when they see they have to pay for it there too? Will a user be able to buy once and use it across all platforms for no additional charge?

Now a few other questions that have been bugging me since finding out about the iPhone Packager and 10.1 last year.

1. Are clients going to expect that it is easy to just build an online version, an AIR app for mobile, an AIR app for Desktop, and an iPhone app all the same time? What are they going to say when we as devs and designers have to tell them that its not as easy as Adobe markets it? Then what are they going to say when we have to tell them they need to fork over all the money for certificates and distribution? Then are they going to expect it to all be done in the same timeline?

2. What about design? Much of what I have read in the past several days has been focused on code and development. But I’m “technically” a designer. All the different screen sizes are getting more and more difficult to keep track of.

They are not all the same, and it does NOT take just a couple minor “tweaks” to layout to make the same design work from the Nexus to Desktop to iPhone. Ok, maybe desktop apps could really repurpose the same size because they’re larger. But does that mean a designer will need to start at the most important size – the highest most targeted device – and work from there? Or will we designers need to create a different design from device to device?

The Nexus is 800×480, the iPhone is 480×320. Thats a large difference in appearance. Physical size is close to each other, but a button at 100 pixels by 100 pixels on the iPhone is not the same physical size as on the Nexus. That is a TON of work recreating, resizing, and reworking design.

The iPhone’s screen resolution is terrible compared to the Nexus or Droid. This also plays a difference in design. There are some things a designer can get away with on the Nexus that they just cant on the iPhone, and vis-versa. (See the difference between a HD TV and one that isn’t.)

What about a designer’s tendency to want to have some awesome interactivity? Interactions just DO NOT work the same on handheld touch screen devices as it does on keyboard/mouse controlled desktops. Plus animations, rollovers, buttons, etc DO NOT work the same nor perform the same across devices. Just about any part of DisneyChannel.com will absolutely have the same level of “fun” interactivity on the Nexus as it will on the desktop (ok so this isn’t an AIR app, but the point still stands). So, no, design will NOT be translatable from device to device and will take a LOT of extra designer time to retrofit for each.

3. My biggest fear/worry is the user. Will users think that they should experience the same app on their desktop as on their phones? Are they going to be angry when it’s not? Will this drive my users away from the apps I build? Is there going to be an uproar from our not-so-tech-savvy counterparts? After all they are our audience, they are who we really make apps, games, sites for. But are they really going to understand there is such a large difference between handheld devices and theyre laptop? Or are they going to be blinded by “One Web, Any Device?”

(I love that slogan by the way, and am not trying to degrade or otherwise speak ill of Adobe because of it.)

I want to create the best possible experience for my users as I possibly can no matter what device they are using. And I really do see AIR as a great solution to do so.

If you have any more questions, comments, concerns, insights or anything else to say, feel free to post here, or on Chuck’s post or Kevin’s post – I’m sure they’d love to hear your feedback as well.

Tags: AIR, Android, Flash, Flash AIR, Flash Player, FP 10.1, Mobile