I'm looking at http://github.com/openfl/swf and it looks like it requires the assets to be embedded/compiled into the resulting file.
Is there any way to load an swf run-time, and have the application interact with any supplied swf?
It looks like the neko target allows the swf to be loaded run time from the assets sub folder, however the flash target compiles the external swf into the generated swf(based on the fact that I can see the classes inside the generated swf).
Related
Is there a difference between res/ and resources/.?? If I simply create a new directory and title it resources, it is not displayed as a normal directory, seems like resources is a keyword unlike temp which shows as a normal directory.
We commonly name a resource folder res in the lib directory to hold drawables, values, layout, etc..
and then in the test directory we put sample json and other items needed for testing in resources. I'm just wondering if there is actually a difference between these?
Thanks
The test folder contains code (usually test code, unit tests, etc...) that runs on your local PC or laptop. The code compiled and eventually run using the installed Java on your machine the same way as pure Java projects with some minor differences. So basically the purpose of the test folder is to test parts of application code that don't have a dependency on the Android SDK and without using an Android device. Also on the side, there's another test folder which is androidTest, it also used for testing parts of the application but with using an Android device, meaning an actual test application is loaded on the device and it executes the tests which have a dependency on the Android SDK.
That being said, pure Java projects or code usually use resources folder and not res (as far I have seen while using IDEs). When compiling and then running the pure Java projects or code, the contents of the resources folder are placed at the root of the Java classpath so that the code being executed finds its resources there.
Android Studio or the Android Gradle Plugin seems to handle both differently (in terms of packaging them into the final aar or apk), so it is best that there is only res in main or androidTest folder and also that there is only resources in test folder.
I'm trying to make a simple application with neutralinoJS
I'm wondering how get a unique file:
.exe to windows
a binary, .deb, .rpm to linux
and a .app to macOS
Cause there is a file that runs the html/js but the source code is visible to edit
Files are visible
Neutralinojs produces portable cross platform apps. Therefore, your application files (css, js etc) and Neutralino framework files (settings.json etc) are visible from application bundle.
Whereas, they are having an idea to make a packager tool which will minify app source.
Hope it helps
In a large web application, I'm using requirejs amd modules so that the scripts themselves are modular and maintainable. I have the following directory structure
web
|-src
|-main
|-java
|-resources
|-webapp
|-static
|-scripts
|-styles
|-images
|-static-built //output from r.js. not checked into git
|-WEB-INF
During build js and css are optimized using r.js into static-built folder. Gradle is the build tool.
Now the problem: The jsps refer to the scripts in static/scripts folder and this is how i want when working locally. However when building war, I want the static files to be served from static-built folder. The important thing is the source jsp should not have to change to serve the optimized files from static-built folder.
Two options that I have are: a) the gradle build while making war should include static-built instead of static. b)include static-built in addition to static and using tuckey urlrewrite pick the resouce from static-built rather than static.
What best practices are the community following in similar scenarios?
We've setup the server to have a runtime profile (dev, qa, prod, etc) read from a system property which determines some settings based on it. When running in production profile we serve the optimized files from the WAR. In development we serve the non-minified and non-concatenated files directly from the filesystem outside the application context.
Files are structured according to the official multipage example.
Configuring serving files depends on your chosen backend solution. Here's an example for spring.
Alternatively, r.js can generate source maps and those will help with development as well.
Not sure if this question is outdated already, but I had a kind of similar problem.
I had similar project structure, but with the only difference - I've split the project into 2 modules:
one of them (let's call it service) was java-module for back-end
the second one contained only js and other stuff related to front-end (let's call it ui).
Then in Gradle build 'assemble' task of the service depends on 'assemble' task of ui AND another custom task called 'pre-assemble'. This 'pre-assemble' task was copying the optimized js files to place where I wanted them to be.
So, basically, I've just added another task that was responsible for placing all the optimized js files in the proper place.
I'm working with the Hot Towel SPA template and I'm trying to add in some data that I want to get from breeze. I have the breeze nuget package installed and the breeze script files are in the scripts folder of the site.
I can reference it by using the actual file name like the following:
define(['durandal/app', '../scripts/breeze.min.js'], function (app, breeze) {
...
});
However, this will break when my site is running in release mode and the script is actually bundled. Plus, it is really ugly and feels like a hack to put the full name in there.
What is the correct way to do this?
By default Durandal loads external libraries via normal script calls not via requirejs. Same is true for HotTowel.
e.g. https://github.com/BlueSpire/Durandal/blob/master/index.html#L31
or if your platform supports it via bundling
https://github.com/johnpapa/PluralsightSpaJumpStartFinal/blob/master/SPAJumpStart/App_Start/BundleConfig.cs#L18
Simply load breeze before requiring main.js and you should be good to go.
In my application all images, local HTML pages etc. are marked as "Build action Content".
I have just realized that there is also "Resource".
Which one should I use for images and which one for HTML pages to display in a UIWebView?
Currently I use images like this:
this.oImgLoginLogo.Image = UIImage.FromFile ( "Data/Images/ball.png" );
But in Monotouch.Dialog I see this line:
static UIImage arrow = Util.FromResource (null, "arrow.png");
But arrow.png is also marked as "content"...?
Puzzled.
What are the disdavantages/advantages of each option?
Embedded resources are embedded into the dll or exe file, and accessible from .NET reflection APIs. Content files are bundle resources and are copied into the app bundle (which is simply a directory), and accessible using file APIs or MonoTouch's Apple bundle APIs.
MonoTouch does support embedded resources, but they aren't straightforward to use from Apple-specific APIs, which are designed to use things from the app bundle. However, embedded resources may make more sense when you aren't dealing with MonoTouch-specific APIs, or when you're writing libraries that are portable to other platforms.
MonoTouch 4.0+ does support Content files in dll libraries - behind the scenes they're mangled into embedded resources when the library is compiled, so you can share it as a single dll file, then they're unpacked into the app bundle when the app is compiled.
My guess is that MonoTouch.Dialog was using embedded resources and not bundle resources because it's a library and predates MonoTouch 4, therefore the file marked as Content is a bug in the project.
In the .NET world, the difference is that during the build process a file marked as Content gets copied to the output folder, while a Resource file becomes part of the DLL itself.
AFAIK, MonoTouch doesn't includes resources into the build, because that doesn't exist in iOS, so that's why you always use Content. A final step then zips the directory with the executable and the content files into the .app file, which is how iOS expects it. The same thing is valid for MonoDroid.
The difference between MonoTouch and MonoDroid in the API exist because the idea of those frameworks is to translate, almost one-to-one, the APIs available in those platforms, instead of creating one interface that supports all platforms equally.