I am working for an embedded project, UI developed in QML and backend logic developed using DB/other system calls in C++/Qt.
Which is the best approach to deploy qml files?
Does It adding to .qrc (as resource) and compile to executable application?
or
Load QML files from import folder (QML files will be deployed)?
or any other suggesion?
I have around 200 QML files.
QML files in the file system
Files are stored without compression and encryption
Faster to build but slower to deploy
Stored without compression so they take more storage space
Easy to do UI changes on the fly on target (just edit QML and restart)
QML files in the resource file
Resources are compiled to the binary file making the executable file size bigger
Slower to build but faster to deploy.
Takes less storage space because resources are compressed by default.
Because the executable size is bigger the program takes more memory when running.
You can't do changes to UI without re-compiling
See from the link the following chapter Managing Resource Files with the Qt Resource System for an example of relative path referencing.
I don't have any strong opinion but here some of my thoughts:
If memory usage is an issue then you might go without embedded resources and make sure you use dynamic loading of components as much as possible. In the development phase it's easier to go without embedded resources. If it's a customer project I would do the customer delivery as qml files embedded. This prevents the customer from tweaking the UI code themselves.
Related
I'm a little bit confused about the qtquickcompiler, the JIT qml caching and what is available (and what is not) in the open source version of qt 5.8 (respectively 5.9).
Basically, I want to protect my .qml and .js files from being readable in my release build. I started a new example QtQuick project without editing any code. I followed these instructions and added the CONFIG += qtquickcompiler in the .pro file, but it has no effect.
My .qml files are built into the .exe (on Windows), but if look in the executable, e.g. with notepad++, I can still see the source code of the .qml files.
On the other hand, if I don't use the QRC for my .qml files, .qmlc files are created for every of my .qml at runtime. These files are not (easily?) readable. But I don't find a way to use only the .qmlc files without shipping the .qml files in my build (and I don't think it was meant to be like that).
Coming to my question: Is there a way to protect my .qml and .js files with the open source version of qt? And what is the difference between the qtquickcompiler and the new JIT .qmlc?
Updated answer:
Since Qt 5.11, the qt quick compiler is also available in the open source version:
CONFIG += qtquickcompiler
See https://wiki.qt.io/New_Features_in_Qt_5.11
No, it was going to be, but then they gave up on those plans for the time being and replaced it with the caching thing.
I don't think you will be able to reuse .qmlc files on another computer, as IIRC they are not architecture portable.
In the future, it should be possible to pre-compile .qml to .qmlc ahead of time and bundle those into the application binary.
If your files are on the file system, then there is no way to protect them, from being read, reverse engineered, or tampered with.
With the compiler, the QML code is translated to C++ code, which is then compiled to a native binary. Also, last time I checked, if you go for the compiler, it is an "either / or" situation, if you use compiled qml you can only use compiled qml, so no mixing with regular qml files. It is also ahead of time, and requires a commercial license.
The qml caching in contrast is just-in-time (possibly ahead of time in the future), doesn't require a commercial license and doesn't come with the limitation that prevents you from using regular qml files. I am not aware of the implementation details, but it certainly is not qml code translated to C++ and then compiled, as it happens on the client side and doesn't require having Qt or even a C++ compiler installed. It doesn't really sound like bytecode either, as IIRC it is not binary compatible between platforms, it is more like caching the qml file processing result to avoid on doing it every time.
As outlined in this answer, with some extra work it might be possible to implement a decent amount of protection, for example encrypted QML files or binary resources, but I still haven't dug into it.
Lastly, if you set compression for the qrc file with a low threshold, it will somewhat obfuscate the QML code in the executable binary, but even so, it is regular zip compression, so if your code is really worth stealing, it will not really prevent that, just make it a tad less trivial.
Is there a way to protect my .qml and .js files with the open source version of qt?
Not yet. Up to (and including) 5.8 you'll need to buy a license in order to use the QML compiler.
And what is the difference between the qtquickcompiler and the new JIT .qmlc?
That the compiler will turn QML into C++, which gets then compiled into your application. The .qmlc files are a cache generated by the engine to avoid parsing / optimizing / etc. the same files all over again. Yet, they're a cache -- you'll need to original source around in case they don't get used. At the Qt Contributors' Summit 2016 there have been some discussions about how to streamline and integrate the compiler with the cache, but so far nothing exists.
Coming to my question: Is there a way to protect my .qml and .js files
with the open source version of qt?
Yes, of course,
look at my answer:
https://stackoverflow.com/a/40861056
You can use an encripted resource file, an decrypt it in execution time...
I do that in all my projects ...
Is not a trivial job, but works fine.
Qt's resource system lets you build an executable that has resources (.qml's, images...) embedded inside it. I'd like to load the files from the filesystem instead, and ship them alongside my executable. Is this a technique supported by Qt? Any gotchas? Any advantages to one way or the other?
Qt doesn't limit you in what you can do here. It's your choice. Qt's resource system is there if you want it, it's not forced down your throat. Not using it doesn't make you automatically wrong.
If you want to deploy files along with your application, go for it - if it makes sense for your particular application.
My personal preference for small (<0.25GB) applications is for a nice monolithic portable executable on Windows, with everything inside, that you don't have to install if you don't wish - mimicking how an app bundle would be on OS X.
The portability helps, as does the slightly stronger locality of reference: most filesystems will attempt to keep a file's blocks together a bit harder than they do for files that merely are in the same folder.
If there's any utility in power users tweaking the contents of the deployed files, then certainly using the files over using resources has advantages. You could also use the resource system as a fallback for files that are missing - that way a user could provide a replacement file optionally, if it's something you could use.
To make it short: If it is applicable for your application and 'business model' it is ok.
Besides being supported by Qt using QFile (for example), Qt's resource system has some advantages:
compression (ZIP)
simple usage in the application
no care about missing files (typically)
If you mind adding all resources to the executable will not work for you and you want to seperate them, look at the option of seperate (binary) resource files with Qt.
In my ASP.NET MVC application, I want to update the contents of a css or js file which is embedded inside my dll at runtime, without restarting the application.
My application takes a long time to restart, so in development I'd rather not wait for minutes at a time to see changes in js or css.
I think Embedded resources are not meant to be changed in the runtime at all. It is almost same as you cannot modify the bytes (compiled from your source code) within your assembly at runtime. You may consider a different architecture for your Application so that you won't need to update your embedded resource at runtime. Especially for JS and CSS, they can be added in the runtime and they can be served by your server without any need to be embedded.
Anyway, I understand that you may have the need to embed the resource and so, here is the link I found, maybe useful for you: Programmically embed resources in a .NET assembly
I've been developing a game using Silverlight 4 and silversprite (http://silversprite.codeplex.com/)
This game is HEAVILY content dependent, using a lot of audio and images. My content folder is around 90 mbs worth of stuff.
And because of that, my XAP file is around 60 MB, and takes 5 minutes to download from the website before any user can start playing.
I am using Visual Web Developer 2010 to create my site and load the XAP. Is there a way where I can take content out of my XAP and put it in my ASP.net site project? Or perhaps upload my content files to the site's storage?
This would make my XAP file much quicker to download.
Anyone have suggestions?
Thanks!
Yes, include in your XAP only content you need for the initial screen. Place other content you need in other XAPs (if you need to and understand the manifest xml) or just plain zip files would do. Perhaps a Zip for each "Level" or whatever.
You can download the Zip with WebClient and then use StreamResourceInfo and Application.GetResourceStream to access content in the zip file.
This blog although aging a little now still carries the basic idea and is still fundementally the current technique to use.
Absolutley its called Application Library Caching. Ive used it very successfully its now a standard operating procedure, particularly nice is its application with resource assemblies.
straight from msdn ...
Resource files are typically any non-executable data file used by your application, such as image, audio, and video files. A resource file can also have specific meanings in certain contexts. For example, in the context of application localization, resource files refer to .resx files, which you can deploy in localized satellite assemblies.
it continues with some really useful info
With Silverlight, you can deploy
resource files in the following ways:
•As individual files in the
application package.
•As individual files that you retrieve
on demand.
•As files embedded in an assembly in
the application package.
•As files embedded in an assembly in
an external library package.
•As files embedded in an assembly that
you retrieve on demand.
which is what is suggested in the other answer(s)
We have several fairly large JavaScript files embedded into a single script resources DLL. This is then consumed by multiple projects by way of a reference and page includes via the ASP.NET script manager. This keeps things nice and neat within our ASP.NET pages and requires very little work to integrate into new projects.
The problem is that some of these script files are quite larger (approx 100KB) and take time to download. By running minify on them before embedding this is reduced down a lot (around 70KB) but not enough. What we would like to do is GZIP the files before they are embedded. However, just gzipping the files causes syntax errors as the content is not unzipped. There is a content type "text/javascript" applied in AssemblyInfo when the resource is embedded but we can't find a way to specify content-encoding.
Is there any way to make this work without having to write a httpmodule/handler (which would mean changing the config for all consuming projects)?
Okay, so it looks, from many different attempts, an absence of answers and a lot of Google searching, that the HttpModule is the only way to approach this. In an attempt to keep this easy to configure I've setup an HttpModule inside the same dll containing the script files as below.
Simplified DLL Structure
\ScriptMinified\*.js [Embedded Resource] (Minified Only)
\ScriptCompressed\*.gz [Embedded Resource] (Gzipped and Minified)
\ScriptDebug\*.js [Embedded Resource] (Raw uncompressed and commented)
MyScriptManager.cs
MyHttpModule.cs
The only additional work is an entry in the consumer's web config to enable the module. Plus I've made the initialize call, in MyScriptManager, that includes the script tags, detect the presence/mode of the new http module and serve gziped, debug or minimized versions as required. This means we don't have to recode or configure any old projects for them to work so achieves much the same result.