I received this warning when I migrated my application from flex 3 to flex 4:
components:MyApp is a module or application that is directly referenced. This will cause components:MyApp and all of its dependencies to be linked in with modules:searchModule. Using an interface is the recommended practice to avoid this. Unknown Flex Problem
MyApp is a class which extends the Application component and in the module named "searchModule" there's this line:
var parentApp:myApp = parentApplication as MyApp;
I then use the variable myApp to call methods defined in the MyApp class from within this module.
This warning is reported 10 times because I am doing the same in other modules.
I want to fix it but I don't understand the part "this will cause its dependencies to be linked in with modules" and how would I make an interface to avoid this? And why there wasn't a warning about it in flex 3?
Thanks in advance
I'm guessing a bit, but...
The Flex Framework is one of those special Adobe-only libraries that can be cached by the Flex player. As such, with certain compile settings, the SWF from the compiler does not contain the Flex library. In lex 4, the framework is not compiled into your application SWf, resulting in significantly smaller application file size.
If you extend the Application class, which it sounds like you done, the compiler cannot count on your new "Application" being in the cached Flex Framework and therefore must compile your new class, and therefore the Application tag into your SWF. This is going to daisy chain significantly; as the Application tag does a lot of Flex Framework setup stuff.
I assume that is what the warning means in terms of dependencies.
Did you really extend Application with additional functionality? Or is "MyApp.mxml" just the name of the your main application file?
You might try this:
var parentApp:Application = parentApplication as Application;
I believe there is a FlexGlobals class introduced in Flex 4, which can also give you access to the top level Application.
In terms of using an interface. Interfaces are designed to help remove specific dependencies. You can create an interface for your new functionality of the new Application class and reference that instead.
var parentApp:myApp = parentApplication as IMyApp
Based on my interpertation of the messages you're seeing that may address the issue.
I had this error when I had Application MXML insted of Component MXML, for example.
Changed Application to Group, in referenced Component, and warning was no more.
Reason for error was, because I worked on component in separate project as application, and later copied it to main project, but I didn't change it to component.
Related
I'm looking at using Sub-Applications within flex, to enable mutli-versioned compilation.
Specifically, I'm looking to have a Flex 4.x host app that loads Flex 3.6 sub-apps.
The docs state this is possible (and the purpose of sub-apps). However they specify this:
When compiling each of these types of applications, you should include
the MarshallingSupport class into the main application and
sub-applications. You do this with the includes compiler argument, as
the following example shows:
-includes=mx.managers.systemClasses.MarshallingSupport
However, from what I can tell, MarhsallingSupport wasn't included until the 4.x releases.
Looking at the mx.managers.systemClasses package for 3.5.0.12683 and 3.4.1.10084 shows no reference of MarshallingSupport (see svn here and here)
This is also true for 3.6a (download of SDK available, but can't find the source).
Am I missing something? How am I supposed to include this class in the 3.x sub-apps, when it's not available?
see http://help.adobe.com/en_US/enterpriseplatform/10.0/AEPDeveloperGuide/WS8cbf8723eeed7311-4cca458e1328d74a115-7fff.html
Like module bundles, there are no special compilation requirements. You can build the
application bundle SWF in any way that is convenient. Note, however,
that application bundles must include marshalling support.
This is automatic with Flex 3, but with Flex 4 you must force the inclusion
of the MarshallingSupport class in your SWF.
For Flex 4 this can be
done by referencing the MarshallingSupport class in your application
code (as in the previous example). You can also explicitly force
inclusion of the MarshallingSupport class on the mxmlc command line
using the following option:
-includes+=mx.managers.systemClasses.MarshallingSupport
I am trying to run my Flex project, however on runtime I get the error:
VerifyError: Error #1014: Class mx.core::DesignLayer could not be found
So I have added an import statement for the Design layer class: import mx.core.DesignLayer, and now I get the error on compile:
Definition mx.core::DesignLayer could not be found
What is DesignLayer? Why it could not be found even tough I import it?
Thanks.
You are probably building new functionality with an old SDK. Or perhaps you are reusing a third-party component that was built with a newer SDK inside you application built with an older SDK.
In either event the DesignLayer class was introduced in Flex version 4, as stated in the docs. So if you're building your application with some flavor of Flex 3, it makes sense the DesignLayer class can't be found, simply because it isn't there.
Go have a look in the framework's source code at [sdk-path]\frameworks\projects\framework\src\mx\core. In Flex 4+ you'll find the file DesignLayer.as there. Not so in Flex 3.
In the simplest of Flex Projects, create an MXML Flex Module and then load it using the ModuleManager. No problem. Create an ActionScript class that extends Module and then configure your project to compile that into a Module. Load this new module instead. The project compiles, but crashes when running with the following error:
"Error: Could not find compiled resource bundle 'containers' for locale 'en_US'."
I believe the compiler is failing to compile the required class definitions into ActionScript only module, while it succeeds for the MXML module. I can see that my skeleton MXML module is slightly larger than my ActionScript module (66KB vs. 45KB).
How can I resolve this problem (if that is indeed the issue)?
A good approach in these sort of situations is to use -keep-generated-actionscript for two projects, one with the mxml approach, and one with the actionscript approach. You can then compare the code to see what might be missing from one project, but included in another.
Have you tried adding an explicit reference to [ResourceBundle("containers")] to your ActionScript project class? The mxmlc is different to the compc compiler in behaviour for many valid reasons.
I was having this same problem when compiling a library swc. I was able to fix it by adding the following section to the projects projectName-config.xml
<include-libraries append="true">
<library>${flexlib}/locale/{locale}/framework_rb.swc</library>
</include-libraries>
This forces the compiler to include the framework resource bundle for the specified locale.
for me the issue was finding out which project - in my case a library - and which class in this library caused this behavior (I needed to realize my last changes - no info from flashbuilder). Then applying the following attribute to the class:
[ResourceBundle("containers")]
public class IpChecker {
...
That did the trick.
As you know, we could build a RIA application based on flex. Also, we could build an desktop application based on AIR. I have a question, If we want to build web & desktop application simultaneously. Could we use the same codes to ship our production to web & desktop?
If you design your application for it, you should have no problems in sharing 99% of your codebase between your Flex and AIR builds.
You will need a separate application MXML for the Flex / AIR versions as AIR uses a WindowedApplication and Flex uses Application
You will need to abstract your usage of any AIR-only APIs. That is, any class, property or method marked with the AIR-only icon (
) in the Online Documentation. You might find this process easier if you are using a Dependency Injection container like Swift Suspenders.
Alternatively, you can split your service definitions into two different source trees. This would result in your AIR project and Flex project sharing one source path, but also having their own source path. This way, code that accesses com.application.MyService would be shared across AIR and Flex but the implementation of com.application.MyService would differ depending on which 'service source path' was being used.
You may find it useful to configure each build with a compiler flag like -define+=CONFIG::AIR. This allows you to use conditional compilation so that you can compile the same file for both builds, but include specific code for the AIR build.
Here is an exmaple of conditional compilation:
public function getMyService() : IMyService
{
CONIFG::AIR
{
return new MyServiceThatUsesAnAIROnlyAPI();
}
return new FallbackServiceForFlex();
}
Unfortunately there is no way to 'negate' a conditional flag (ie. !CONFIG::AIR) so you either need to be smart about your usage of it, or include two flags (CONFIG::AIR and CONFIG::FLEX)
I'm surprised no one said it yet, but this is how I would do it:
Create a library project. this project will include all your
shared code.
Create a Flex project for web deployment
Create an AIR Project for AIR deployment
Both the Flex and AIR projects can reference and use code in the library project. The AIR project can use AIR specific functionality without affecting the web project.
If you need to perform different actions differently based on whether using the web project or the AIR project, you can create interfaces in the library project and implement them in the main project to use the respective APIs.
yes, you can do it.
there are some conditions you have to control in code.
Keep in mind, if the application is also a flex app, then it will be a single window app.
for every project I make needing this I create 3 projects
code base (the main control is a group or a canvas)
flex exporter => when you build this you will end up with a flex application
it has a control from #1 inside the main application
air exporter => when you build this you will end up with an Air app
it has a control from #1 inside the main window.
I have compiled a CSS swf file which includes embedded skins for my Flex application. In our download product, this CSS works fine. On the web, a non-Flex container is loading the Flex application, and the CSS fails silently.
When the application is debugged, the following runtime error can be seen in the trace output, but is not raised as an exception.
method not implemented mx.core::IFlexDisplayObject/mx.core:IFlexDisplayObject::setActualSize()
over-binding 0 in GlobalStyle__embed_css__319796825
accessor not implemented mx.core:IFlexDisplayObject::measuredHeight
over-binding 0 in GlobalStyle__embed_css__319796825
accessor not implemented mx.core:IFlexDisplayObject::measuredWidth
over-binding 0 in GlobalStyle__embed_css__319796825
method not implemented mx.core::IFlexDisplayObject/mx.core:IFlexDisplayObject::move()
over-binding 0 in GlobalStyle__embed_css__319796825
Update
Now that I've determined the actual problem, I've editted the question to be more useful and direct.
The non-Flex application is using content from the library with the same class name as the Flex skins embedded in the CSS swf. Because Flash looks to the most global swf for class definitions, it is using the classes defined by the non-Flex application.
Because this content does not extend UIMovieClip, it is causing the StyleManager to fail. Due to potential security errors, Adobe has wrapped most of this process in try-catch blocks to supress expected runtime errors.
Rename the classes used by one application or the other in order to resolve this issue.