How to Save the Content in Uiwebview for Faster Loading on Next Launch

Need content in UIWebView to display quickly

Edit: Just pointing out that this question, and its answers, are 4 years old. I'm chatting about iOS 3.x below. I can easily imagine that things have changed in the meantime -- heck, the devices alone are faster than the iPhone 3G was. YMMV. :)

I've been looking at this myself for the past while, not actually implementing anything yet, just Googling. It seems overall that it's very hard / impossible to do this on the iPhone using DontLoad. Even in March, there were reports that it works in Simulator, but not on device: http://discussions.apple.com/message.jspa?messageID=9245292

I'm just guessing, but based on even other StackOverflow questions (e.g. this one) I'm thinking perhaps the on-device caching is somehow more limited than both its Mac and Safari counterparts.

Others on the Apple forums report experiences with rude engineers when asking about UIWebView and NSURLCache, where in bug reports the engineers say it should work, but actual developers say it doesn't. http://discussions.apple.com/thread.jspa?threadID=1588010 (Jul 29-Aug 20)

Some solutions might be found here. Considering [UIImage imageWithData:...], David describes some code for "an implementation of an asynchronous, caching image downloader for iPhone."

And now I've discovered this Aug 10th email on the cocoa-dev mailing list:

On Aug 10, 2009, at 1:38 PM, Mike Manzano wrote:

Has anyone been able to successfully
get the URL loading system on iPhone
to pay attention to custom versions of
NSURLCache? It seems to me that it's
being ignored. More info here:

[a link to this page; removed.]

(See the second "answer" on that
page).

Just need some sort of clue if I'm
doing something wrong or if my code's
just being ignored.

Yes, I've had it work - it just
requires making your own cache
instance and explicitly setting the
shared cache to that new instance.

But it absolutely did work - once
implemented, my "set the table view
cell's image to an image from the net"
works nicely (and without it scrolling
was painful at best).

Glenn Andreas gandreas@xxxxxxxxxxxx
http://www.gandreas.com/ wicked fun!
Mad, Bad, and Dangerous to Know

The above email can be found at http://www.cocoabuilder.com/archive/message/cocoa/2009/8/10/242484 (with no further replies)

Further proof that NSURLCache can work is found in iCab Blog: URL filtering for UIWebView on the iPhone (Aug 18, 2009)

Anyone here probably should also look to Apple's URLCache sample app as it may be relevant to their work: https://developer.apple.com/iphone/library/samplecode/URLCache/index.html Except having just looked at it now, it says "This application does not use a NSURLCache disk or memory cache, so our cache policy is to satisfy the request by loading the data from its source." and uses cachePolicy:NSURLRequestReloadIgnoringLocalCacheData. So this is less relevant than I thought, and why this person was calling NSURLCache a joke.

So it seems NSURLCache is not as tricky or impossible as I started this post by saying. Gotta love finding a way that works while researching reasons it won't work. I still can't believe there are only 25 Google search results for "iphone" and "NSURLRequestReturnCacheDataDontLoad"... This answer has just about every one of em. And I'm glad I wrote it so I can refer to it later ;-)

iOS preserve state of UIWebView?

Good Approach

In iOS 6 and later, if you assign a value to this view’s restorationIdentifier property, it attempts to preserve its URL history, the scaling and scrolling positions for each page, and information about which page is currently being viewed. During restoration, the view restores these values so that the web content appears just as it did before. For more information about how state preservation and restoration works, see iOS App Programming Guide.

UIWebView first request too slow

The main reason is because, when you invoke the first time URL request, the server on the receiving end tries to display the information as per the requested device browser, ( like mobile, desktop). This is where you see a bit of delay.

• The server take some time to resolve the request origin browse type & respond according to the browser type. This value is internally send from the browser. There is a difference in mobile safari & desktop safari.
• The Server upon receiving the request, responds you back with the device type compatible page, ( mostly all domain servers are implementing this internally, the responsive pages).
• If you want a "no delay situation", try calling the exact mobile version of the portal in concern.
• The sub-sequent requests are treated from a known type browser, hence reducing the delay in response.

Hope this solves the doubt.

---

Related Topics