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.
