Web Edition basic client-side operations

In the short time I’ve been using xojo (and the time I tried out real studio) I came across numerous solutions to reduce lag. WebControls, canvas etc are honestly enough .

Mobile is a whole different world and again, honestly, having a specific interface for mobiles is necessary. Why? Well, that’s how every technology around has been doing it. It’s not only about lag, it’s about the right way to display information on the screen. The webapp sample available on xojo is not meant to be used on a mobile even though it can be.

I think that studying the right GUI for each platform is important and usability can be largely improved through better GUI design alone. Example: take your iPhone or similar and go to mobile.nytimes.com; There are not so many “buttons”, “effects” etc being displayed and everything is “sized” in the screen, easy to read etc. The interface present in mobile.nytimes.com can be easily replicated with xojo, no special care needed (I think).

A better example is Facebook mobile site. It’s a real web app (not like nytimes which could be classified just as a site) and it clunky even though we are talking about Facebook depending on your connection and iPhone. Anyway, it’s healthy to aim for perfection and light speed results but evaluating reality and using respectable companies as examples (Facebook) shows that xojo is perfectly fine.

btw, for very specific cases where realtime response is necessary you can just use a regular javascript control from somewhere else. Maybe the “including” process could be made wizard and hassle less but it’s there and can be used.

Another solution could be an optional “download a plugin” that the browser could offer the user to improve performance but that has clear security issues and browser compatibility etc.

A good example of how easy it is to have responsive and beautiful controls is http://www.chartjs.org. I still didn’t use it but you only need to create a wrapper class to get your data and place it in the chart. Having all data objects compatible to JSON makes it so easy that I can’t describe… Anyway, again: xojo is fine, just plan well your architecture and patterns and it will work well.

Some development tools allow you to enter the code that will run either on the server or on the client, as WebDev.

This may be an example to follow for Xojo.

Just so you know… for this code to execute, there still needs to be data transfer between the browser and server (or vice-versa) where each of those lines are (assuming they are to execute in order).

[quote=60057:@Derk Jochems]Re-creating controls that are already implemented is not allowed i think. But it would be great if each control can add javascript that is send to the browser wich gets executed if for example a button was pressed or a slider has moved…
[/quote]

Of course it’s allowed. You just don’t get the benefits of WYSIWYG editing in the IDE when you use such custom controls.

unfortunately this is a duplicate of an much older ticket, <https://xojo.com/issue/19486> that has been decided not to implement. I still disagree with this decision, thus.

like that :slight_smile:

[quote=60075:@Greg O’Lone]
Karen Atkocius All that is why I suggested client side events written in Xojo but translated behind the scenes to Javascript and sent to the browser, if possible.
We’ve looked into this, but the problem is that you’d basically have to code in a sandbox environment.[/quote]

exactly. Technically there would be solutions. Think of Sandbox → XojoScript with Context Object (on Server). XojoScript is already compiled using LLVM, there is an LLVM bit code → JavaScript library etc, etc. But that just the technical thing. What could be the use of it? As soon as you would need to access the Context Object, the benefit would go away. So, what could be inside the Sandbox? Just one control? All controls of the page? What would happen if you manipulate a property of the control? That would need to be sent to the server to be made known there as well. While technically quite exciting, I don’t see how this could significantly help to build a responsive Webapp in a way, better then what we can to now with Xojo - maybe supplemented by an injection of single line JS to immediately enable/disable things here and there (and take care of it, not to get out of sync, keep compatible with framework and browsers…) or build entirely custom controls using the SDK.

But - thats not the point here. There are latency issues. There should be a easy and generic solution. WebSockets would ease the situation but not solve it. Having the possibility to show an client side (!) indicator of ongoing activity till the servers response reaches the browser would do. Being able to control this behaviour on a per eventhandler level (e.g. by adding a certain Attribute to it) would be perfect. The framework generating the client side JS/HTML code already today checks if certain event handlers are implemented at all and add the JS handlers accordingly to avoid unnecessary communication. At that stage such a attribute could be checked and the necessary processing for indicator being added as well.

Just my 2ct…

I’d like to add that beside the demand to indicate some activity to the user asap and some waiting indicator after some time, there is also an issue with double invocation. Users tend to redo their action if there is no visual response within a fraction of a second. Depending on what action is performed server-side, a second invocation of this may be unwanted or even a source for crashes. An ideal solution would take care of this, too: disable a button client-side till the the result of the server-side action event reaches the browser.

Do not forget to vote if you are interested:

<https://xojo.com/issue/31768>

and for this case that make webapps more responsive:

<https://xojo.com/issue/18354>

I pray that it’s finally available in 2014.R2!