My objective is make the mobile version of my webapp seem as responsive as possible. Currently a round tip to the server is required to even initiate the loading state when the user clicks a button to change to another page. On slower connections users may second-guess if the click/touch was received and subsequently click the button again, or click other buttons, sometimes lots of times, which can produce undesirable results as the server attempts to respond to all these clicks. I would like to make the loading state (blank page with a spinner) appear immediately via local javascript on the page I think, then disappear on page change. I’m not sure where to start with this though. Can anyone help?
start a timer that disables the button, shows a spinner and starts your code
when you code is done, hide the spinner and enable your button[/quote]
That is still a round trip to the server (the timer.) The best solution would be entirely browser side so the user can’t use other elements while sending the request and waiting for a response.
start a timer that disables the button, shows a spinner and starts your code
when you code is done, hide the spinner and enable your button[/quote]
Yes, this is great on fast connections - I’m looking for a browser-side solution for slow connections that covers the page and shows a spinner to prevent multiple clicks/taps during that slow round trip. Beyond preventing extra clicks, this will also serve to give the user the impression of instant responsiveness and speed.
What really takes a lot of time is loading time between pages.
In some circumstances, it can be nice to have an instant transition. This can be obtained by preloading the content of several pages using the same principle as sprite sheets.
Placing several WebContainers on the same WebPage, with one in view and the others off view. Then bring each in view when needed.
Initial loading time will be longer, but then transition is pretty much instant. Here is a quick prototype for iPhone.
[quote=260682:@Michel Bujardet]What really takes a lot of time is loading time between pages.
In some circumstances, it can be nice to have an instant transition. This can be obtained by preloading the content of several pages using the same principle as sprite sheets.
Placing several WebContainers on the same WebPage, with one in view and the others off view. Then bring each in view when needed.
Initial loading time will be longer, but then transition is pretty much instant. Here is a quick prototype for iPhone.
Yes, I used to use containers exclusively and preload them all, but for my mobile solution I’m doing actual pages in order to let users use the back button inside the app.
And on slow connections, I have found that even the trip to the server to process the click event to reposition the container can take longer than users expect and produce extra clicks by users.
Oh, I was thinking I had to use pages to take advantage of the hashtag features, but I see I can go back to containers, so that’s great. Thanks Michel!
If this still doesn’t achieve the perceived responsiveness, do you know how I would go about this in a browser-side javascript solution?
[quote=260690:@Vince Goff]Oh, I was thinking I had to use pages to take advantage of the hashtag features, but I see I can go back to containers, so that’s great. Thanks Michel!
If this still doesn’t achieve the perceived responsiveness, do you know how I would go about this in a browser-side javascript solution?[/quote]
JavaScript permits a lot of things but it is usually specific.
A browser side solution that Xojo provides is WebAnimator. Correctly used, it can create pretty stunning UI effects.
Even for a WebTimer which is client side as well, there will always be need for a round trip as it is needed to get back the information to your code, which executes on the server.
You will never be able to be 100% client side in Xojo, but it is possible to minimize the number of round trips.
As an example, is there a way to execute javascript in response to a click on a button without a trip to the server? I presume it would require first getting the javascript loaded in the container/page, then getting it called onclick. I think this must be possible, just need a little guidance as to how if anyone knows.
Sure, in JavaScript one can associate code to an event. But the tricky part is that doing anything will require sending back to Xojo for your code to know it happened.
Either you write everything in JavaScript, either you deal with a round trip so Xojo can work.
JavaScript can do many things with Xojo controls. In RubberViewsWE for instance, when the user rotate the device or change a desktop browser window size, the JavaScript part of my class moves all controls where they should be, and scales them so the stay sized relative to the view. BUT when the user is finished changing the view, my JavaScript reports to Xojo the size and dimension of each control. Otherwise, Xojo would think they are unchanged and that would be chaos.
For instance, it is quite possible to disable a button as soon as it is clicked. But how will JavaScript know when it is time to re enable it ? In practice, it is much simpler to use the build in auto disable.
You could use the WebSDK to create a custom control that loads javascript onto the page that would have an event listener for clicks on the elements you need to watch. EventListener reference
