What's the solution for using a SWF graphic more than once since reusing your graphics is 'dropped'?

[FLAdude]

The whole reason for having SWFs is so that you can use the graphics, usually more than once. If you are writing a game, for example, and you have a SWF to be a enemy character graphic, you are most likely going to have more than one of that character in a level, and it is useless if it breaks your app to do something so basic. There are really countless situations where you would want to use a SWF graphic more than once, just like you would use a PNG or JPG more than once.

It now says

Error #3764: Reloading a SWF is not supported on this operating system.

whenever you try to use a SWF more than once on iOS.

The release notes say that this foundational, basic functionality of AIR was dropped because there 'was a problem with it'. What is this 'problem' and why is it worth dropping such a core and basic functionality of the platform? It is strange that the notes simply say this is dropped, but don't say what solution you are supposed to use instead, or give any real explanation as to why it was dropped or if it was ever coming back.

Is this permanently dropped or just for the beta?

What is the 'problem' that is worth dropping it for?

What is the solution to use graphics more than once in AIR?

The release notes talk about 'undefined' behavior. What does it mean if the behavior of something is 'undefined'?

Packing all of your graphics as classes within the root IPA/SWF object is not a solution because it obviously won't work for downloadable graphics and it would make a massive SWF if you have a web-based version of your project, making it take an unbearable amount of time to download to a user's browser.

This secondary ActionScript SWF 'feature' is something that should be an option people can enable if they want with a check box or command line option. Doing things that break other things isn't a fix or a feature. To randomly drop such a basic and foundational functionality is insane.

The secondard ActionScript SWF thingy hasn't even really changed anything anyways, the secondary ActionScript would still have to be there at compile time, so you might as well put all your code into the main SWF anyways, it is just some smoke and mirrors to make it look like dynamic loading of ActionScript. Any truely external ActionScript will still not work. You still have to approach your project differently if you want it to work on iOS.

[Colin Holgate]

You can load externals swfs that have graphics in them. You just can't load in external swfs that have code in them. In your example where you have a game character that you want to have multiple copies of, you could do the same as you would with web based Flash, and use a Loader to load in the same swf repeatedly. Another way you could work would be to have one external swf that has all of the characters you need on its stage. Then when you want to add a character you would just addChild() it from the stage of the loaded swf to the stage of your app.

[FLAdude]

It will only load one time. After that, even a SWF with NO actionscript in it will cause an "Error #3764: Reloading a SWF is not supported on this operating system."

As of AIR 3.6 you can only load a SWF graphic one time, after that it will fail and make an error. This will happen even if your SWF just has graphics and NO ActionScript.

This worked previously, but with the new AIR3.6 build just released, it is completely broken.

[Colin Holgate]

Ok, I managed to reproduce what you're saying, with a very simple test case. I'll raise a question about it elsewhere.

[Gaius_Coffey]

I'm tagging onto this as it could, not to put too fine a point on it, make six months of work utterly redundant, probably cost me a customer and leave me a bit shafted.

Please can you confirm;

What is the limitation on loading external SWF content?

Currently, I have SWF files generated by InDesign that I need to load on the fly as they have InDesign generated graphics in them... They _also_ have InDesign generated garbage actionscript that I do not want but cannot remove.

So...

Are you telling me that I can no longer load these files in? Or, that if I do, I can only load them _once_ per url?

If so...

With several thousand possible graphics, and users who are likely to go back to the same areas several times, I am... well... not very happy.

G

[Colin Holgate]

For your job that you're already doing there's no problem. You don't have to publish with the beta of AIR 3.6, just publish with the shipping AIR 3.5 instead. Hopefully by the time AIR 3.6 is finished they will have found a way for it to work again.

[Gaius_Coffey]

Ok, so this is a _bug_ and _not_ a policy decision then?

G

[Colin Holgate]

Let's hope so! I've shown my simple test case to Adobe, hopefully there will be a good answer.

[FLAdude]

Thanks for spreading the word about this to Adobe, Colin.

@Gaius

From the way they stated in the AIR3.6 release notes it sounded sort of like a policy descision, which is what disturbs me and would be utterly insane. Hopefully that is not the case.

[Lorenzo_Nuvoletta]

FLAdude, I have same issue as you... simple graphic SWFs with NO code, I want to load and unload them on demand to manage memory better and now in Air 3.6 I can't... this should be a bug not a feature.

[JonKaye]

@Gaius @FLAdude @ Colin -- now that AIR 3.6 has been released officially, has this issue been resolved in that one can reload SWF's without code? I am using 3.4 now but need to update to 3.6. I didn't see anything about the restriction in the 3.6 release notes, but I am very nervous -- I have a whole bunch of SWF files to load for assets. Thanks!

[Gaius_Coffey]

I will be doing that tomorrow - watch this space.

G

[Gaius_Coffey]

So far, so good.

G

[Nimisha1]

Reloading of pure asset SWFs(having no ABC code) is now allowed on iOS, please download the AIR 3.7 build from here :

http://labs.adobe.com/downloads/air.html

While reloading the pure asset SWF please make sure your SWF doesn't contain any ABC code otherwise it won't get reloaded.

Please share your feedback with us!

Thanks,

Nimisha

[Gaius_Coffey]

Hi Nimisha,

That doesn't even come close to resolving my issue, sorry!

