Hi - Web Edition application running on iPad/iPhone
Does anyone know if the session gets lost if a user goes from Safari to another application then back to Safari?
Thanks
Pat
Well, a quick test with my product tells me that it keeps the Session open for at least 30 seconds, and returning to Safari maintains the Session.
hmmm. Not for me.
In the iOS simulator I have the application running from a shortcut on the desktop. Swap to another application then immediately to the Web Edition app, the app relaunches.
My test was with an iPod Touch, latest iOS, if that matters. 20 minutes layer, Safari shows the Session ended warning screen.
there must be a problem with my code then.
Just tested on my iPod Touch and swapping to another application and straight back to the Web Edition app takes me straight back to the apps login screen via the app launching screen.
My app does pulse back to the server every 5 seconds via a WebTimer. Maybe that’s what’s keeping it alive.
iOS is a different beast from desktop browsers. The problem is that Mobile Safari goes into a sort of “sleep” mode when you launch another app. If it lets you come back, the allowed time is going to be really short.
Ah - so makes sense then that the session gets dropped. Anything I can do about it?
Not really.
Bugger :). Thanks for the help guys…
Suppose every language has the problem with mobile safari then…
We’ve dealt with this issue (mobile disconnects on web apps) quite a bit. We came up with some workarounds. I’ll try to post something about it this weekend…
Sorry for the delay in replying Travis - if you have any thoughts on this one I’d greatly appreciate them.
I like to know how you overcome this issue too.
We had framework hacked some of the iOS EventSource connection stuff in 2012r2 to avoid unnecessary disconnects on iOS. Although Greg took a different approach than we did (by counting errors) it appears the updated method in Xojo pretty much resolves the same problem we had in that area. In other words: make sure to use 2013r1+.
As mentioned above in the thread (a different issue but still important), you can’t control when mobile safari or frankly any mobile browser goes “out of scope” to the point its no longer maintaining active communication to your server, and thus losing your session. It’s been a while since we tried to determine what factors were involved (RAM in device, size of other apps launched, timing, etc) but the bottom line is it isn’t in your control.
We have an application where we need to take the user back to a session even if their browser went out of scope. We needed to give them ~10 minutes to keep their session open regardless of what happened with their browser. To do this, we ended up implementing our own “external” sessions that don’t expire when framework sessions do. In our database we always create our own unique “external session identifier” that stays mapped to its current web framework identifier (WebSession Identifier). We store that custom external one on the users browser via a cookie so we read it when they come back. In our database, the record for that “external session identifier” contains things like the last active timestamp and what I’d call a serialized representation of their state (what web page they were on, what they were doing).
So when new sessions come in, we look at that cookie to see if they had a prior session going with us, if it should still be valid (based on timestamp and whatever other factors), update the pairing to the new framework session that was created, and then restore their state- taking them to the proper page they were at with the proper values. That way- to the user- it is as if the session never really expired even though the framework one did.
Probably the most useful framework change we’d still want out of the box regarding this stuff is replacing the web app disconnect screen with custom HTML. We like our application to both show a friendlier message in our application’s style, and automatically retry at the root web app URL to create a new session after a bit of time. That might be the last framework hack that is still really necessary for us. Time for me or one of the other devs to make sure that is logged in Feedback! 
Sorry for not thanking you for your feedback sooner travis. Thanks! Food for thought…
Sounds very clever Travis, great solution.
With the announcement that ios7 brings multi-tasking… Does this problem go away?
It may change how long Safari happens to maintain the web app connection, but it will still stop at some point. You can see the same thing on Chrome on Android (which has ‘full’ multitasking) when the OS needs resources elsewhere…
You’ll have to wait and see. Apple is very active managing power and stuff. It’s funny, you typically don’t see this kind of issue as accutely on Android because 7 or 8 hours out of a huge battery on a huge handset is just fine. But with any browsing platform, the connection can be broken for a multitude of reasons. It may make sense for some apps to design a persistent session mechanism that can handle transitory Sessions.
Bit of a rhetorical question really :). Will be interesting when we can get our paws on ios7