Connection drop offs, local storage...

Targets Web
1

Hi All,
I was wondering if anyone might have encountered this or could offer some help.
I have a POS ( loyalty system ) web app running with 42 cafes and 2000 customers using it a day, 7 days a week.
Each cafe has an iPad sitting next to their till with the program running where customers enter their details.
I’m experiencing session drop offs where the app needs to be relaunched. I’m assuming it’s a client internet connection thing
but I don’t know for sure.

Lets say it IS a client connection issue, I’m stuck and can’t think of a way to handle this. Ideally the app would switch to operating locally
until the connection was resumed, then upload collected data and carry on. I’m assuming this could be done using Local Storage and
Javascript but it is beyond my Javascript skills at present. Has anyone played around with this ? Is it a viable path to head down ?

Routers, internet connections and wifi around the country (NZ) has been a mission in rolling this app out and is proving the achilles
heel of a web app due to the necessity of a constant reliable connection. Has anyone else encountered this or have ideas about
dealing with poor connections.

The problems not going away any time soon and of course the APP gets blamed. Trying to tell clients their wifi isn’t reliable
is not what they want to hear.

Any help appreciated, thanks.

2

Because Xojo web apps have all of your logic on the server, what you’re asking for really isn’t feasible. Functionality is predicated on a connect to the server.

Now it could be that you are maxing out the number of connections. It’s set to 100 by default, but each session can use between one and four connections. You could try increasing the number of connections either on the command line (for a standalone app) or in the App.Open event. The maximum number is dependent on memory, so you’ll need to figure out how much memory a typical session uses and how much you have available.

You may also want to consider a load balancer with several instances of your app running behind it.

3

Another possibility, you could also make a native iOS app which talks to a xojo web app using an API. That would allow you to run in offline mode when connectivity is sketchy. That’s how the app for the annual Xojo Developer Conference works.

4

Thanks Greg,
Yes I’d wondered about that 100 connections. The App is on Xojo cloud maybe I’ll try bumping it up in the App Open event. I’ve watched the App.SessonCount and it looks fine but if a session can have four connections then that might cause problems. I’m also keeping an eye on XCtop-Dev and memory seems fine. How would I figure out how much memory a session uses ? I don’t think I could glean this from XCtop.

Yes the IOS app seems like the next step short of finding any other solutions.

Thanks

5

Could you tell me the syntax for this to put into the App.Open event please. I can’t find it in the docs.

Thanks. B

6

[quote=418469:@Barney Hyde]Thanks Greg,
Yes I’d wondered about that 100 connections. The App is on Xojo cloud maybe I’ll try bumping it up in the App Open event. I’ve watched the App.SessonCount and it looks fine but if a session can have four connections then that might cause problems. I’m also keeping an eye on XCtop-Dev and memory seems fine. How would I figure out how much memory a session uses ? I don’t think I could glean this from XCtop. [/quote]
First of all, stop using XCTop. The IDE itself can give you those statistics now and XCTop is very CPU intensive.

Your session memory footprint can be estimated by looking at the amount of ram that the app uses when it first starts up, subtracting that from the amount in use at any given time and dividing by the number of active sessions. It’s a good starting point.

In terms of the open event, you should be able to add items to the args array that match the command line options. The only two that are valid for cgi (Xojo Cloud) are MaxSockets and MinSockets. To set one, just append

MaxSockets=300

To the end of the array.

Seems my recollection was incorrect though, MaxSockets defaults to 200, which should be sufficient for 42 sessions.