AIR mobile and the mystery that awaits us!

Wonka river of chocolate

I started writing a lengthy comment in response to brother Kevin Suttle‘s very concise and well-written celebration post on the announcement of AIR for Android and Mobile. Please read that first here: http://kevinsuttle.com/2010/02/15/air-mobile-will-spark-the-era-of-contextual-applications/

In response to that post and many other announcements today, I have a lot of thoughts and questions I’d like to air out post. Before I get into this, I feel the need to state now that I love AIR. I’ve loved building AIR apps, coding with both CS4 and FlashBuilder. I am thrilled that Adobe is pushing this further into the mobile realm and hope the adoption skyrockets! I think it is the future of the Flash platform.

And now, some of my thoughts/questions and issues:

A. Aside from the use of a common language and platform in Flash, how can/will building AIR mobile apps be a unified advantage over building native apps on the device? As Ryan Stewart noted, “Depending on the device, you may want to make some small modifications, but you’ll be able to reuse your assets and a bulk of the code to quickly create cross-platform mobile applications with AIR mobile.” As we know some of the pave-over pitfalls of building AIR apps across Mac and Windows, there are some conditionals required to handle things like docking and alerts. My hope is that Adobe can continue to offer more seamless pave-over/common solutions that will let us tap into unique device platform features with a unified code approach.

B. It’s hard for me to envision how the same windowing, alert and docking functionality I’ve implemented in a desktop-based AIR app will appear/function on a mobile platform and smaller screen size. Assuming the mobile device/platform implementation of AIR supports this, will they work in a familiar way so the user knows how to handle them? Example: Twhirl. On Android, will the identical AIR app (if supported verbatim) actually load multiple windows for each of my Twitter accounts and lists? Will the app’s taskbar/docked icon (or mobile equivalent, if there is one) blink or bounce when I have a new tweet? Will a notification window popup over whatever app I’m using (or if/when I’m on a phone call) with new tweets? Hard stuff to imagine, but very exciting possibilities.

C. How will the AIR API proxy unique device functionalities like GPS, Accelerometer, orientation (landscape/portrait), touch/mult-touch, etc? Will we see separate classes for each, or something similar to the Flash Lite implementation of System.Capabilities.hasStylus? Furthermore, if I write such functionality into an app, will AIR ignore or intercept such calls if the same app is installed on a device without that functionality?

D. Most important (to me, anyway) of all, is the issue of distribution. There was an exchange earlier today between Ted and Scott about distribution and monetization. If AIR-built apps are to be listed in respective ‘app’ stores on different device platforms, will that require the developer to build/package the app for each device they wish to distribute too? Will there be a unified certificate or similar approach to protect source and assets from onedevice/store/platform to the next?

I’ve got more questions, but I’ll leave that for another post. Forgive me as I know the announcement is super fresh, and I’m sure many of these questions will be answered soon. My excitement has me desiring many answers and discussion now. If you have any thoughts or answers, similar or on other aspects, please post them and let’s get a dialogue going here. (Feel free to direct responses/comments to brother Kevin Suttle’s post.)

chuckstar

6 Comments

John Wilker

Technology issues aside, what I’m most interested in is monetization. Adobe typically has done a really poor job of helping, supporting and/or encouraging anyone to monetize the Flash platform. I really hope that changes.

I think the change also has to come from the community though, so who knows if we’ll stop shooting ourselves in the foot.

Great post Chuckstar!

Reply
AntonioHolguin

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 year cert), iPhone Dev certificates, who knows what Google will require for Android devices? I assume AIR dev cert would be fine.

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 Internet, 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.

Reply
Shashank Tiwari

Great post! I am a big AIR fan as well and have enjoyed building such apps. However, I have found that AIR (on the desktop itself) is notorious for its erratic behavior on Linux platforms and sometimes strange desire to become a resource hog. Unless, we are saying AIR 2.0 on mobile is a completely new small footprint super efficient runtime, I think the battle for serious applications is going to be an uphill task.

Reply
Arno Gourdol

Hi Chuck,

Great post, lots of good questions. Let me try to lift some of the mystery.

We are envisioning AIR as a runtime that can help you build three categories of applications:

– Simple Apps. Those applications work the same on both a desktop and mobile device. Typically they are going to be fairly simple applications, displaying all their content in a single, small window when running on the desktop. Many games will also belong in this category.

– Adaptive applications. These applications can be more sophisticated and adapt to the environment in which they run. For example a fairly simple, one screen layout when running on a small mobile device, more information visible on a larger tablet device, and multiple windows when running on the desktop.

– Complex applications. These applications will share the core code and functionality, but will have different user experiences on different platforms.

In general, when building an application for mobile devices, you’ll want to give special consideration to the physical display (size and pixel density), the input methods (keyboard vs. touch) and the general mode of interaction required (on the go vs. at the desk).

I presented a session at MAX detailing some of these issues: http://tv.adobe.com/watch/max-2009-develop/designing-flash-applications-for-the-iphone

With AIR, we provide you with a consistent API across mobile devices. So, you get a single API for geolocation, mulit-touch, gesture, accelerometer and screen orientation support. These APIs are always present and when invoked they will produce reasonable results. You can also check if the functionality is supported by checking the value of a “isSupported” property on the appropriate class.

Some APIs that are functioning on the desktop will not be functioning on mobile devices, for example mobile devices don’t support printing or multiple windows, so the corresponding classes will not be functioning (isSupported will return false for them). In all cases, however, the APIs will be present so you can build adaptive applications with a single code base.

As for distribution, we want to make sure that users will find (and pay for) your apps, just as they already do today with other mobile apps. So, apps built with Flash will be hosted in the mobile store appropriate for the platforms you target (Apple App Store, Android Marketplace, etc…). To submit these applications, you will need to follow the same process as for other applications, as appropriate for the store, including code signing.

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *