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?
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
Interestingly enough, the RADAR report I filed last year that reported the bug in iOS6 that started all of this has been marked as “Fixed”.
I’ve worked with the desktop versions of Xojo (and it’s unnamed ancestors) but I’m new to WE. I’m testing with iOS 7 beta now and I’ll just say I hope (and assume) that Xojo are testing with iOS 7 already. If not, chop-chop.
From what I’ve seen so far, we’re going to wait for a few more betas before we begin testing.
Yeah phones need to NOT crash all the time
I’ve been playing with the Beta for iOS 7 and without going into detail, I can definitely say there’s a fair amount of polishing to be done before it would even be worth testing. Besides a number of UI things that need to be fixed and tweaked, I have a number of apps that start rending funny and working wonky. That’s what I get for being impatient I suppose…