Hi all,
Anyone know how to get the total weight of the client-side web app?
It is not simple, because Xojo uses dynamic loading. I looked in the Chrome developers tools, but I have not found.
Greetings
Olivier
If you have Firefox, install the Web Developer Toolbar and use it’s Document Size function (under the Information menu). It gives you the compressed and uncompressed sizes of everything - html, css, js, images, etc.
See this article for more information.
Thank you Jay.
I had already tried, but apparently it does not take into account the dynamic content, only the initial content of the page. For example, you can add tens of webContainers or webPages (as and when the user uses the application), not close, the specified size will not change. I’d like to see the evolution of this size (for mobiles).
To add to the dilemma, we only include the parts of our framework which you actually use in your project. For instance, if you only use labels, we don’t send the code for controlling WebMapViewers.
Like many of my answers, it depends on your project.
p.S. - try using safari or chrome web inspector. It’ll show you everything in the DOM. The thing it does NOT show you is javascript code that only exists in memory.
Well, one idea is to use the Net function of Firebug to monitor the cumulative size of the requests as you are creating/embedding controls. It’s not exact, but it should give you an idea of how much data is being added to the page. Use this in combination with the Document Size from above for an approximation of the total footprint.
[quote=95566:@olivier vidal]
Anyone know how to get the total weight of the client-side web app? [/quote]
Well since E=mc^2 you can actually detect the change in weight if you measure the client computer VERY VERY VERY VERY precisely since you end up shoving electrons and therefore energy to it (although I doubt you can get a scale that precise)
You can do the same with an elastic as you stretch it - it gets ever so slightly heavier (but man do you need a good scale)
But I doubt that’s quite what you meant 
The task manager of Chrome is impressive. But the data are fanciful…
For EEweb, it indicates for example more than 150MB, at the opening … In clicking a little in the listbox, one quickly reaches 300 or 400MB.
Apparently, the browser need to reserve a lot of memory, much more than the actual size of the web app. Even the very cleaned homepage Google takes 80 Mb in the browser!
Finally, it is Internet Explorer that seems to have the most suitable memory analysis tool!
it looks awesome. it is possible to see real-time the global memory use, the memory use of each object etc… Especially, it is possible to take snapshots to see the evolution of the memory use between each snapshot, to see the number of creation / destruction of objects between each snapshot, etc…
The IE profiler also raises another point quite clearly (I have suspected it for a while). Xojo has javascript listners on all sorts of things (understandably) but the one that concerns me is that fact that it listens for mouse move. Looking at the framework.js it looks like it doesnt send data back to the server unless it has to but the fact that the function gets called will be putting some strain on the browser so would it not be a good idea to be able to disable the mouse move event in the framework if you are not using mouse move events within your web app?
I believe the Xojo devs have been clever enough to only implement events which are used/implemented by the end-developer in the Xojo IDE…at least I am hoping. Otherwise it would definitely be an excessive browser strain, not to mention data-waster for mobile devices.
Looking at the framework.js code it appears to only be sending when it needs to (see below). I dont use mouse move anywhere in any of my apps but this function still has a listener attached and is being called.
Xojo.input.move = function (event)
{
event = event || window.event;
if (Xojo.input.target !== null) {
Xojo.input.setLastEvent(Xojo.input.target.object(),event);
if (Xojo.input.lastCoordinates.length > 0) {
preventEventDefault(event);
}
return;
} else if (Xojo.input.pointerTarget !== null) {
var control = Xojo.input.pointerTarget;
Xojo.input.setLastEvent(control.object(),event);
if (Xojo.input.lastCoordinates.length > 0) {
if (control.implementedEvents.indexOf('MouseMove') > -1) {
Xojo.comm.triggerEvent(control.controlID,'MouseMove',Xojo.input.mouseEventData(event,Xojo.input.lastCoordinates),event);
}
var handled = control.mouseMove(event, Xojo.input.lastCoordinates);
if (handled === true) {
preventEventDefault(event);
}
}
return;
}
};
Oh my… The javascripts should be generated dynamically to be efficient, in a modular fashion, and pieced together when built into the final executable. Perhaps they have some sort of mechanism they’re working on behind closed doors? Greg’s always busy helping around here and might like the suggestion. I know they have a lot on their plates right now, but that would be a #1 on the wish-list for most developers most likely to ensure efficiency and reduce server/browser load. Plus, mobile site users would greatly appreciate it since most companies no longer offer unlimited data (of 4G quality or higher anyway), and the ‘light-weight’/optimizations could be another key selling point for web-edition.
So here’s the thing. There are a lot of method that xojo programmers like to call which expect to have the current mouse x and y coordinates available. I’m not saying that there isn’t room for improvement here, but the way the framework currently works, MouseMove events are always captured.
Greg, here is the thing, I never use anything that needs mouse x,y so the event should never be needed. Looking at the code it doesnt appear to do much else other then deal with the mouse move so it would not be difficult (I know Greg cant comment on this) to use a little bit of jQuery to remove the listener on the mouse move thus removing the load etc.
Do me a favor though… Enter a feature request in feedback. When we’re thinking about more optimizations, that’ll be the time to investigate this again.
Keep in mind that If you do that, you may affect the behavior of the framework in unexpected ways.
There’s always room for improvements in everything. I think the web-edition is very stable and took a lot of planning and hard-work. You’ve done a great job. I’d rather it work, than not, and improvements come in waves 
Thanks Greg for hearing our concerns! I’m working on some payment controls and I have to say that the WebControlWrapper class has come quite far since the first beta release (think sometime around 2012r2.1…don’t quote me). I’m having some issues with HandleSpecialURL though since it’s not behaving as it does when I load the same code in Real Studio. Not sure if the handle methods have changed or it’s a bug, but the standalone web apps terminate after handling the special urls…
I didn’t even think of that nate! That would be simple as pie from the developer’s end using a function such as:
function removeEventHandler(elem,eventType,handler) {
if (elem.removeEventListener)
elem.removeEventListener (eventType,handler,false);
if (elem.detachEvent)
elem.detachEvent ('on'+eventType,handler);
}
I use that code to disable button clicks and set their ‘image’ to a more visually pleasing disabled image (custom buttons). Will have to investigate with Xojo webapp controls.
:-((
For webControlWrapper too?
The problem of Matthew is also important.
Regarding the mouse move event handler, I have tried to disable it using straight javascript and it appears that Xojo somehow reinstates the handler on each page load so I cant put the javascript late enough to be sure that the framework.js has loaded and the handler is in place before removing it (not without a whole heap of js). So as a simple test to see if it makes much difference I commented out line 1179 in the global/framework.js which is where the handler is added by the Xojo framework. I have tested network, cpu and memory load with and without the event handler in place and moving the mouse all over the screen and whilst the event handler is being called a lot, it does not appear to make any difference to the browser, bandwidth or load on the cpu, memory or network. So I conclude that this is probably ok as it is although I have not done the same test on a mobile device for cpu and memory load but I did put a packet sniffer on my lan when using my ipad, iphone and android devices and moving my finger around the screen did not appear to make any requests back to the server.
document.onmousemove = Xojo.input.move;Fwiw, MouseMove events don’t fire on most mobile devices…