开发者

Android SDK vs. Adobe AIR: Pros and cons?

Has anybody blogged about this comparison, or does anyone want to give it a shot here? Would be nice to see some reasoned thoughts on Adobe AIR on Android开发者_运维百科 vs. the "native" Android SDK (in Java).

Edit: Despite few views and no answers, I'm leaving this question up here since it's a topic that needs to be covered at some point... but if it gets no attention I'll delete it in a few days.


I think it's ultimately very similar to the question of whether to use AIR or Java for a desktop application. Ultimately it comes down to three points:

  1. Does AIR do everything you need? Obviously the android SDK gives you complete access to device capabilities, but AIR purposely doesn't, in order to stay portable. For example, AIR may not support intents, at least initially (I don't think Adobe has announced yet one way or the other). Also, AIR requires Android 2.2. If those limitations are troublesome, regular android SDK may be best.

  2. Are you looking to make something that would be well-suited to doing in Flash? If you're planning a design-heavy app with animations, video, sound, or the like, then building it in Flash may be significantly easier than using Java. On the other hand, if your app will be pure code using only standard visual components, then it might not make a lick of difference which platform you use. Or on the gripping hand, if you'd have existing Flash animations or the like, then trying to shoehorn them into a Java app will be bothersome.

  3. Are you targeting other platforms besides Android? If so, AIR may be a big win, as the same app content should run on windows, mac, linux, and later on, other devices that plan to support AIR, like Blackberry, some TVs, blu-ray disc players, etc. If you are only targeting Android, AIR may lose some of its appeal.

I hope that helps some. Realistically, unless you're effectively locked out of using AIR because you need something it doesn't give you, or effectively locked into using AIR because you're doing design-heavy work and you need the tooling, then I think the pros and cons of the two SDKs are largely questions of convenience. Either platform will work, so it's merely which will get you to the finish line the fastest and most reliably.


One issue to consider is compatibility with Android devices. Both fancy smart phones and cheap phones run in Android, but they don't have the same capabilities. Even if you application is simple or can be done beautifully in AIR, its relevant to mention that AIR is not compatible to all Android devices.

Some very popular devices currently sold (such as Samsung ACE and other "cheap" devices) use ArmV6 chips, and AIR or Flash are not compatible to this architectures, even when running on Android 2.2 or so.

AIR is interesting because same development works in different technologies, but consider that AIR doesn't run on "old" iPhones either, its only guarantied to work on new technology with big processors.

Check this Adobe link http://www.adobe.com/flashplatform/certified_devices/

AIR should be ruled out in your decision of technology if in your requirements you are targeting as much phones as possible, including those that are not so fancy or new.


I have experience with AIR mostly and little with Android SDK when I was building a native extension to AIR. My biggest hurdle with AIR is it's immaturity, it's bugs, and it's inconsistent behavior. Yes, you can go to the shiny page at adobe.com and see how cool is the AIR... All bright with tons of features which seems to cover all your needs. Yet, once you start building your app you'll find many ugly surprises:

  1. Stage text in not working appropriately. link besides this bug StageText has few other bugs, like behavior in Scroller for instance.

  2. Sound() object doesn't play the stream (it does on emulator only). link

  3. Lack of features like AEC makes AIR useless to whole list of chat applications, as you'll will hear echo and screaming noise. link

  4. Overloaded (and immature for mobile) Flex SDK (I hope folks at Apache will rewrite it from 0 and make it more manageable).

  5. No H264 support on iOS devices: link (yes, I know it's Apple problem, that they want to control HD delivery on their platform, still it's Adobe problem too, as they couldn't fight right to bring their technology to forefront).

  6. Sound object doesn't take variable bidrate (only 44.1KHz is possible). Flash "second generation" Speex codec samples at 16Khz. Now, try playing this back through Sound and you'll enjoy a funny circus. At the end you will need to write your own upsample algorithm.

I'm sure people will add more to this list. So, my answer would be native SDK is more preferable for anything serious. You won't work like a QA person with it - testing countless little examples trying to understand why an AIR feature not working, shuffling internet for answers and looking at AIR bug database... only to find that critical bugs are sitting there from release to release. That is my experience with AIR. Going native SDK makes your application not really "cross-platform", but AIR SDK can't claim this title anyway for anything more serious then couple of "Employee directory" examples. And if you will need to build for the other platform, you will just use native tools for it.

GL.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