For example, we use Adobe InDesign generated Swf assets. There is no way I have found to prevent these from containing ABC code... But I neither want it nor need it nor use it.

There are literally thousands of these. Too many to load once and never again. 

What would work better for me is either a) a server-side way to strip ABC code prior to serving or b) (better) a "loadWithoutBytecode" flag to let me notify the runtime that I don't need or want the code or c) (best) a way to prevent Adobe InDesign putting in all this rubbish and unwanted ABC code in the first place.

Thanks

G

[Nimisha1]

Hi Gauis,

Can you please try any third party tool (like http://www.swixkit.com/ ) to remove DoABC tag from the SWF?

SWIX is a Windows Only tool and using this tool, one can easily remove the DoABC tag from the SWF & re-create the same SWF which has no ABC Code. This is useful for simple asset SWF’s which do not use any classes/ symbols which are required by the Main SWF.

This might be helpful in cases where removal of the DoABC tag won’t affect the working of neither the secondary SWF.

Thanks,

Nimisha

[Gaius_Coffey]

Hi Nimisha,

Thanks for the link, I've downloaded and it does seem possible to get a workable asset SWF for desktop.

To be workable, it would need to run in-tandem with InDesign server as a command-line / API. I have contacted them for information about the achievability of a server-side solution, but... Even if they can help us (which remains a big if - I don't know that my customer wants to be the first to implement a server-side solution based on this) we will need to modify a number of systems to make it work and there will be additional licencing, technical headaches and so on for ongoing maintenance.

Is there a good reason why we can't simply opt in or out of processing byte code from downloaded SWF files?

It seems to me that we wouldn't need to do anything at all, and certainly wouldn't have to introduce a costly third-party product and additional servers, if we could simply ignore the downloaded ABC.

G

[Lorenzo_Nuvoletta]

Hi Nimisha,

Thank you very much for that.

I was reading the release notes for Air 3.7 and that is not listed, is it because it is stillnot perfectly working yet?

i noticed it still has problems unloading SWF with SWF version:10

[Nimisha1]

Hi Lorenzo,

What is the issue that you're facing while reloading?

-Nimisha

[Lorenzo_Nuvoletta]

I am sorry, it was another issue that indirectly was causing the loader to break...

so far with Air 3.7 SWF seem to unload and reload fine.

[Gaius_Coffey]

Hi Nimisha,

I have downloaded the SDK from labs, but Flash Builder is throwing up a nasty error as follows;

Description	Resource	Path	Location	Type
unable to open 'E:\sdks\4.6.0_AIR3.7_LAB\frameworks\libs\player\11.5\playerglobal.swc'	OSMF2.0.2494		Unknown	Flex Problem

I built the SDK in the same way as I had previously done for 3.6,3.5,3.4 etc... so...

Is there something I'm missing? I know for 3.6, I had to download a slightly different package as per Colin Holgate's post here; http://forums.adobe.com/message/5129146#5129146#5129146

Can you let me know as I would like to test against 3.7, thanks.

G

[Nimisha1]

Hi Gauis,

The SDK which is available at Labs is the one which contains ASC 2.0 and it is not compatible with Flex projects. That is why you're facing this Flex problem issue.

We are working to make SDK available on Labs which contains ASC 1.

Thanks for letting us know.

Sorry for the inconvience caused.

-Nimisha

[Gaius_Coffey]

Thanks, Nimisha,

Is there a reference somewhere that I can read to understand the difference between the two? It seems a bit bizarre that you need anything different for Flex, which is surely just a collection of ActionScript 2.0 classes and assets as per everything else.

Also, can you respond to this;

"Is there a good reason why we can't simply opt in or out of processing byte code from downloaded SWF files?"

Obviously, from everybody's perspective, it is preferable _not_ to require the introduction of an expensive third-party product and yet another technology to supply what we _already_have_ just in a slightly modified form...

G

[Divij_Kumar]

Regarding the query:

"Is there a good reason why we can't simply opt in or out of processing byte code from downloaded SWF files?"

A downloaded SWF having bytecode is equivalent to having a part of the executable code of your app being downloaded at run-time. This is not allowed by Apple. Refer section 3.3.2.

3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.

Regards,

Divij

[aj-runtimelogic]

Hi All,

I'd like to revive this thread and ask for further clarification of why SWF reloading isn't supported in AoT builds for iOS for SWF assets that have ABC.  When we package these assets using ADT it strips the bytecode from these files and packages it within the primary application SWF so I don't think that Apple ToU compliance is an issue any longer.  I assume there must be a technical limiation in how the loaded SWF with stripped ABC is linked back up with it's bytecode after loading.

Is this a limitation of the AIR runtime that can be worked around in the future, or something that stems from a technical limitation of how the cross-compiled code actually executes under iOS?  In otrher words, can it be fixed in a future release of AIR?

It seems to me that the promise of using AIR is the ability to target web and iOS from the same codebase.  If you have an existing application of some complexity targeting web then it's likely loading assets on demand and reloading them later as needed (Ex. we have over 700 items in game that can be equipped on avatars and each is a separate SWF asset).  Having to extensively modify the app's asset manager for the iOS platform crates the need for divergent codebases at the core level for each platform.  It seems like this is an important flaw to address if Adobe wants to target mobile gaming.