I've been developing a project in AS3 but decided to switch to AIR instead, as I found out it's impossible to save files on user's hard drive without prompt appearing. My question is, what changes do I have to expect? is the code written in same AS3 syntax/style? Did instantiating objects / drawing shapes / positioning system / stage change in AIR? thanks.
Everything is the same from a code perspective, except that the AIR SDK includes quite a number of new APIs that are less restrictive and geared toward application development since the deployment target is no longer a web browser.
If you can, you should take a day or 2 and read thru the documentation so you will know what's available to you. Make sure to select the most recent versions of AIR and Flash Player under Packages and Class Filters: Runtimes so the docs are populated with what you need.
Related
With all the security issues with Flash lately I am looking at alternatives for if/when Flash is retired at my work. We use strictly IE 11 and IE11 seems to be very finicky about css3 animations. I see the new Flash has the ability to publish the file as embeddable actionscript files instead of a swf file. Is this a viable alternative to Flash or is this vulnerable to the same security issues Flash has? My assumption is the vulnerabilities exist in the Flash players but I want to be certain.
No. Apples and Oranges, really.
The Flash Player is a runtime environment of the Flash platform (AIR being another). It "plays" .swf files.
ActionScript is the scripting language that an apropriate compiler (mxmlc, for example) compiles into .swf files.
I see the new Flash has the ability to publish the file as embeddable ActionScript files instead of a swf file.
You can embed any file, but guess where you embed it into? Into the swf file.
Again, ActionScript is the programing/scripting language and an swf file is the compiled result.
Flash CC can also export to JavaScript/HTML/CSS. That means that instead of creating a .swf file, a bunch of JavaScript/HTML/CSS files are created.
As you can see in the link you provided, the feature sets are not equivalent.
Note: The 3D Rotation tool in the toolbar of the Flash Professional CC workspace is disabled when creating HTML5 Canvas documents because it is specific to SWF projects and not supported in the HTML5 specification (see Figure 3).
There's a whole bunch of other things not supported
Recommendation
If one comes to the conclusion that the Flash platform is not an appropriate publishing platform any more, why bother sticking to the Adobe Flash program?
It appears to be disadvantageous to cling to the program, just for the sake of keep on using it.
Why not use the CreateJS library on its own? Or any of the other dozens of great JS libraries? There's a lot to explore in the post-Flash era and it is very exiting. It's not a good idea to stay behind, still coding in dead languages, hoping that there's a translator to communicate with the Present. Try to order a pizza in Latin and you know what I mean.
If the goal is to target multiple different platforms, there are alternative tools to do this like defrac or Haxe that allow you to compile from one languages to many platforms.
The answer to the question if compiling ActionScript to JavaScript/HTML/CSS is a reasonable workflow for the future is no. It might be a good tool to port existing projects, but not to neglect the current developments in the JavaScript/HTML/CSS realm.
I seem to get almost weekly Java updates. All these technologies can have security issues, it's just that Adobe react quickly, and release a fix as soon as possible. That does come with a certain amount of publicity.
About using CreateJS on its own, you could do that, and come up with your own libraries to create hierarchy, synchronizing sound to visual events, asset management, etc. You could also do everything purely in code, if your imagination is good enough to do that. Or, you could just use Flash Pro, and get all of those things for free.
After already searching the site for the answer to the question, I've found this:
Is it any way to run two instances of debuggers?
I need the Flash Professional CS5.5 version of the answer to this question.
Basically - I need to know if there's a way to debug 2 different .fla files in Adobe Flash Professional CS5.5 at the same time. One of them implements the Adobe AIR framework (for using the SocketServer class), the other is a standard AS3 project. It'd be nice if I could debug the client-server interaction easily using the IDE rather than using extensive means to do so.
Anyone have any ideas? Thanks.
This is not an answer to your question but a suggestion to take a different approach.
The Flash IDE and it's debugger are inadequate but for most trivial programs. Variable inspection and breakpoints work randomly and it's next to impossible to drill down into more complex objects. Flash IDE is all right for creating the visual resources for Flash programs but for any serious coding, it just falls on its face. The compiler included with the Flash IDE is also very poorly written and generates unoptimized code.
I'd suggest to switch over to using FlashDevelop - it's a free, open source IDE that runs on top of the Flex and Air SDKs and uses a better compiler that performs more optimizations. (You can mark functions for inlining, etc.) The debugger - while not Visual Studio - is much, much better than the IDE: breakpoints work and object properties can be inspected easily.
Because FlashDevelop is geared towards coding, you can create a project in it with multiple source files, define your resources and then compile to multiple platforms. Compilation is usually fast with hundreds of source files (don't import every type in every package) and you can do debug/release builds. If you can port your code from Flash to FlashDevelop, you'll have a much easier time managing your project.
I'm relatively new to flash, air and AS3 so I'm sorry if this comes of as a beginners question. I have made an application in AIR to run on windows and communicate with my atmega8 chip through serial communication via serproxy.
Now I want to port that application to android to perform the same basic functions but communicate to the atmega8 via bluetooth. So I created a new Air for android file in Flash CS6 copied my code from my previous application excluding the communication through sockets part and created an apk which ran on an android phone:). It did everything except the communication as expected.
Now I have been trying to implement the as3breeze.com/bluetooth-ane and use it to communicate but I'm not too sure how to go about the whole thing. I have imported the ane through actionscript settings and have implemented the classes but when I try to test I get this error.
The content cannot be loaded because there was a problem loading an extension: Error: Extension namespace is invalid for C:\Users\AppData\Local\Temp\Tmp_ANE_File_Unzipped_Packages\AndroidBluetooth.ane
So after some searching I found posts talking about as3 sdk and flash builder. Do I really need all these things or can I make my bluetooth app work some how with just flash cs6? Also what exactly does my error mean and how can I solve it. Thanks in advance for any help. I have been searching so a solution to this for days and I either get an explanation that does not work or I lack the knowledge to understand.
The path that can't be accessed makes me believe you haven't extracted the ANE (basically you're trying to access a temporary directory). Try extracting the ANE file to somewhere, like My Documents or wherever your flash project is, and include (in the actionscript settings) that path instead.
Hope it helps.
This month I started to play with Flash Builder because I don't have a mac to create native iPhone apps.
I have made a Flex Mobile Project and an AS3 Mobile project. Both do mostly exact the same and I see great differences in operation speed (AS3 version is much faster). Also the size of the AS3 version is less than the size of the Flex version when I deploy the project.
But one thing disappoints me, the size of a deployed AS3 app (Android) is still about 8MB. I think that is quite huge for a simple app, or is it normal? I did not test the iOS version because I am not an Apple Developer member (is there a trick to deploy an iOS app with fake certificates)?
Resources I have used in the apps:
Two images approx. 35kb in size
A StageWebView
I want to know:
What is the average size of a simple app when it is a native app (apk file)?
What is the difference between an AS3 app and a Flex app except the libraries that re used?
Is the AS3 app converted to C or another language?
Why is the apk so huge (IMO)?
Is there a trick to deploy an iOS app with fake certificates? (just for testing)
Thanks for the answer(s).
What is the average size of a simple app when it is native app (apk file)?
I have no idea. When you were comparing sizes; did you export a release build or a debug version? The full version of my app; using Captive Runtime is 12MB. That includes all the embedded images. I thought that roughly 8MB is the size of the embedded runtime. Of course, if you don't use Captive Runtime then the app will be smaller; but it will have a depency on the user having the runtime installed.
What is the difference between an AS3 app and a Flex app except the libraries that are used?
For all intents and purposes nothing. The Flex Framework will need to execute code to setup the framework and such. In theory this 'impact' is offset by the value that the framework brings.
- Is the AS3 app converted to C or other language?
Not for Android or Playbook. It relies on the Mobile AIR Runtime--which I assume is written as a native app somehow. For iOS there is a more in depth conversion taking place; but no on knows the exact magic sauce; but it the process is much more intensive than Android or Playbook and people believe that your code and the AIR Runtime is converted to Objective C somehow in a way that is not in violation of the Apple licensing agreement.
Why is the apk so huge (IMO)?
Huge is open to interpretation. Without seeing your full app code; it's tough to judge.
Is there a trick to deploy an iOS app with fake certificates? (just for testing)
I don't think so; although there may be possibilities on unlocked devices.
You would like to use Mobile AS3 Project if you want you apps to be smaller and your GUI mainly contains vector graphics and Mobile Flex Project if you prefer to use standart GUI Controls that comes together with Flex framework but adds overhead in size because of controls that come with it.
As of the other questions:
the size of the apps is different on mobile platforms. Typical iOS app is about 2MB - 20MB. It really depends on resources you store with your app. What might be important to you is not to overcome 20MB if not needed because 20MB+ apps require Wi-Fi connection to be downloaded.
(However you should export release build version only as mentioned by www.Flextras.com)
there is no fundamental difference between AS3 and Flex apps - they both compile to the same instructions that executes on targeted mobile platform.
as far as I know (being iOS developer myself) there is no workaround to deploy an iOS apps. You need to use Mac and become Apple Developer to deploy with valid certificate.
to make your app smaller try to pai special attention to the resources you add to the project. Although I believe the size is so big because of framework itself, you would like to use more vector graphics vs. bitmaps when compiling apps with Flash/Flex.
When you export for Android you have an option of embedding the air framework in the application, that way your users don't have to download air. you can export your application without air embed which will result in a much lighter application, however your users will need to download air runtime. http://cookbooks.adobe.com/post_How_do_I_create_an_AIR_application_for_Android_tha-19299.html
I already made a game with flash, and I want to provide an easy download for people that would rather play offline. Thing is, i use a folder whole structure to dynamically load content per level. Folder structure looks like this, not that it matters that much:
Game folder
animations
anim1.swf
anim2.swf
sounds
music1.mp3
soundeffect1.mp3
levels
level1.lev
level2.lev
myGame.swf
How should I go to distribute this? Should I just resort to make a zip file for the flash game and assume people know how to extract and open the swf? Is there any other way to port easily as an executable? Perhaps Adobe Air (not sure if this works though)?
Thanks, and please help!
Distributing a zip file is the only option if you really want that structure to prevail. Else,
Embed all the resources in the main (myGame) swf & distribute it.
Provide a html page for people who do not have standalone flash player installed.
Embedding as a single file allows the browser to cache the single swf & allow the player to keep playing offline until cache is cleared. So user might not even need an explicit download.
If you are using Flash Builder it is fairly straightforward to compile the application into a self-installing AIR executable (or DMG on a Mac). It is possible to include the AIR runtime which would avoid potential problems of the user not having the correct flash player for example.
An alternative to AIR would be to create a projector executable from inside the standalone Flash Player or from the Flash authoring environment.
Another option to using a zip file would be to use a free installer creator such as InnoSetup or Nullsoft on Windows, or Packager on Mac. Linux users are generally more tech savvy and so a tar would probably be well understood.
Adobe AIR works wonderfully! I use it for my own project, and your project should transition over to it with little to no modification (any issues should show up in the Compiler Errors and Output). The only downside is that, past AIR 2, there isn't any Linux support.
The other option is obviously to create a standalone .SWF projector inside a zip or installer, but in my opinion, that isn't the sleekest way to deploy for desktop. The advantage of AIR over this is that it gives you access to additional desktop functions that Flash Player doesn't.