Inspiring

Question

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

Forum|Forum|13 years ago
December 14, 2012
5 replies
11274 views

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.

Development

This topic has been closed for replies.

J

janfw9969106

Inspiring

It looks like this issue still has not been addresses; I'm currently encountering the same error "Reloading a SWF is not supported on this operating system.". The SWF assets I'm using are exported from FlashCC's library (Export to SWF).

Is there a way to remove the ABC bytecode?

P

PisØ

Participant

Using URLStream to load SWF as ByteArray .. then the Loader.loadBytes to convert ByteArray to SWF .. with LoaderContext.applicationDomain.currentDomain and LoaderContext.allowCodeImport = true.. the reload works... isn't it? But.. there is some security problem using allowCodeImport = true?

B

Blakflag

Known Participant

I found that this technique worked OK in ipa-debug but once I compiled my App to ipa-ad-hoc the SWF -> bytearray -> SWF technique stopped working, due to the security restriction. So I abandoned that method and I am just holding references to all my SWFs in memory, if I need to reuse one.

Not a great solution but its the only one I have currently.

If anyone has swf reloading fully working in ad-hoc mode please let me know.

N

NicolasTony

Known Participant

Holding references... means you don't really unload them do you ? To me the whole point is to free memory of currently unused swf (have 200Mo of swfs-assets). Or maybe I am missing something and I wonder what you mean. If you keep them in memory, you don't unload them, and thus you're not even concerned with the issue. Concerning bytearray I don't think it helps at all for once, doesn't it already work in ipa-debug whatever you use for loading ?

My only solution so far : remove DoABC tags from swf, will work fine on both Android and iOS releases. Only problem is that, as said, it doesn't work in simulator, so I have 2 assets output folder (simulator test and release).

I made my own batch that does it now but it will work with so many restrictions no point in sharing sorry, you can also do it manually with swix, I used to do that.

B

Blakflag

Known Participant

I would also like more information about the issues raised in this thread. What is the current behavior as of Air 3.8? Is there any way to pull from very large collections of swfs (containing ABC) without either the danger of memory filling up or refusal to reload swfs?

What about SWFS lacking ABC? Are those safe again or still under the same new restrictions? This issue is pretty crippling for my use case, which is to port a large legacy application (with ABC in the swfs) to iOS.

E

Eddy_Li

Participating Frequently

I read an article about "Packaging and loading multiple SWFs in AIR apps on iOS" that happen to mention "Error #3764: Reloading a SWF is not supported on this operating system."

http://blogs.adobe.com/airodynamics/2012/11/09/packaging-and-loading-multiple-swfs-in-air-apps-on-ios/

Not sure if this applies on your case though.

G

Gaius Coffey

Legend

Hmm...

Reading that blog doesn't make me feel any more relaxed.

So, I have about a gazillion and six generated media files that have ABC that I neither want nor need, but cannot remove. The images are all I use and are simple Shape or Sprite with drawn shapes in them.

Based on that blog, I would need to do something like; "http://<pathtoserver>/<pathtoimage>.swf?cacheBuster="+Math.random() in order to allow for the possibility of a user wanting to use the same logo twice... It is simply _not_ an option to store so many possible logos.

However, the blog is also implying that what I am doing is dangerous in any case. In all modes that are available to me prior to full release, I am able to display and run the loaded SWF without issue. The uncompiled AS warning appears in debug mode, but not when I compile "ad-hoc for limited distribution". Is this a potential stumbling block for release in any case?

G

Colin Holgate

Inspiring

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.

F

FLAdudeAuthor

Inspiring

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

Inspiring

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

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded