I am using the HttpContext.Current.Session.IsNewSession to decide on what page to show when my MVC4 application launches.
This works great on desktop, iOS safari.
However on iOS Chrome, every time I close the browser (actually close tabs and close the application from the task manager) and relaunch it the IsNewSession is always false.
I am guessing it uses the session cookie ASP.NET_SessionId to track this as there is a new cookie value when I close my desktop or safari.
However on iOS Chrome, when I close and relaunch the cookie has the old value - which I am guessing is the root of the issue.
So why does iOS/Chrome not clear my ASP.NET_SessionId cookie even though it should be a Session cookie and deleted when the browser is closed.
Thanks.
I suspect this is because of a design feature of many modern mobile operating systems whereby apps don't really close when you might think.
With desktop applications you have a lot more screen real estate and so it's easier to manage windows and multitask. So closing applications feels natural and necessary when you're done with it.
With mobile applications, however, there is more of a focus on the user being able to open and switch between applications seemlessly and so the concept of closing or minimising apps is abstracted away and taken care of by the operating system.
This means that when you close Chrome, it's not really closing (and may not close at all before you enter the app again). Therefore the session is never cleared.
If you force close the app then your function will work as expected.
There's no elegant work-around that I can think of for your problem. One idea is to store the time of last activity for the user and if it's greater than, for example, 5 minutes, then you can show them your startup page.
Related
I'm developing a social media site. Over the last three months, I have noticed that a few percent of users are suddenly losing their cookies on iOS.
I investigated the circumstances and found that
It is not in private mode.
One day the cookie suddenly disappears. Once this happens, the cookie disappears within a few minutes or hours, no matter how many times the user logs in.
I have tried every setting to reproduce this on my iPhone. This should occur simply by changing some setting such as privacy in chrome, but I have not been able to reproduce it.
My website sets the cookie 'expires' field to six months. Most users do not lose their cookies.
Chrome goes into the background, stops, and when Chrome restarts, all cookies from all sites disappear.
I asked the user to try another website that uses cookies and they all disappeared as well.
Cookies only disappear when Chrome goes into the background.
The nginx access log shows that no cookie was sent.
This is happening on iOS 16.
I have not tested what happens when the iPhone is initialized.
I've asked users to check what happens in safari.
Do you have any idea what the solution might be?
The frequency of occurrence led me to believe that this issue must occur worldwide, but I could not find any information on it. Probably because most people use apps instead of the browser for services that require login.
I am working on a web page, which I want to test on my iPhone. However, when I visit the website from my phone in either Firefox or Safari it is an old version of the website that opens. I have tried to clear cache and history as described here, but it is still the old website that appears. I have also tried to de-connect my Firefox account and restart both the app and the phone. I have checked in a browser on my computer and here I see the new website and any changes implemented instantaneously.
Do anyone have similar experiences with such an issue and how to solve it?
Edit 1: After a while (couple of hours) I tried again and it was indeed the new page in the mobile browser. I still don't however understand why there is latency in a mobile browser and not elsewhere, i.e. where and why is the old page cached on a mobile device even though history and cache has been cleared?
Edit 2: I have now also discovered that the same issue applies to all other non-mobile browsers than FirefoxDeveloperEdition, so this browser must be doing something the others don't.
I faced similar issues in past. It depends upon your hosting provider. Usually it takes no time to update web pages but sometimes average hosting sucks.
Try opening webpages in incognito mode/private mode.
My problem was solved by running cache-purge from my provider's SSH service.
I have a HTML page with a Download app button. When clicked by an iOS user, it redirect the users to the App Store via itms-services. The link I used here is:
window.location.replace("itms-apps://itunes.apple.com/app/id578505616");
It looks like so on a mobile browser:
Facebook/Pinterest has an in-app browser which asks for the user's consent before redirect the user out of their app in the form of an Alert box with Cancel or Open app, which Open app opens the external link. It looks like this:
It looks like this with the Alert box:
Assuming the user is using an iOS device. The expected behavior here is when the Open app button is clicked, the user gets redirected to the App Store app. However, we are seeing about a 10 seconds delay before the actual redirection happens.
See videos below:
https://www.youtube.com/watch?v=_dgh7v-IsK8
https://www.youtube.com/watch?v=_LFHeRnBFgg
https://www.youtube.com/watch?v=82Y-kj-pMyw
Notes:
I can't seem to reproduce this at all times. It is only reproducible sometimes. Sorry!
Once a device is delayed for the first time, all subsequent links to AppStores will be fast, until roughly 1 day late. Rebooting the phone and/or clearing the browser cache and/or reinstall Facebook/Pinterest does not help reproducing this.
I tried to replace the itms-apps:// link with https://itunes.apple.com/us/app/trusper-tips-tutorials-how/id578505616?mt=8, but we were still experiencing the delay from time to time.
The delay seems to be exactly 10 seconds.
Why does this delay occur? This seems like a bad user experience.
My current theory is that the problem is on the Apple side. The reason being, once the Open app button is clicked, it is out of the hand of our website, as well as Facebook/Pinterest app. I presume, once the button is clicked, iOS is handling the actual context switch from one app to another. Therefore, it suggests that either the system call actually opening the URL is hanging, or the system call opening the App Store app is?? However, I haven't been able to prove either one to be true or false. Does anyone have a better explanation?
[Edit 04/02/2015]
I can confirm this problem still exists as of today on my phone (iPhone 5S w/ iOS 8.2).
I did some further research and found this article which I think is suggesting that this is a iOS system-related bug: OpenUrl freezes app for over 10 seconds
As there is no proper documentation on how it works, it is hard to pinpoint the cause of it.
Let me advance a theory.
Opening an app from browser causes a context switch; indeed from browser to App Store. So for the very first time it'd cost some time, while in subsequent times it will open faster as it will get opened from cache.
If you consider AppStore uses Keep-alive connection between iOS AppStore in device and iOS AppStore Server for the first time socket opening in server would seem higher than the subsequent times as subsequent request would reuse the same connection.
If the app is removed from the cache then it'd again take some time for the app to open and there would be a little network delay as the app would have lost the cookie for keep-alive connection then the app would have to endure the socketing opening cost.
There are also other factors like Safari hanging, resulting in some delay. You can read how Safari can be messed up here.
iOS doesn't have garbage collection, only things like ARC (Automatic Reference Counting). Each has its own advantages and drawbacks. Sometimes these drawbacks can surface and cause some problem; nothing is to be ruled out. For example a memory leak or app-crash might leave dangling pointers.
Technically, using itms-apps should give a little advantage over plain iTunes url because itms-apps should narrow down the search; itms-apps mean iTunes Music Store-apps.
A plain iTunes URL may be a Book (iBook), Music (iTunes), App (Appstore), etc ... so iOS might have to decide which app to launch.
I hope this helps.
I'm currently hard at work developing my first Web application, and I have stumbled hard upon an issue on the iOS mobile-devices' Safari Browser.
If I create a cookie set to expire in x days (basically any cookie created, session-only or otherwise), and hard-reset the browser on the phone (as in closing the app entirely or restarting the phone), the cookie is destroyed.
Why is that? And how can I avoid it?
The same thing happens with objects stored in LocalStorage.
Also, if it can not be avoided, what other way of storing my app-data should I use? Server-side storage is last resort here.
The phone settings have been checked, nothing indicates that the browser is rejecting- or is set to clear cookies on session/app exit.
As Shivan Raptor said, important data should be stored server-side.
After some fiddling, I also found that localStorage apparently survives app hard-reset, whereas cookies do not.
Closing.
I have an application built using XPages' mobile controls. On an ipHone the application behaves as I would like in the standard Safari browser. When I take the url and add it to the Home Page as an icon and use the application from there every time an action I take invokes a native application (Maps, Contacts, Phone, attachment viewers etc.) when I switch back to my application I am immediately asked for my userid and password again. Is there a way to control the behavior to not lose the login credentials the same way that the standard Safari application seems to.
This is a limitation in iOS. If you save it to the home page like that it works, but it will NOT multi-task. That's the problem. So it doesn't remember where you were or anything like that.
As David mentions it starts all over again when you switch back.... The problem is not only the credentials - it is also all the information you may have entered or where you have navigated to in the "app".
This is why I am changing to another approach. I am starting to write apps as web-apps that run locally (i.e. cache the ressources and run on the cached versions of the JS-files, CSS and images). Then I implement a localstorage where you can track where in the app you are - and return to that place again. This way you do not need the authentication for running the app - only for synchronizing the information with the server. My approach is to save data locally and sync them to the server (as a sort of replication). This obviously gives more work - but it also gives a better user experience since you can run the "app" without being connected.
I have tried to control the caching locally using a cache.manifest file. This can be done, however, it is a pain. Therefore, I am now using Sencha Touch which really does this nicely.
/John
PS. I think you may be able to handle the login issue by using the XPage Dojo login custom control (http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=Xpages%20Dojo%20Login%20Custom%20Control) - however, it does not solve the issue with reloading the page...
It seems the secret to success here is NOT to tell Safari the XPage is capable of acting as a mobile web app. Add the following code inside for the XPage to ensure this is the case.
<xp:metaData
name="apple-mobile-web-app-capable"
content="no">
</xp:metaData>
Note: You can still provide an icon for the home screen, its just that icon will now act more like a bookmark with the Safari controls and (more importantly) you can switch between applications and when you return to Safari it will display your Xpages app just as you left it.