I am an experienced Flex and Air Developer and love Android having owned a G1, a milestone (Droid), a Nexus One, a Galaxy S and now a Nexus S. Understandably I am interested in developing Flex applications for Android.
I have just started working through the flex for android in 90 mins tutorial here:
http://coenraets.org/flexandroid90/FlexAndroid90Minutes.pdf
The very first step says that I have to create a Flex Mobile Project.
I was under the impression that the whole point of Air is that the same application could run on many different platforms. I was intending on creating an air app with different skins that could be swapped in and out depending on the platform it was running on. This seems to imply that I will have to compile my Air app once for desktop and once for mobile.
This isn't the end of the world but it's not quite how I expected it to work. I suppose that if I am creating mobile specific skins then I may as well create a mobile specific app.
Is it possible to create one Air app that will run on both mobile and desktop? Is this a good idea?
I don't think it is a good idea to write one app for the desktop and for mobile. The views are very different, and the user experience is very different.
Ultimately, this is one of those cases where separated presentation patterns really helps you. You can write all of your app and behavior separated from your view but slap a different view (desktop or mobile) on top of it for the right experience on the right platform.
Check out MVC, MVP or Presentation Model for different approaches, if you are not familiar.
Its a common problem, in the Java world we had the whole Java SE/EE/ME with JME being for mobile devices. Even the newest phones, some of which have, or soon will have, multiple cores are still much more limited devices than desktop/laptops. The overhead is just too great for the standard libraries, too much ram and cpu needed to load and run those libraries. So we have Flex Mobile, JME engines, and our Android favorite Dalvek.
Related
I am an experienced Apple developer who is looking to develop for Android. I do not currently own any Android devices, so I am considering purchasing a B&N Nook HD for development purposes, which now runs Android. From the research I've done, it seems that the spectrum of Android devices is quite varied and disorganized compared to the Apple world (no offense intended). So, my question is, even though there are better (more expensive, too) devices to purchase (Nexus tablets), will a Nook HD suffice for beginning Android development? By the way, my intentions are to develop mostly tablet utilities with emphasis on networking and data manipulation. I'm not really interested in hardware-specific areas like graphics and sensory input (with the exception of the touchscreen, of course). Thank you for your advice.
In a general sense, yes. Your device will do just fine. However, a caveat is that you must take into consideration the flavor of android you are planning to target. e.g. Working on a Froyo flavor won't necessary guarantee it will run on the latest Jellybean and so on.
Hell, I started developing android almost 2 years ago (but stopped indefinitely) but it was only this year that I took it upon myself to get a PHYSICAL android device when I continued to develop my app. For no particular reason I just dropped by the local gadget mall and randomly picked the Samsung Tab 3. Yes, reviews are bad and it kernel panics a lot but these are trivial things for my specific use.
The one major problem I had? Dealing with REAL input from REAL data on a REAL device. My app worked sufficiently fine on the emulator. When it ran on the Tab it was breaking everywhere!
I'm converting my Android app (apk) to Blackberry OS 10 (bar).
Everything is ok if i install the bar file to my BB.
But when I try to upload to our BB server to deploy to software to the Z10, i have the problem:
"Qnx/Android" is not supported
I found the root cause here:
It is currently not possible to add Android applications to the work
perimeter on the BlackBerry Playbook tablet or BlackBerry 10
smartphone; this is by design.
Since all applications added to the BlackBerry PlayBook tablet or
BlackBerry 10 smartphone via BlackBerry Device Service are installed
in the work perimeter, Android applications cannot be installed.
Alternatively, Android applications can be successfully downloaded
directly into the personal perimeter on the BlackBerry PlayBook tablet
or BlackBerry 10 smartphone.
What's should i do now?
I need to install my app to more hundred of BB10.
Can i reuse my Android code?
If can't, what's the best solution, best language if i must you write all the code from scratch.
Thanks you
Possible duplicate of
Deploy repackaged android (BB10) APP in Blackberry Enterprise Server within workspace
You can't reuse any of your code.
The best option depends on the type of application. If it is reasonably complex, with interaction with on device stuff like location, then Cascades/C++. Alternatively, you might consider html5. Have a look round here for more:
https://developer.blackberry.com/
Playbook is another curve ball. If you have to support that then you can't use Cascades.
And to be honest, there is a certain amount of personal preference involved here too - what do you like writing in?
Just a FYI, it took me about 6 months, part time, to feel fully comfortable with C++/Cascades. This was from nothing, no C, no C++, no experiences of GUI design tools and a different IDE. But I created my first app, a really simple one, in two weeks.
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.
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.
I would like to learn mobile development for fun and as well to enrich my resumé.
I'm currently developing in C/C++ at work on Windows (and sometimes with C# that I don't like too much). I have a nice Android phone and an iPod touch, so I wonder what is the best enviroment on which work.
Sure iPhone/iOS now has huge user base and a lot of attention, but it is used just i
on 3 devices from a single vendor (iPhone + iPod touch + iPad), Android instead is used by a lot of vendors, however is not gaining the attention it deserves.
I own a MacBook white so I can develop for iOS (I even have installed XCode but it seems a mess to me), but I prefer to work on Windows and I downloaded Android SDK + Eclipse and it seems much more easy given my Visual Studio background. I also know some Java and I'm already resigned to Linux.
So... which one should I learn, also given my background?
I don't think there is a real Answer to your question but since you already have the Android SDK and Eclipse set up why not try that first. Then if you don't like it try something else.
I found it very easy to deploy application on the Android Market and the registration fee is very small.
Android programming is a little bit difficult. Apple provide, in its development tool, a storyboard system that make very simple to control the flow of the app. Android is a bit more complicated.
On the other side, Apple programming is expensive: you need at least a Mac Book, an one between Iphone or Ipad. Last but not least, you need to sign to the apple developer program if you want to publish the app or to test it on a real device, which means 80 dollar/year. You can develop even without the program, and without a real device (iphone or ipad), but this means no possibility to test on a real device, which provides some characteristics that the simulator doesn't provide. And still you need a Mac, for Xcode (the apple developer tool) is only for Mac.
I believe though that is only your choice. Personally, i would begin with Apple in order to start with something that is simple at the beginning, but only if you have all the instruments listed above. For fun, Android is better: more complicated but free.