Currently, the AIR beta (3.9) allows concurrency on Android but does not provide it for iOS
To solve this problem, or maybe even to do it more efficiently than AIR workers when they become available on iOS, is it possible to do concurrency via a native extension (ANE)?
I see the section "Threading" at http://www.adobe.com/devnet/air/articles/extending-air.html but it only leaves me a little more educated at my guessing :)
Let's consider an MP3 Player with visualization. Can an app be built such that the native extension reads the MP3 data, processes it, and hands over both the raw sound data and computed visualization for the actionscript layer to then play/display (and possibly manipulate the display further)?
I definitely think this is a legitimate usage of native extensions. We use threading in a few of the ones we've developed. It's a complex area to create a quick tutorial though but basically the iOS documentation on NSThread is what you should be looking into.
There's a good rundown on the concepts and some sample code here:
https://developer.apple.com/library/ios/DOCUMENTATION/Cocoa/Conceptual/Multithreading/CreatingThreads/CreatingThreads.html
The major difference between this and the AIR concurrency is that the concurrency code is written in AS3 whereas with the native extension you'll have to write in native code for every platform you develop on.
Related
Hi i am developing an application using adobe air for iOS using flex.
i have the user take a snapshot and my intention is to upload the photo to my api.
the problem is when compressing the byteArray and then encoding it to a base64 String to send it up the apps freezes for 1-2 minutes.
My question is: is there a way to multithread this process in adove air, so i have it going in the background ?
and from your experience does an adobe native extension use another thread on the device for itself or no, maybe i can handle the background encoding and upload in a native extension.
Thank you all.
AS3, up until recently, was entirely single threaded. As of FP11.4 and AIR 3.4, you have access to Workers, which is essentially offloading tasks to a second thread. Beta support was added to Android in 3.8 or 3.9 and I believe it is out of beta now in 13.0. Workers are not supported by iOS, though. This is, I believe, because they have to cross compile to Objective-C to support iOS at all, so their methods won't work.
You're only option is to load the processing onto an ANE, which may or may not be a good idea. ANEs are meant to behave as a bridge between AIR and native OS APIs. While this would work, I think it goes beyond the scope of what an ANE is intended for.
Unless your photos are insanely large, I would suggest just not doing compression. Resizing photos (using the BitmapData class) is fairly quick on 4S+, so I don't think that is much of an issue (4S is closing in on being 3 years old at this point. Having old hardware means things run less than ideally, so anything older will just have to accept poorer performance)
Worker Documentation
I have a successful kids educational maths game made in Adobe Flash ActionScript 1, its a fairly simple game but there is animations for example a plane crashing into our logo and breaking it apart.
Could I use HTML5 and tools such as PhoneGap and get it to work like it does now in an iPad App and get Apple to accept it on there App Store? I'm drawn towards HTML5 because its non-propriety and has a promising future but will it be able to replicate the game. I've noticed the featured games on the PhoneGap website aren't very interactive/game like compared to Adobe AIR app examples.
Thanks
You could definitely recreate the game in HTML5 and use PhoneGap to package it for iOS. As long as you follow the app store guidelines, there's no reason why the game wouldn't be accepted by Apple.
The game logic seems straightforward enough and should, therefore, be relatively easy to translate to JavaScript. However, I think there may be significant effort involved in reproducing the animations you have, to an acceptable level of performance, using standards-based web technologies.
There are a few avenues I can think of which it might be worth your while exploring:
Google's swiffy will convert SWF files to HTML5 so you can use them on devices which don't support Flash. I have used it successfully to convert a reasonably complex Flash animation, however the performance of the animation on the device, when it was packaged as a native app for iOS using PhoneGap, was significantly worse than the Flash version. I'm not sure whether the tool would be capable of converting the whole game (definitely not if it's pulling in dynamic data), but you could certainly use it to translate the individual animations of the game.
Adobe Edge is an animation tool similar to Flash for creating animations in HTML. I've not used it so I don't know whether it's any good. However, it is still a relatively new product and a quick search for character animations using Adobe Edge wasn't particularly encouraging.
The CreateJS toolkit for Flash Professional is a free extension which will convert Flash animations to JavaScript using the open source CreateJS framework (which looks superb and may be a good starting point for rebuilding the game should you decide to convert it).
Convert the game logic from ActionScript 1 to ActionScript 3.0, reuse all your existing animations as is, and package the game for iOS using the Adobe AIR packager. Inevitably the performance won't be comparable to native, but I think it should be acceptable for this type of game.
I think in your case I would probably go for option 4, primarily because you'll save yourself the effort of recreating / converting existing animations in another technology. I would definitely encourage you to embrace HTML5 and associated technologies but would suggest you use them on a new project which will allow you to plan around its particular strengths and weaknesses.
I've recently heard about the converting feature of Adobe Air but how well does it work?
Does it emulate every bit of code a complex Flash game using tons of libraries outputs or should you expect a lot of work to go around if you were to convert one?
I'm thinking of making a complex cross-platform game but not sure which is better/easier, to use Flash and Adobe Air for its abundant game libraries, resources and faster development or to simply go with Java.
It Would really save lots of time if I can use Flash. Though, I can imagine it would also give me headaches to worry about all the time. Like what if adobe/apple stops supporting Flash or what if the converting feature won't work.
Any advice and any bit of information would be welcome. Thanks.
AIR works well on iOS in my experience although native apps will always perform better. I cant think of any aspects of Flash that wont work when converted to run on iOS.
Whether AIR performance is good enough really depends on the individual case - how gpu and cpu intensive the game is.
You have to consider the trade-off: use existing Flash skills to create a 'good' game quickly; or learn new skills to create a 'better' game slowly - is it worth spending weeks/months learning new skills to get a few extra percent of performance? Only you can decide that.
Regarding Adobes AIR support in the future; who knows - they dont have a great track record (think flash on mobile) - but i would suggest AIR will be around for at least the medium term, if not long-term.
My personal opinion is that "mobile" is not going anywhere and now is the best time to start learning Java for Android and/or Objective-C for iOS. Like PhoneGap, Flash mobile Apps don't give you complete access to the devices entire API/SDK options, even though what they do offer usually suffices. Flash is still a respectable tool but developing "native" gives you full control over your app's memory, device interaction, cutting edge APIs, etc ...
Depending on how optimized your action script 3 code is written, you may experience some performance issues vs utilizing native graphics libraries. I assume the latest version of AIR (I know Flash 11.2 and on included some nice graphic stuff) may address performance but haven't seen any benchmarks for AIR on mobile devices yet.
If you are hoping to go the AIR route, I'd say why not take a few days and try to port it over. If all else fails get a nice iOS or Android book and cuddle with it every night until you are confident you can recreate your App natively.
It's a great thing that it's possible to compile an SWF into iOS native app. I think AIR is now the best option to write e.g. small games or interactive books. Of cause AIR app will be slowler than the same app written on e.g. objective C. The question is how slower AIR app will be. Can simple AIR apps be launched e.g. on iPhone 3G or iPAd 1?
And another question is, can arbitrary flash app be compiled into iOS native app?
Will be grateful for any thoughts!!!!!
Performance of AIR vs. Objective C:
For pure script execution, AIR apps perform rather slower than native, including on iOS. However, in virtually all cases the limiting factor of your app's performance will be rendering, not script, so it depends entirely on what you do visually in your content. This is why Crooksy suggested you look at Starling. Without Starling (or similar libraries that make use of the GPU), it's pretty challenging to get decent performance out of an iPad1. It can be done, but it takes expertise and incurs extra work. It will be much better to start with the huge performance boost of using Starling or similar.
Can arbitrary flash app be compiled into iOS native app?
As long as it's made with AS3, then it should compile. For whether it works, two main caveats come to mind: First, a handful of APIs don't work on mobile devices. (I think printing is one example.) Second, if you read in any SWFs at runtime, all actionscript inside them will be ignored. (Not for technical reasons, it's an Apple requirement.) So if your content is split into a bunch of SWFs you'll need to bundle them together at packaging time, and if you absolutely depend on reading in SWFs with script from the network at runtime, you're going to hit a wall.
Hope that helps!
Check out the new Starling frame work.
http://gamua.com/
Here's the start of a nice tutorial series (episodes 1 and 2)
http://www.hsharma.com/tutorials/
Lee Brimelow also has a few tutorials
http://www.gotoandlearn.com/
Regarding converting Flash apps into iOS compatible apps, yes that is possible but it depends on what the app actually does as to whether any modifications will be needed before it will perform correctly on a device.
I've looked at a few demos from adobe that show apps built with Flex 4.5 running on iOS from simple list views to video capture. This has made me wonder if its an effective solution to build cross platform mobile apps.
For those of you who have taken Flex 4.5 mobile for a spin, what is your impression on the capability and performance on iOS. Is there anything you can't do with Flex 4.5 mobile that you couldn't with a native app? Are there any limitations?
The mobile story in Flex is quite strong, in my opinion. It is what has attracted me to the platform and what seems to be bringing life into the Flex community.
The experience for developing apps in Android and iOS is quite fantastic, actually. The velocity in which you can dev is blazing and the abstractions provided by Flex (data binding, state management, skinning, etc) give you the ability to totally rock your app.
The performance is better than I had expected. It is not as great as a native app, but it certainly gets the job done. The ability to share code and UIs between Android and iOS more than make up for it in most cases.
There are, however, limitations. For one, you are not using the native widget set. You are using the Flex widget set. This means that you do not get the native look/feel. For this reason, it is best to build apps that look like YOUR app... not a Flex app or a native app. There are lots of popular examples in the app stores that work this way... and a Flex app pretty much requires it in my opinion.
There are also a lot of APIs not available to you. Flex provides hardware abstractions for the most popular APIs (video, audio, accelerometer, positioning, webkit, etc) but platform specific APIs are still missing (contacts, calendar, system notifications, etc).
At that point, it is worth asking what your app needs to do. Does it have a lot of native interfacing? If so, Flex might not be right for you. Find the APIs you need to talk to and make sure Flex has an abstraction for you. If it is a data-centric display/edit app, then Flex is a strong fit.
Hope this helps :)