Well all right, maybe it doesn't kill web development completely... but it's certainly irritating. =)
I have been testing a site recently using various desktop and mobile browsers. So far, the only one that has given me significant trouble is Safari running on the iPhone 5, which uses a level of caching beyond anything I have seen before that seems nearly impossible to get rid of, which I now call Super Caching. This Super Caching has prevented me from testing my site as I am unable to test any changes - not to the css style, back-end c#, front-end javascript, aspx design, nada. I have tried the following methods to attempt to clear the cache for this page (both separately and all together):
Close all tabs in Safari, then close Safari entirely (double tap home button, close Safari icon there)
Settings -> Safari -> Clear History + Settings -> Safari => Clear Cookies and Data. Checking the Website Data after doing this confirms there is nothing there and shows 0 bytes of stored data.
Shut down my phone completely (not just sleep)
Change the url to my site by appending garbage information like ?random=pleasedontcacheme&random2=123
Add code to my site to try and prevent caching... which of course doesn't work because these changes are never retrieved by the phone's browser.
In short, testing has become a small nightmare at the moment. While any tips for how to actually destroy Safari's obnoxious caching would be greatly appreciated, I am more interested in making sure that this does not happen during development in the future. So my question is, for the current Safari browser, what is the best way to stop it from caching a website?
So far I have added the following to the Page_Load of my site's default page:
HttpContext.Current.Response.Cache.SetExpires(DateTime.UtcNow.AddDays(-1));
HttpContext.Current.Response.Cache.SetValidUntilExpires(false);
HttpContext.Current.Response.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches);
HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache);
HttpContext.Current.Response.Cache.SetNoStore();
Response.AppendHeader("Cache-Control", "no-cache, no-store, must-revalidate");
Response.AppendHeader("Pragma", "no-cache");
Response.AppendHeader("Expires", "0");
I have also seen others use meta tags, though they have been described as a bit hacky. (As found here).
I am still working towards a way to retake control of my iPhone's cache, but in the meantime, I would like to ask those who might be more experienced with this particular issue how well the above methods work for getting around the caching issue (during development mostly, but also good to know for future reference). Or, are there other solutions that have been found helpful for this browser/system combo?
Thank you very much in advance for any tips or advice. =)
I have a corporate app with ie8 as the current forced browser. Machines are locked down tight and i can't even test on anything else because I can't install anything else. There are no other version of ie in use. it is 100% ie8. no 7, no 9. And they default to run in ie 7 compat / ie8 quirks mode.
In order to get stuff working right and to force standards mode, i had to use the html 5 DTD (to future-ready the site for mobile dev coming down the pipe instead of xhtml4) and
<meta http-equiv="X-UA-Compatible" content="IE=8">
heading in the template.
I have no information when they might go to ie9... or even skip to ie10.
Whats the best way to future proof this intranet site without being able to test it in ie9 or ie10, or a gecko browser?
I tried to follow tight standards and keep it clean with jquery and css and no in-line markup.
What does an ie9 do when it sees the ie=8 x-ua header? Should i use something else instead of this? I may not be working this app when the move comes. What notes should I leave for a future developer to be aware of?
Leave the X-UA-Compatible set to IE=8. IE9 and IE10 will try to switch to IE8 mode.
I have an HTML5 game set up using the 'Windows Phone HTML5 App' template. This essentially just loads the HTML Game in a WebBrowser control.
When loading index.html locally with a relative URI, performance is dismal with the profiler showing about 10fps:
When loading exactly the same HTML, only from my remote server, I'm getting a good 45fps.
Does anyone have any idea what this disparity is and how to fix it?
Edit -> When loading all images remotely the performance issues are gone. The problem lies in loading images locally, rather than remotely. Bewildering.
Edit 2 -> Base64 encoding the images as data URIs also has the same massive performance gains. Unfortunately that isn't workable for us, but shows something is seriously wrong with loading images locally
Have you found the cause of the problem?
First, in order to make sure you do not have any xss issue can you setup Fiddler for example and monitor the traffic on the phone?
Second, crazy idea: would it work to make a simple http server in your own app? you can then set the webbrowser load your game from it and see how that works compared to loading from local
I'm using WP Mobile Detector with W3 Total Cache and a responsive layout (media queries), and I have a few issues:
When I view the site locally (localhost) on a Blackberry, it looks good; the zoom/viewport is correct, media queries have trigger correctly etc. However, when I view the live site on the Blackberry, the viewport has zoomed out. In the context of a responsive layout, locally I see two columns, but on live I see all six columns (i.e. the Blackberry thinks it is a full browser - quite annoying!).
I thought I would deactivate W3 Total Cache to see if that was having any effect: yes, it was. When the cache is off, the viewport/zoom is good and all is well. Problem solved? Not quite...
With the cache off, I navigate to the live site and while the sub-pages of the site - e.g. www.SITE.com/about, www.SITE.com/contact - are responding with the mobile theme, when I click a link back to home (or type it into the address bar) - i.e. www.SITE.com/ - I'm no longer delivered the mobile theme, just the normal 'desktop' theme. If I go back to a sub-page I see the mobile theme again. What's going on there then.
When viewed on the Blackberry (for example), if I click the 'View Full Site' link (which triggers a Javascript function to modify the cookie) it doesn't show the full site (i.e. normal theme), it just refreshes and shows the mobile theme. However, when viewed in Firefox on the desktop (via a User Agent Switcher) the link DOES modify the cookie and switches back to the normal desktop theme.
Thoughts/Questions
W3TC does work with WPMD (mobile theme delivers minified JS/CSS), but maybe I haven't configured something correctly. The following two links were very useful and I have implemented the changes suggested:
--- http://snipplr.com/view/47970/wp-mobile-detector--w3-total-cache-integration/
--- http://journal.code4lib.org/articles/6223
Is this a known [Blackberry HotSpot/Internet Browser] issue? I have added the requisite meta tags in the document head to indicate viewport data, and the HandheldFriendly meta data which I understand is mainly for Blackberry purposes. As I said, it looks ok with the cache switched off, excepting the home page issue.
I should say it works nicely in Firefox with the User Agent Switcher extension set to iPhone 3, and I have none of the Blackberry issues.
WPMD works by setting a cookie. This appears to be working, else I wouldn't have seen the mobile theme at all.
Does the Blackberry have a problem with the Javscript function? Not easy to tell from the phone itself - might need to drop in a JS error monitor (I was looking at one the other day).
Who'd have thought mobile dev would be so tricky!
UPDATE 1
It's a few weeks since first posting, and I will soon be following Joshua and Frederick's advice to uninstall and then reinstall the [latest version of] W3TC and I'll post my results.
I found that different browsers (both desktop and mobile) treat javascript redirect statements differently. For example:
setTimeout(function(){window.location.reload();},10)
window.location.reload();
location.reload();
The three lines above effectively perform the same action (slightly different implementations, depending on your needs), but I had varying success across browsers using each one - Chrome worked with one, Firefox another, etc.. Unfortunately, I still could not get the Blackberry browser to perform a proper automatic refresh via Javascript.
What else...so, switching between desktop and mobile using a desktop PC/browser has proven interesting. Let's say we're on the desktop version, and we switch to the mobile version of the page. We're OK so far, but then we switch back to the desktop version of the page. Still OK, but if we quickly click a link on the desktop page to go to another [desktop] page then we may find ourselves looking at the mobile version instead of the desktop version.
So, what happened there? As the page was still loading when we clicked another link, did we interrupt something? Presumably not, as the cookie would have been set and sent in the previous request from the mobile version of the page to say, e.g., "show-desktop-version = true". If we do hit F5 or the browser's 'Refresh' button (or, in fact, a link to any other page) then we do see the correct mobile or desktop version (respectively).
Another interesting thing: say we're on our mobile version (using desktop browser), and we're looking at site.com/mypage, and on the page is a link to 'View Full Site' (VFS). We click VFS once and it refreshes but we're still seeing the mobile version. So we click again - same result. So we click again, and again, and again, and again, and - oh, OK this time it switched to the full site. This cycle/process seems to occur once, and then not for a while, and then happens again.
UPDATE 2
Regarding the mobile-desktop theme switching problems, please disregard my notes in 'Update 1'. One of my switcher links (from desktop theme to mobile), e.g....
View Mobile Site
...was using the query parameter (as you can see). I had used this technique to test whether a mobile browser was preventing a proper refresh as the link pointed to the same/current URL. The switcher link should have actually looked like this,
View Mobile Site
...with just a hash to allow the link to be clickable, while allowing the Javascript function to do its magic (update cookie, reload page).
Problem resolved.
(W3TC + WPMD compatibility still an issue for me - will post updates).
I am the developer of the WP Mobile Detector.
The issues you describe are exactly what happens when the W3 Total Cache is installed. For whatever reason, sometimes it is necessary to deactivate and delete the W3 Total Cache.
Two customers that I can remember reported issues even when the W3 Total Cache was disabled. Once it was removed, it fixed the problem. They then re-uploaded W3 Total Cache, made the changes at the link you posted, and seemed to be fine.
For whatever reason these issues seem to be more prevelant with newer versions of the W3 Total Cache. I need to get with Frederick (the creator of W3 Total Cache) and make sure the plugins play nice together.
Make sure to clear your cache on the BlackBerry device as well.
Without evaluating the plugin there are some things to consider here. First W3TC attempts by default to set a cookie to properly determine which page cache to use for user agent groups for smartphones and less-smart phones; it keeps unique caches for each because of the popularity of mobile theme plugins prior to popularity of responsive web design and progressive enhancement.
The user agent groups can be disabled or used to redirect visitors to another page or theme. The next release also removes the need for the cookie when user agent groups are set. A future release will also allow cookies to be used to unique cache user requests as well.
I've built an example with web-browser in windows phone 7. When I load an html file which created by myself, I can double click on web-browser to zoom in/ zoom out the content. But, when I load an web-page (ex: google.com) I can't.
I uploaded my example to my skydriver account. You can't get it at http://cid-b65eb4d185de7cfc.office.live.com/self.aspx/.Public/Shared/Sandbox.WebBrowser.zip
If you known the reason why, please help me.
I think the reason lies in the meta tags within the HTML headers from Google.
I'd guess that Google have fixed the viewport to not allow zooming:
<meta name="viewport" content="user-scalable=no" />
See this post http://blogs.msdn.com/b/mikeormond/archive/2010/12/16/displaying-html-content-in-windows-phone-7.aspx