I'm reviewing someone else's code and noticed a web form gets refreshed every time you attach an image(click 'add image', find and choose image, return to form, form goes blank). And, it's because the url gets reloaded. In tracking this issue down I noticed that the original dev overrode the viewDidAppear instance method in WebViewController like so:
- (void) viewDidAppear:(BOOL)animated {
NSURL *url = [NSURL URLWithString:self.defaultUrl];
NSURLRequest *requestObj = [NSURLRequest requestWithURL:url];
[self.webView loadRequest:requestObj];
}
Apple's documentation says
You can override this method to perform additional tasks associated with presenting the view. If you override this method, you must call super at some point in your implementation.
I see super isn't called and I think putting in an NSURLRequest is not good practice. I removed the code, added the URL call a button action and all's well so this is mostly a stylistic/academic question.
Do you agree that loadRequest shouldn't be in there? Thanks for your help.
Why shouldnt it be there? loadRequest does its work asynchronously on another thread, so it doesn't block the main thread.
Connects to a given URL by initiating an asynchronous client request.
If it behaves the intended way, is for you to decide.
(Oh and yeah, you should call super in viewDidAppear)
Related
I am using UIWebView to display textual content in my app (I store the content in local HTML files that I pack with the app). All together, I have three web views whose content I change dynamically based on user feedback.
Although some might argue that this is not the most accepted way, I find UIWebView very convenient to display formatted text, and modify that text using HTML if necessary. While this works 99% of the time, on occasion, I experience problems that generally fall into one of these categories:
Sometimes, the web view content loads slow and is late a second or so.
The content loads but is not showing. However, as long as, I touch the view (try to scroll or something) the content pops in.
A few times I received memory warnings (usually not long after the app's initial loading) that in no way affected the performance of my app. It logged the memory warning but the app worked like nothing happened.
This is the method I use to load content to my web views:
- (void)loadSimpleDocument:(NSString*)documentName inView:(UIWebView*)webView
{
NSString *path = [[NSBundle mainBundle] pathForResource:documentName ofType:#"html"];
NSURL *url = [NSURL fileURLWithPath:path];
NSURLRequest *request = [NSURLRequest requestWithURL:url];
[webView loadRequest:request];
}
Aside from this, the shouldStartLoadWithRequest delegate method is also implemented, always returning a YES.
My question is: Is there a way to improve the reliability/performance of my web views (in particular loading)? Is there something I have overlooked, did wrong, or do not know about?
Some additional info:
I am on iOS6 SDK, use ARC, and do everything programmatically (do not use IB or storyboard).
You have 2 options to check what's going on:
Implement webViewDidStartLoad & webViewDidFinishLoad delegate methods to check why the content isn't showing (may be the content isn't loaded yet).
read the html content to an NSString then use loadHTMLString:baseURL instead of using loadRequest and check if it loads faster.
Hope this could help.
NSURLRequest delegate methods are not getting called when i run the application on the device. It works perfectly on the simulator though. Also its not the case of my view loading before the request is fulfilled because i enable to view to be loaded only once the connection has received the data.
My code requesting url is here. Any help greatly appreciated.
- (void)viewWillAppear:(BOOL)animated
{
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:#"http://-dev01x/content"]; cachePolicy:NSURLRequestReloadIgnoringLocalAndRemoteCacheData timeoutInterval:60];
[request setHTTPMethod:#"GET"];
_getData = [[NSURLConnection alloc] initWithRequest:request delegate:self];
NSLog(#"HELLO %#",_getData);
}
Your code as provided here makes no sense:
_getData = [[NSURLConnection alloc] initWithRequest:request delegate:self];
That line returns a pointer to a NSURLConnection object, your variable name is misleading. If you want to block at this point (and does that even work) then it would appear you need to use sendSynchronousRequest at that point.
I do something similar to what you want to do, but in a more traditional way. In viewDidLoad or even in the initWithFrame, I will start up an asynchronous connection, set a flag, and set the view backgroundColor to black or white (I use a spinner too normally). When I get viewWillAppear, if the connection has completed, all is well and I set the various UI elements. If not, then don't do anything, and later, when the connection completes, pull down the spinner and update the UI.
The only way I can think of to block the main thread at the point you are trying to would be to use that synchronous request (which IMHO is a really bad way to deal with this).
The beauty of doing things in the background is that if its taking too long, the user can tap the back button or go somewhere else in the app [in which case you cancel the connection and tear everything down.]
Check url u provide to NSMutableURLRequest when checked in browser gives nothing
NSMutableURLRequest needs valid url
I am triggering a phone call through a UIWebView, so that when the call ends, the user is returned directly to my app, via the following code:
UIWebView *callWebview = [[UIWebView alloc] init];
NSURL *telURL = [NSURL URLWithString:#"tel:number-to-call"];
[callWebview loadRequest:[NSURLRequest requestWithURL:telURL]];
When it returns control back to my App I'd like to execute some code, but I am unable to determine what if any method the OS is calling when it returns to my App after the call ends? ViewWill, ViewDid etc never get called when control returns.
What if anything gets called when the call ends and control returns to the webview/app?
UIWebview Class has some delegate founctions.webview call these founctions when start loading and finish loading request and so on. I have poor English,I wish you can understand me.if I misread your question and my answer isn't what you want,please forgive me.
I am loading request like this [resultsWebView loadRequest:searchRequest]; Then I do this
- (void) webViewDidFinishLoad:(UIWebView *)webView {
if ([resultsWebView canGoBack]) {
[goBackButton setEnabled:YES];
}
else {
[goBackButton setEnabled:NO];
}
if ([resultsWebView canGoForward]) {
[goForwardButton setEnabled:YES];
}
else {
[goForwardButton setEnabled:NO];
}
}
canGoBack is always returning NO.
It was working earlier, but it has stopped working suddenly(I have not done any code changes). I don't know how is this possible? Not getting any success to resolve this. There is a question on stackoverflow UIWebView canGoBack and canGoForward always return NO. But it is different as the question author was using loadData and he resolved the problem using loadRequest. But I am already using loadRequest. And again, it was working earlier, but it has stopped working suddenly(I have not done any code changes). Help me.
Cause of issue:
params = [NSString stringWithFormat:#"query=%#", searchTextField.text];
NSMutableURLRequest *searchRequest = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:#"https://www.example.com/do/m/]];
[searchRequest setHTTPMethod:#"POST"];
[searchRequest setHTTPBody:[params dataUsingEncoding:NSUTF8StringEncoding]];
If I use the simple request like below, it works fine.
NSURLRequest *searchRequest = [NSURLRequest requestWithURL:[NSURL URLWithString:[NSString stringWithFormat:#"https://www.example.com/do/m/?%#", params]] ];
Thanks
The request may be fail even though you can see the page successfully rendered in the web view, you also need to set those go back/forward logics to – webView:didFailLoadWithError:.
Finally, I found that, if the URL is same in the consecutive POST requests for the loadRequest method then canGoBack does not work. It was working for simple GET requests because URLs were different.
To fix this, I sent the consecutive POST requests with two URLs, which are different from UIWebView perspective but actually same from the server perspective. I am setting the different URLs alternatively for consecutive POST requests, by adding a question-mark(?).
https://www.example.com/do/m/
https://www.example.com/do/m/?
In this way the URLs become different for consecutive POST requests of UIWebView and canGoBack method works.
Still I donot whether it is a bug in UIWebView or we can not use consecutive POST requests with UIWebView to get the canGoBack method works.
I am doing this in my app :
-
(void)viewDidLoad
{
[super viewDidLoad];
// Do any additional setup after loading the view from its nib.i
NSURL *url = [NSURL URLWithString:#"http://www.mySite.fr"];
NSURLRequest *request = [NSURLRequest requestWithURL:url];
[self.myWebView loadRequest:request];
self.myWebView.scalesPageToFit = YES;
}
When i have not the network ( no connexion) nothing is shown ( just a white page witch is the web view).
My question is should i put an alert to the user when there is no network ? how i ca do this ? thanks ? will my app rejected if i don't show an alert to the user ?
Thanks for your answers
While it makes sense to check for reachability, I think you have a better approach using the delegate method webView:didFailLoadWithError: which will tell you if the web view has failed to load your page. In such a case, rather than popping an alert view load some kind of local HTML page indicating that the load has failed if you wish and set a timer to trigger a reload after a while.
As such I don't think Apple will reject you for this unless it is the only thing the App does. But you will have to give a thought on the user experience when the load fails.
I do not think that not checking for a connection will cause your app to be rejected, but you should do it anyway.
Ed Marty has pointed out that my original suggestion of using
- (BOOL)checkResourceIsReachableAndReturnError:(NSError **)error
will not work in iOS (thanks!).
This StackOverflow question appears to have a working solution to the problem.