I'm building a Flex/AIR application that connects to a remote server, the URL of which changes depending on the environment (development/production, and possibly others). For now, this URL parameter is hardcoded in my root application MXML file but it means I have to change it everytime I build my app for a different environment.
Is there a way to externalize such a parameter so that when Flash Builder automatically builds my app (in development mode), it uses the development URL (http://localhost...) and when Flash Builder exports a release build, it uses the production URL (http://www.mycompany.com/myapp)?
Flex compiler supports something called Conditional compilation, you an read about it here: link. The problem is that it still doesn't give you an way to check if you're exporting a release build or building for debug. Probably the simplest way to achieve that is to use ANT for compilation of the release build and use the conditional compilation from there.
Related
We plan on using SASS instead of plain CSS for our SharePoint project very soon. While testing and trying to set everything up, I ran into some problems:
We're using Visual Studio 2015 and on my developer machine I installed the Web Compiler Extension to compile the .scss-files and partial files to a regular .css-file.
That worked very nicely but the problem is, that there will be a few developers working simultaneously on the styles. I want to avoid merging the resulting css-file each time someone tries to check in something into source control (we're using Team Foundation Server).
Since there is a build running every time someone is checking in their changes, and to deploy the resulting solution to the nightly build machine, the idea was to somehow include the SASS compiler in the build definition. This way the more readable scss-files get merged and the build creates the resulting css-file to include it in the solution.
Maybe I'm thinking too complicated, but I just couldn't get that to work so far.
Any ideas how I can achieve that?
(Maybe I should also mention that none of the dev machines got any internet connection)
If you're building an MVC app, you can use MVC's bundling feature along with the SASS NuGet package. And, be sure to enable minification. There's a UseNativeMinification property on SassAndScssSettings. That way you don't need to deal with merging the css file when you get latest or check in. Reference this thread: SASS/TFS best practice
Another way is running a script (e.g with PowerShell task) on the server that to install the gulp components and then call the sass compile task to compile the SASS. Refer to Powershell build - compiling SASS for details.
Recently tried the plugin example of Qt.
It didn't work at all and I was confused as to the reason. Then found the solution on one of the forums.
Qt, Application and plugin all three have to be built with the same configuration (Release/Debug)
This works for me as I can build all three in Debug/Release mode. But if I want users to extend my application using plugins I need to provide debug build of my application. (If I provide release build, users will not be able to trouble-shoot the plugin). Qt source is available so it can be built in any mode.
I don't want to provide debug build of my application to users. Is there any work around for this restriction on build mode for plugins?
P.S. I understand users can debug with logging statements, but not sure how many prefer that approach.
This is because Qt has a so called build key which is just a string containing some Qt configuration information, this is documented in the Qt plugin Howto.
So you should just go ahead and provide a debug build of your application for the best results.
You can build debug version (to have compiled in debug configuration) and strip it out of all symbols etc.
For a normal Flash/Flex application I would include my Unit Tests in my application project (perhaps in a tests source folder alongside my main src folder). I'd then have two application entry points: the app, and it's tests.
How are people doing this for their Flex Library Projects? You know, the kind that produces a SWC file. As far as I can tell, you can't set an executable entry-point for these projects (to run the tests).
Normally, Flash Builder only allows you to use the debugger from a Flex/AIR application, not a library project. So best thing to do here is load the library into a Flex application and write+debug tests there.
Here are step-by-step instructions to be able to test your library project, with debugging/stepping enabled:
Create a Flex Library project that you want to test + debug
Create a normal, empty Flex Application. We will write the tests in this dummy Flex Application so we can utilise the debugging features.
Set the library's build-path to the 'libs' folder of the Flex Application so it builds most recent code into a swc loaded by the Flex Application.
Optionally, set the
Flex Application to 'reference'
the library project in Project
Properties->Project References, this
ensures the library code is built first.
Write your tests in the Flex
Application
Debug and run your tests: you
should be able to step through your library
source code! Nice.
Optionally, once you're satisfied your tests are all good
copy your tests back into the
library project to keep all the library's associated code together in one project. Make sure you're not including the test classes in the actual library swc.
This is how I do it anyway.
If we assume that you need an mx:Application entry point to run the unit tests, then it would seem to make sense to generate a separate application project solely to run the tests.
Would you really want to include the unit tests in the compiled SWC anyway? (For an application this wouldn't be a problem since they're, presumably, not referenced, but for a SWC library I think they'd be compiled in if they're in the folder hierarchy somewhere)
In Flash Builder Beta 1 onwards itself, you can write and execute Flexunit tests from a library project.
You can use the IDE integration feauture of FlexUnit, and select the project, folder , class or method from the context menu and use "Execute Flex Unit Tests". This will create the application file of the required syntax, run the application and show the results in the FB. You can even select from the result and run the tests are requried.
There isn't currently a way to test a library project. You must have an application as the entry point to the tests. This would be a great feature request for Flash Builder 4.
I'm using Flexbuilder as an IDE, and I'm working on automating the process of building my application.
In the process of setting up the ant build file, I noticed that there's no way to call the project using the list of dependancies that Flex builder stores - each library or library project has to be added to the flex compiler commands manually. This creates an enormous burden on the developers to update the build scripts, and makes the build process very uncomfortably fragile.
Is there an option or third party project that addresses this? Failing that, is it possible to build using Flex builder's process via command line?
This answer might be of use.
automating component libraries
I'd like to see the command-line arguments that FlexBuilder is using to compile my application. This is so that I can build them into the ANT script I'm working on. Is there any way to view the command line compilation step?
The reason I'm asking for this is that when I compile my app using Ant/Flex SDK vs. FlexBuilder my app behaves differently.
So I figured out the answer.
First of all, you can get a better idea of how FlexBuilder compiles your app by adding a -dump-config=C:\myConfig.xml to the compile arguments in FlexBuilder. This outputs an xml file containing configuration settings used in the compilation step. You can also use this file as an argument to compc or mxmlc if you'd like. Read more about it
here...
But, here's what actually solved my problem. I was using the regular old Flex SDK installed on our integration server to compile my apps using Ant. This is the free SDK you can download from Adobe's site. I then took the FlexBuilder directory from my local machine and copied it up to the integration server and pointed my build script to use that version of the SDK (and changed my path env variable).
When I compiled using the FlexBuilder version of the SDK, all was well and the strange bugs I was seeing in my app disappeared.
Moral of the story, make sure you are using the same version of the SDK for your automated builds as you use to build locally.