what is difference between swfLoader(load application) and ModuleLoader(load module)?
which is better to use?
thanks
The SWFLoader is used to load sub-applications while the ModuleLoader is used to load Modules, as you stated yourself.
The difference is that Modules have a tight link to the application their are loaded in and cannot be used standalone. A subapplication on the other hand really is a separate application that has no direct link to the application it is loaded in. Depending on your use cases, you might consider one or the other.
There is a good stuff available from Adobe here
Be sure to check the section "Comparing loaded applications to modules".
Related
I added a MXML component in flex and selected the base as UIComponent. I want to make it accessible so that automated testing tools can Access it. I am using TestComplete for automated testing. As TestComplete uses Microsoft Accessibility classes. Now it treat my component as the Graphics.
How Can I do this??
It should work, if the application was correctly prepared for testing with TestComplete. Check the Preparing Flex Applications for Testing with Automation APIs topic to learn more.
You won't have much luck automating Flex using MSAA, because the object hierarchy and information reported by MSAA is very limited. To improve things, you could try compiling your application with accessibility enabled and also creating a custom accessibility implementation for your component. However, I doubt it will make much difference.
Having said that, you should really consider upgrading to the TestComplete 8.20, because this version has proper support for Flex. By "proper" I mean that it identifies all objects inside Flex applications (including custom components), provides extra test objects for automating Flex controls and also lets you automate controls using their native properties. In addition, this version can dynamically load the testing library into Flex applications, so that no changes to the application's source code or build process are required.
Please look at the official documentation about Creating Applications for Testing
Especially the part about instrumenting custom components
First, the background:
I am creating a Flex application with a component that displays various dynamically loaded SWFs, one at a time (kind of like a kiosk). These loaded SWFs are created in Flash IDE, not Flex. They will not be created by us (we will provide a .fla template but that's it), so I am loading them into a separate SecurityDomain.
My Questions:
I want the application to be able to call methods inside the loaded SWF. To do this, would I just call Security.allowDomain("domain original app was loaded from") in the startup process for the loaded SWF?
I want the loaded SWF to be able to throw events that are caught by the application. Can I accomplish this through the SWFLoader.swfBridge property?
I am defining an interface for the methods inside the loaded SWF. But, I don't want to leave the implementation up to the customer. Instead, I want to provide another SWF that contains the interface implementation and have it be a constraint that the customer includes it in their SWF. I am not very familiar with the Flash authoring environment, how would it work so that the interface implementation SWF exposes its methods in such a way to be accessible to Flex? Is there a way to sign the SWF so that the Flex application knows that it is dealing with the original, not a spoof? How would the Flex code pass in arguments, since it is across SecurityDomain boundary -- is there marshalling involved (say if I want to pass in a Dictionary or some kind of object graph)?
The Flex application may load hundreds of these smaller other SWFs during its lifetime. How do I make sure it doesn't keep using up more memory? I plan on using SWFLoader.unloadAndStop() and clearing all references in the Flex object that refers to it. Is this enough? Will the AppDomain for the loaded SWF be torn down automatically so that the class definitions are no longer in memory?
Thanks,
Karthik
Some answers:
2) No. Well, you could try, but it would be a mess. You can look into some of the bootstrap loading documentation, but if you're not in complete control of the flash development, this is a lost cause and will end in headache for you.
Depending on your architecture, I would abstract everything out in such a way where communication is happening through javascript or through a localConnection. It might be a pain to use a localConnection to start (giving the serialization size constraints, etc.) but once you get everything hashed out, you won't need to fight with all the security sandbox restrictions. I understand that you want everything to be secure, but if you have control of the server and know where the swfs are being loaded from (and can add numerous layers of security that you invent [for example: having a loaded swf talk to a server when loaded]), you may be better off.
Random thoughts....
Good luck in any case.
Alex Harui from Adobe gave some extremely helpful answers on my post on the Adobe forums. Check them out if you are interested in this same question.
Karthik
I'm about to start a project where there will be a Flash application where the visitor customizes a profile with externally loaded images and texts. Then the visitor needs to be able to download that profile as a dynamically created swf with all that external content baked into the swf.
Any ideas how to achive this?
Thank you!
Which aspect are you curious about? The overall workflow of setting up the server-side architecture? Information on tools that can generate SWFs? Or information on the SWF format itself?
As for tools, here are a few options off the top of my head:
The Flex SDK (i.e. mxmlc) will compile a pure AS3 project with embedded assets. If you've got reasonable control over the server, and don't mind a relatively heavyweight approach, that's probably the most "supported" way to go.
SWFMill (http://www.swfmill.org) has its own XML format for generating SWFs and importing assets. It's not quite up-to-date on newer SWF formats, but that may not matter depending on the requirements.
www.swftools.org has a few things that may be useful.
haxe.org has several options for generating SWFs.
If your question is about generating the format from scratch, all those projects are open-source, and personally, I've found the haxe sources to be the easiest reading. The library you want is http://code.google.com/p/hxformat/. Taking a look at the swf format spec might be helpful as well: www.adobe.com/devnet/swf/.
Or were you looking for more step-by-step detail?
(note: sorry for the lack of active hyperlinks, apparently the system doesn't believe I'm human yet :)
I believe you would have to create the SWF on the server side and then either
1) provide the user with a URL
or
2) dynamically load it in to your application and use it as the target for a button click, or something like that.
There are a number of ways to create SWFs on the server, but that's an area outside of my experience. Maybe someone else can post some better information on it, but here's a link to one approach, to get you started.
http://www.sephiroth.it/weblog/archives/2006/02/swf_server_side_compiler_with.php
My Flash (AS3/AIR) application is currently using a slightly unusual architecture (for a Flash app) to provide particular base classes for loaded content at runtime. The external content is published with 'stub' base classes, which are eclipsed by the 'real' base classes at runtime when it is loaded. I've heard this referred to by Adobe as bootstrapping (pdf), and it has been working very well for me until now. It's not unlike a DLL architecture I believe, although I'm not qualified to say for sure.
Until now, the external content I have been loading has been loaded from within the same SecurityDomain (same sandbox), which allows me to easily load the content in a child ApplicationDomain. Unfortunately, as far as I can tell, an ApplicationDomains that span SecurityDomains cannot be related - that is, I cannot make an AppDom of one SecurityDom the child of an AppDom from another SecurityDom.
But now I need to load this external content from outside my Application sandbox. There are plenty of ways to achieve communication across SecurityDomains - although most of them are very limited, AIR's sandboxBridge API is probably the most powerful. Unfortunately, none of these communication methods allow me to achieve this bootstrapping architecture.
I notice that the LoaderContext object has a securityDomain property, but Flash security prohibits 'local swfs' from touching it (it throws a SecurityError or similar).
Flex's SWFLoader has a trustContent property that looks promising, but I'm inclined to assume that it has the same restrictions as setting the SecurityDomain in the Loader's LoaderContext.
I suspect I'll have to redesign (which won't be easy), but I thought I'd just check here that I've not missed something in my research.
So ... any ideas or pearls of wisdom? I'd especially freaking love it if someone from Adobe who works on the Security model could gimme a definitive "yes/no it can/can't be done"...
Thanks in advance!
Addendum: I've since decided to re-design the architecture so that the bootstrapping all happens on the external domain. My question still stands, however, out of curiosity.
Technically speaking, wouldn't it be possible for your AIR application to simply save the external SWFs inside your application directory, and load them from there so that they live in the same security sandbox?
However, there are some really obvious reasons why this would be Bad Karma, so it seems like any solution necessarily raises the question of whether trying to put local application content and remote untrusted content into the same app domain is the right architecture approach..?
At the time of writing, I determined that you cannot load an ApplicationDomain into your own SecurityDomain if it is from another domain, even with AIR.
By design, I guess.
Okay, so ASP.net allows one to embed Images into an Assembly and access them using WebResource.axd.
I just wonder: What are the Pros/Cons of using Web Resources instead of Images in a folder on the Web Server, like how it's being traditionally done?
This article mainly mentions ease of deployment, but that doesn't seem to justify the extra amount of work.
One clear scenario is: third party controls.
I really don't want to deal with different script/image files for controls we are not developing. With embedded resources, its just the .dll file and that's it :).
The same applies if you are developing custom web controls that you will be using across different web sites.
I built custom controls that used by three different applications in same machine. When I maintain scripts for controls, I can forget deploying the new script file to every application.
In this scenario, it's good to embed resources into assembly and deploy assembly to GAC.
But the good point about external files (not embedding resources) is that, sometimes you realize a bug in script files. deploying it without resetting application is a good thing in an online application.
here is the rule i think it is the best,
if you have resources that wont change that often like, scripts, images. then you are better embed them in resources.
but if you have resources, that change versions like Jquery, then you should create properties to point to those external resources.
hope this helps
For me it is just a an another not-killer-feature added in ASP.NET . I do not think that it was implemented with serving a lot of content in mind but some times the added ease of deployment matters, then you gain some benefit. Question is when?
Microsoft states that they use it for eg. to serve forms validation scripts, and that due to caching it should not affect performance. That creates isolation for the controls and their scripts, so you do not have to worry about them yourself when adding them to your site.
So for me, if you think it helps you deploying user/server controls you can try. For serving images in general? I would not bother.
I would not put images into the assembly. It's just too much work for no apparent benefit. Is it faster? Probably not as Reflection-like speeds would be called in to get to the resource. Is it harder to maintain, you bet!
Why would a high-end developer be needed when the business wants to update a logo for example?