My Australian weather application has grown so large that the activity load time is becoming irritating. I am therefore trying to optimise it.

One of the characteristics of the app is the large amounts of historical data that are hard coded as variables but rarely accessed. I therefore want to place this data such that it is only loaded when it is actually used. There are a number of options for this, including:

1. Place the data in a page-level script, separate from the main page but in the same activity. This is what I do currently on the assumption that it is only loaded when that page is accessed, not when the activity is first accessed.

2. Place the data in a page-level script, separate from the main page and in a different activity. This would definitely mean that it is only loaded when that page/activity is accessed, but it would be a bit messy and so I only want to do it if my assumption above is incorrect.

3. Place the data in a number of panels and then access it as required using eval(). Again, this would be rather messy as the amount of data would mean that I would have to use multiple panels. Also, I don't understand when an eval() is actually evaluated (when the page is accessed, when the activity is accessed, or when the code is executed).

The overall issue here is that I don't understand what is loaded into memory when, particularly in terms of page scripts vs activity scripts vs eval().

Any thoughts?

You can store it in a "library" and initialize when needed.

Wait for Lyndel if he has any info about the loading and memory mapping. I'm also interested in it.

Or you could store it somewhere on the web and access it only when needed.

Found something that could help here and everywhere:

feature=player_embedded#!

It's a video discussing javascript speedup and how scope is treated in javascript.

I use panel labels and eval() quite often.

Here's is an example of panel label content defining 2 fields and a function.

var toReturn = {};
toReturn.field1='Hello';
toReturn.field2='World!';
toReturn.doSomething = function(){return (this.field1 + ' ' + this.field2);};
toReturn; // eval returns the evaluation of last statement which is the object you to return. See Mozilla documentation.

// Now, use the thing.
var evaluated = eval(CF.widget(tags to get to panel above).label);
System.print(evaluated.toSource(););
System.print(evaluated.doSomething());

Note that you can assign null to evaluated variable and all evaluated stuff is cleaned up.

You can also use utilities from files section posted by Rusty Fobe to set/restore objects/arrays from System Globals (System.setGlobal()/getGlobal()).

Thanks Lyndel and BluPhenix.

I've now tried all three options that I identified, including eval(), and they all had similar load times. I then removed the historic data altogether and (surprisingly) it still didn't reduce the load times by much. In other words, the large amounts of fixed data are not what is causing my problem.

I'm now going to explore different widget possibilities (I literally have thousands of widgets in the application), with the options including:

1. Different widgets for different purposes, with fixed positions, sizes, etc and controlled by turning visibility on/off. This is what I currently do on the assumption that turn visibility on/off is more efficient than moving/re-sizing/etc widgets.

2. The same widgets for different purposes, controlled by moving them around, re-sizing them, etc. The idea here is simply to reduce the total number of widgets (and hence load times).

3. Dynamically created and destroyed widgets. The idea here is again to reduce the number of widgets when the activity is first initiated (and hence load times).

I thought that the video that BluPhenix pointed to was interesting but dealt with a different problem than that which I am seeking to address (i.e. run times rather than load times). For me, load times are a major irritant of the Pronto and I don't understand what is good practice and what is to be avoided.

Good practice is to limit number of widgets - search for post by me about widget caching, as well as the number of objects (yes, a function is an object) that you create.

Also, load/compile time is affected by length of names and embedded comments in the script. I suggest that you also have a look at the ProntoScript site (Philips) with regard to the new PDF and examples they posted on building ProntoScript libraries as they have provided Ant Build file for using the Yahoo Javascript compression tool. This will save you plenty of load time.

FYI, I use a different compression tool that yields very similar results.

Again, a search on compression of this forum should point you to the tools that I use (I think it is ShrinkSafe by DoJo).

Guy Palmer,

I think that you'll be much better off creating your widgets on demand. Currently, you are building a huge name space and rendering thousands of images that are not likely to be used.

While it will be more expensive to build a given widget dynamically than to flip visibility, it is much cheaper to build a few on demand than building thousands on speculation.

You may be able to define a small set of prototype widgets. This might allow you do develop "skins" by re-defining the prototypes.

Ok, I'll try my option 3 - dynamic widgets - and report back.

I've now moved the majority of widgets from static to dynamic. Not surprisingly, load times have improved a lot (50-100%). More surprisingly, run times within the application have not noticeably (i.e. to the naked eye) worsened and, indeed, some aspects seem much quicker (e.g. removing widgets rather than making them invisible). So, that's all good.

But there is a big problem: dynamic widgets are always placed right at the front when created, and I'm pretty sure that there is no way to move them backwards. This is a real pain because it means that any widget that one wants placed in front of the dynamic widgets a) has to be a dynamic widget itself and b) keeps of having to be destroyed and re-created to keep it at the front.

For example, I use a whole bunch of widgets to draw graphs and have grid lines which have to sit in front of the graphs plus a 99% transparent button sitting in front of the whole thing (to hide the graphs when pressed). All these latter panels/buttons functionally exist all the time and never move or change but technically I now have to keep destroying and re-creating them.

Email Belgium and request Z-Order capability. I'd love to have it as well.