I am using dojo for UI in iPhone. I have copied dojo, dojox folders completely,
and it takes huge amount of time compiling in Xcode.
It is OK if i keep only the required .js files?
For example
require(["dojox/mobile/parser", "dijit/registry", "dojox/mobile", "dojox/mobile/SwapView", "dojox/mobile/TabBar", "dojox/mobile/Button","dojox/mobile/deviceTheme", "dojox/mobile/compat", "dojo/domReady!"],function(parser) {
parser.parse();
});
It is ok to include only the .js files respective to modules included above in the require function?
Kindly advice.
You will need to keep all of those files as well as all of the files that they depend upon and then the files that they depend on... dependencies all the way down.
Read up on the Dojo Build System. This will allow you to build a single file that only contains the Dojo files that you need and nothing else. It'll also minify it for you. This reduces the number of requests and the total amount of data sent when you pull in your JavaScript.
Related
When I use the Dev Tools coverage tab to search for unused CSS (instructions), will it list in its report all CSS files loaded on the page? Or will it not report CSS files with 0% coverage?
In practice, I think am seeing the latter, i.e. so far I have never seen the coverage tab list a file with 100% unused bytes. But I just want to make sure that is by design, rather than some error I need to resolve. Also, the instructions don't make it clear that certain files will be omitted from the reporting.
Coverage analyses all css files which be apply for page. You can easy check it, just create new css file, use css styles, and import/unimport this css file and run Coverage.
The compiled JavaScript output of a GWT application is divided into various files, for instance
*.cache.html
*.gwt.rpc
hosted.html
*.nocache.js
...
I know this is done with the purpose of minimizing the size of the JavaScript, which has to be downloaded by users. For instance so that a Firefox user does not have to load the JavaScript specifically compiled for IE6.
However, especially for small GWT applications it might often be faster to download a single file of say 500kb rather than make two sequential requests first for the 5kb *.nocache.js script and then for the rest of the app (cache.html files, etc.).
This leads me to the question: Is there any framework or procedure to bundle the output of the GWT compiler into a single JavaScript file?
First, you can merge all permutations in a single file by using so-called "soft permutations".
Then, you can inline your *.nocache.js into the HTML host page (e.g. using a JSP's #include directive) to cut one additional request (you might have to add a <meta name=gwt:property content='baseUrl=myapp'> where myapp is the subfolder where the .nocache. files are located).
AFAIK that's what Google are doing for their GWT apps.
Alternatively, you can run the permutation selection on the server-side if you can totally replace the selection script (*.nocache.js) with server-side content negotiation (based on User-Agent and Accept-Language request headers for instance) that can directly generates a <script> tag for the appropriate *.cache.js file (provided you use the xsiframe linker).
AFAIK, Google use all these techniques for their GWT apps (such as Google Groups). For a small app, though, I'm not sure it's worth the effort…
Also, the last two techniques work best when your HTML host page is already dynamic and therefore already non-cacheable; otherwise you're mostly moving the problem, not solving it.
I wonder whether the sso linker can be used when you collapse all properties and soft-permutations down to a single hard permutation.
Yes, but it's maybe not something you want. See this answer: https://stackoverflow.com/a/4453716/66416 to this stackoverflow question: Merge GWT generated files.
I found another way to accomplish this: Writing a custom Linker for GWT. Two examples for linkers which compile into a single JavaScript file are:
GwtNodeLinker.java from Gwt Node project
ServerSingleScriptLinker.java from Env.js project
I was just adding a single image to a GWT 2.4 application I was working on. I just put it under the images folder in the war and I had it working properly until I would compile it. Then it would get deleted from the folder. If I remember correctly, from working with older versions of GWT, you could just put an image in this folder to use it.
It just took a few minutes to convert the code to use an ImageResource, but do you have to use an ImageResource for just one image or is there another way to do this?
The class ImageBundle is deprecated, try to use ClientBundle instead.
Instead of putting the file in the war folder, which is typically generated, try putting it in a folder called public/ in the same directory as your client package. The compiler will move it then into your module directory.
And finally, ClientBundle (and ImageBundle, but don't use it) will automatically try to sprite your images where possible, and in some cases include the image in your main html download so that the user only needs to download and cache one large file instead of several files - even for individual images it can be worth it for repeat users of the page, to ensure that no caching issues ever occur.
Can someone explain to me in simple term the concept of caching in GWT. I have read this in many places but may be due to my limited knowledge, i'm not being able to understand it.
Such as nocache.js, cache.js
or other things such as making the client cache files forever or how to make files cached by the client and then if file get changed on the server only then the client download these files again
Generally, there are 3 type of files -
Cache Forever
Cache for some time
Never Cache
Some files can never be cached, and will always fall in the "never cache" bucket. But the biggest performance wins comes from systematically converting files in the second bucket to files that can be cached forever. GWT makes it easy to do this in various ways.
The <md5>.cache.js files are safe to cache forever. If they ever change, GWT will rename the file, and so the browser will be forced to download it again.
The .nocache.js file should never be cached. This file is modified even if you change a single line of code and recompile. The nocache.js contains the links of the <md5>.cache.js, and therefore it is important that the browser always has the latest version of this file.
The third bucket contains images, css and any other static resources that are part of your application. CSS files are always changing, so you cannot tell the browser 'cache forever'. But if you use ClientBundle / CssResource, GWT will manage the file for you. Every time you change the CSS, GWT will rename the file, and therefore the browser will be forced to download it again. This lets you set strong cache headers to get the best performance.
In summary -
For anything that matches .cache., set a far-in-the-future expires header, effectively telling the browser to cache it forever.
For anything that matches .nocache., set cache headers that force the browser to re-validate the resource with the server.
For everything else, you should set a short expires header depending on how often you change resources.
Try to use ClientBundle / CssResource; this automatically renames your resources to *.cache bucket
This blog post has a good overview of the GWT bootstrapping process (and many other parts of the GWT system, incidentally), which has a lot to do with what gets cached and why.
Basically, the generated nocache.js file is a relatively small bit of JS whose sole purpose is to decide which generated permutation should be downloded.
Each individual permutation consists of the implementation of your app specific to the browser, language, etc., of the user. This is a lot more code than the simple bootstrapping code, and thus needs to be cached for your app to respond quickly. These are the cache.html files that get generated by the GWT compiler.
When you recompile and deploy your app, your users will download the nocache.js file as normal, but this will tell their browsers to download a new cache.html file with the app's new features. This will now be cached as well for the next time they load your app.
Right, this is the problem I have a container (rar,zip) which contains images png's tiffs bmps or jpegs in an order.
The file extension isnt zip or rar though but uses the same compression.
I want to pull out a list of images contained within the file in the numerical order, then depending on the user decision go to the image selected.
I'm not after any code just the high level thought process/logic of how this can be achieved and how it could be achieved on iphone OS.
From what i know of iphone OS it uses a kind of sandbox environment so how would this effect the process as well.
Thanks
You can include the libz framework in your project and write some C to manage zipped data. Or you can use Objective-C wrapper classes others have written.
Your application resides in its own sandbox. You can include zip files in the "bundle", i.e. add them to your project, and copy them to the application's Documents folder to work with them. Or you can copy archived data over the network to the application's Documents folder if you don't want to include files in your project.
I don't think the extension matters so much as the data being in the format you expect it to be.
Everything I wrote above is for zip-ped files. If you're working with rar-formatted archives, you'll need to look at making a static library for the iPhone, perhaps from the UnRAR source code.