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:
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.
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.
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:
Stage text in not working appropriately. link besides this bug StageText has few other bugs, like behavior in Scroller for instance.
Sound() object doesn't play the stream (it does on emulator only). link
Lack of features like AEC makes AIR useless to whole list of chat applications, as you'll will hear echo and screaming noise. link
Overloaded (and immature for mobile) Flex SDK (I hope folks at Apache will rewrite it from 0 and make it more manageable).
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).
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.
Related
I need to develop application that has a lot of sliding graphics and 3d animations for showing pictures representing products in a very interactive and fancy manner.
Here is a sample of what I'm trying to do http://www.youtube.com/watch?v=ZKCAPSzgoHM&feature=related
I heared that adobe air can do the job perfectly, is that true ? the application is not just sliding of course, it will connect to a server, synchronize some data, log information and so on
So, what is the best solution to accomplish this task?
Short answer, Yep it can. and yep it's true.
Long answer, since AIR3.2 stage3d was introduced to the air platform. Now AIR (as the flash player does) can takes advance of the gpu to render complex 3d content.
Molehill is the new codename of the 3d framework for AS3, you for sure find lot of material on it.
What i suggest you more is using a library/framework built above Molehill (that is indeed just a set of primitives with a low level style syntax). Flare3d, Starling (for 2d), Away3d (4.0 or above) are just few names.
Using this libraries will allow you to fast develop what you had in mind.
All the other tasks you mentioned (connection , log, sync) are pretty easy to do on air.
Now downside of choosing the AIR platform for mobile development on android. Since the introduction of the 3d is pretty recent, it is hard to say exactly the devices supported and the devices that simply fallback to the common 3d rendering system (that is cpu hogging, so not a good choice for mobile).
If you aim to target last generation devices you'll be pretty ok, and you'll find in AIR + flash platform tools a strong benefit in terms of development speed.
Hey,
I'm writing a simple game based on my physics engine for Android (in Java). Because I want to play with some special graphic effects performance is very important for me.
I read on the Internet that you can write an application in ActionScript3 and then just export it as an iPhone/iPad or Android application. That means, I wouldn't have to rewrite everything from Java to Objective-C if I wanted to make version also for iPhone.
Do you have any experience with writing games in ActionScript3 for both Android and iPhone/iPad? Are there any significant advantages / disadvantages?
I have made games with both AndEngine and air for android. Air for android is vastly slower. If you game needs performance, Air 2.6 - the current release - will not be able to handle it.
AIR 2.6 can handle simple games. One with a little performance to spare.
I am hopeful that AIR 2.7 (in beta now) will improve things, since it supports OpenGL. But for now I would have to say stay away from AIR for performance games.
To see an example of a simple game made with AIR, check out this one made my a friend of mine:
http://www.appbrain.com/app/kibble-katchers-free/air.com.munchiegames.KibbleCatchersFree
It plays OK, but chugs sometimes if you have a lot of things going on at once.
If your game is going to be more intensive than that, pass on AIR.
In my experience, it's always better to write applications in the native language for the device. Of course, depending on the scale of your game, the advantages may not matter. When using Flash to export to iOS, you are limited to what you can access on the phone (like UI widgets and features like accessing the camera). I've also read that Adobe is not going to include this feature in future versions of the Creative Suite. So you may lose support for your game. In my opinion, there are better tools to develop for both devices. Check out Corona or Unity.
MY impression is no, not a good idea until they get the performance up. Though this post makes it look pretty decent. Ive done an app for the playbook, and the simulator rendered it just fine, but once I saw it on the actual device it was pretty slow. I didn't realize there was a scroll box already there, and I made my own implementation with on enter frame listener and it was pretty slow.
If you're going for an iOS, then you end up with bigger file sizes. So while flash/as3 is great for prototyping and some simple applications, I would suggest using lower level language that doesn't have to be reinterpreted.
Perhaps the AndEngine could be something for you. It's a 2D Game Engine for Android and it supports physics. I played a little bit with it and it's really powerful but simple to use.
Performance is great, but think also about your game success in audience coverage - the flash is easy on web embedding. The flash is platform and its VM continuously enhanced due performance needs as well as mobile hardware. Try to write once and for all as possible)
Can anyone give a comparative information between developing Android mobile applications using Eclipse SDK and Adobe AIR?
Kindly share your opinion, anyone who has already having any experience on developing Android mobile applications using Adobe AIR.
I have gone through articles on developing Adobe AIR but wanted to know if anyone found it useful. I am aware that Android mobile applications developed using Adobe AIR is supported for Android 2.1 and 2.2.
Thanks in advance.
I will do my best to answer your question, though it's a little broad (if you could provide specifics on the information you need, I'd be happy to add more detail).
Firstly, there's a ton of information both from Adobe and from the Flash/Flex community on developing for AIR for Android. You can develop for AIR for Android using Flash and the Flash IDE or using Flex and the Flash Builder IDE currently in public preview on Adobe Labs (you can do straight ActionScript as well if you like).
One of the benefits of using AIR is that you can leverage your existing skillset in Flash/Flex/ActionScript rather than having to learn a new language. Another benefit is that yu can reuse code for existing Flash/Flex/AIR applications you may have built. Another benefit, and the one Sheikh mentions above is that Adobe is working on making AIR a cross-platform mobile runtime. If you search you will already find articles from Adobe and the community about people running AIR applications on the Playbook (the simulator anyway, since the device isn't released yet) and even using the preview Packager for iPhone to compile their applications to iPhone.
Although I haven't worked with AIR, but what I feel AIR is for, is cross compatibility.
Its like you're not building for Android, you're building for AIR. and since Android supports AIR, your applications will run on Android device.
In future more Mobile OS will start supporting AIR, so if you code an app for AIR, there will be a huge possibility that your same code runs on different platforms like Android, Windows Phone 7, iPhone (perhaps :-P). Thus, it will be saving a lot of coding effort for coders.
I have discovered that the cross-platform compatibility for AIR applications is quite good except for a few caveats:
1) User input boxes. They are generally not handled well in AIR applications. The popup keyboard can hide the input box, which it generally does not do with native JAVA apps for Android.
2) Real-time games. AIR for Mobile is SLOW. You may be disappointed if you try to develop any sort of real-time software.
3) Socket communication. This is my current peeve. I created a simple chat application in Flash and did some speed tests. This is in preparation for creating multi-player games for mobile devices. On the PC, the application can run over 200 messages per second to the server and get responses. On the AIR for Mobile, both on the iPhone and Android, it is about 11 messages per second max - and the app is doing nothing BUT sending and receiving the data strings. Add a layer of game play and the speed limitations could be crippling. This means real-time games may suffer if you need faster communications. It's plenty fast enough for turn-based or games that don't require lots of updates.
Basically, the cross-platform compatibility is nice. Just think about whether your particular project might be harmed by the speed issues as well as potentially poor handling of user input boxes. Do some testing.
I am pondering the idea of a Wine-ish compatibility layer on Android.
The idea is to run Symbian apps on it as both OSes share ARM hardware.
I have no knowledge of Symbian but I think that given the hardware capabilities of Android devices this could be done with less effort than Wine's windows emulation.
What would be the most significant difference to overcome in this emulator? (threading, storage, ...)
The real problem is not going to be code execution, but the API's to do things like graphics, interact with hardware, accept input, etc. If you have documentation of the original and android has the capability, API translation layers would be possible.
But android's security model outright prevents a number of things that are possible on other phone platforms, and combined with it's "java apis only" allows only inefficient means of doing things that can be done more efficiently on others.
This is of course all about application-level emulation/api translation. If you are willing to modify the android platform itself, supporting just about anything else for which you have documentation (and licensing?) within the hardware capability of the device should be possible.
Hardware capabilities of a device have nothing to do with complexity of an emulator to be hosted. It depends on Symbian's design and complexity.
And, even more, licencing. Even if one could make a Symbian emulator for Android, its legality would be questioned.
It's difficult to answer your question in detail, but since Symbian is open sourced (and Android too), if you've got the time, it shouldn't be too hard to see what sets them apart.
QT is used for the latest symbian OS, and has been ported to Android, you could write apps in QT build for each platform
the problem for writing an emulatir are variouss.
If the Symbian apps are written in in an interpreter language like Basic or similar then an emulator couldn't be too difficult to write. I did such stuff once to make the same code run on linux and windows, and I used a translation API for all calles coming from the software directed to UI, input/output.
I wound guess that the UI capabilities of Symbian are a subset of the Android functions so it would be not too difficult to write a WINE alike thing or an interpreter that runs the Symbian code on different hardware - IF it is only in high language.
But be aware there could be some machine code in the appps and that is processor specific. Most of the Android tabs nowadays run on Tegra, Tegra2 or (soon) on Tegra3, some may run on StrongArm or Arm, some may run on Intel Atom (x86 architechture), so this might get more or less impossible if the CPU isn't binary compatible like ARM / ATOM. Then you need to emulate the CPU as well and that might eat so much performance that you need a 4-5 times stronger machine to run that stuff smoothly.
It won't be too difficult to crack Android to execute Linux-alike binaries, but for sure this "mod" will affect the ability to use or download stuff from regular appstores.
With some apps you might have even more headache, e.G. my MP3 player from Korea runs on Strongarm, but it also executes Flash games from various sources. When there is no Flash player - and Google announced something like dropping support for Adobe Flash - it won't be usable.
The "most wanted" is obviously the Ovi Maps, probably that stuff could be easily converted to another app having offline navigation capability :-) People wrote "Gaia" some years ago, an open source viewer for Google Earth (and later forced to give up) so it can't bee too difficult to realize at least this.
I have been developing for Android since some time now and I found Java as proper way of doing development in it. But, now there are number of options available for developing in Android such as Titanium, PhoneGap and Adobe AIR.
The question is who will come as a winner for Android development. I have read lot of comparisons between Titanium, PhoneGap and native Android development. Now, with Adobe entering into it too, what is the future of Android Developers who develop with Java as the programming language.
Since, if one can develop for Iphone and Android with Titanium and Adobe AIR then why will one want to waste time and money for separate development.
The biggest reason I can think of is that using the native language/libraries of the platform (in this case iPhone or Android) is that it will allow you to provide a user interface/experience that is more in line with what the system designers intended over what will likely be possible with something like Adobe AIR.
That doesn't necessarily mean that AIR is bad, or that you might not be able to develop a good application, but since you'd be targeting multiple platforms with the same application code, and each platform has it's own subtle (or major) differences that you can't always account for, you will inevitably be forced to take a "least common denominator" approach to building an application that will run on all of your target platforms and behave consistently across them as well. This might not sit well with some users who expect a certain level of capability as you may not give them a consistent user experience compared to other native applications.
This is a long-standing issue with cross-platform application development -- the design philosophies and behavior of each system are intentionally different (otherwise why would anyone use them?), so your bound to run into problems making an application work 100% the same across them all.
As someone that has done cross-platform development in the past, I can say that while you can do it well in some cases, and using something like Adobe AIR might be a good avenue towards getting more familiar with a particular platform, but a lot of times it's just more prudent to buckle down and build an app using a system's native libraries/languages over a cross-platform solution.
It is quite simple actually. Developing an Android application using Java (the normal APIs) will allow you to a) target possibly all Android devices as all share the same base API and b) it won't put limitations on your application (or at least no limitations with the only limitation being the API).
Now PhoneGap, Titanium and Senza are all web-based frameworks which have certain limitations. You can't access certain functions of your phone as they simply are not some kind of replacement API it's just a framework.
Now Adobe AIR is another story. I'm not sure what functional limitations Adobe AIR will have but I know that there is quite a limitation when it comes to what devices you can target. There are some minimum requirements for Adobe AIR to operate which are
Android Device Requirements for Adobe
AIR
Google Android 2.2 Operating system
ARMv7-A Processor OpenGL ES2.0 H.264 &
AAC H/W Decoders 256 MB of RAM
Which means you can target devices with earlier API versions.
Titanium compiles to native platform controls, but you must to use web languages like HTML and js to develop your application.
With special version for each platform you can design UI following system guidelines.
There seems to be an overall confusion regarding what Titanium is... It compiles to native platform controls.
The majority of the respondents have incorrectly stated that it is web based and that is not true.
However, that is true when it comes to phoneGap