hai good afternoon to everyone, I am developing an iPhone web application. In my application I have loaded two web pages in a single UIWebView. After this process has completed, one web page should hide or overlap others whenever they get the user-interaction. However, I don't need this yet. User-interaction also should remain so-far.
You can't have two different webpages in one UIWebView. Instead, you should try to create two UIWebView objects and add them as a subview in a container view.
You can set these UIWebView objects' frame, userInteractionEnabled, hidden properties according to your needs.
Also, you should look at delegate methods of UIWebView. Those delegate methods are called when a page is finished loading or when there is an error exc.
You can read the documentation to learn more about delegate methods:
UIWebViewDelegate documentation
Related
im using a UIWebView to show html content in my app, the app contains two arrows to navigate between topics just like a RSS reader app, but when the user hits up or down arrow, the next topic doesn't show up until the data come back and the user still able to interact with the UI which is a bit confusing,
My question: how to block the UI when user moves to the next/back topic ? in other words how to make loadHTMLString:baseURL: works as a synchronous calling ? thanks !
You can let the load happen asynchronously, but set the web view's userInteractionEnabled property to NO. (then back to YES, on the didFinishLoad callback).
Or you could put up a clear colored view (with userInteractionEnabled set to NO) above the web view that has an activity indicator and button that lets the user cancel the load.
An even better idea would be to place two other web views offscreen and start loading them for page N-1 and N+1. When the user presses a page arrow, swap frames with the corresponding prefetched web view.
Try this - https://github.com/gavrix/UISynchedWebView-demo
You don't actually want to block the UI. If you do that, there is a very high probability that Apple will reject your app once you send it in for app store submission. Anything that even remotely makes the application feel unresponsive will weigh heavily on you. Instead, create a background thread using GCD or performSelectorInBackground, handle your loading in that, and then once the loading is done, make all of the information available to your UIWebView all at once and alert it to render the display.
If you are in a pinch and have a UIPageViewController and still want to use a UISynchedWebView to ensure that a page has loaded before you run javascript, you can run a block on the main thread's event queue. Still has a slight delay while the javascript runs but won't cause recursion in the run loop.
dispatch_async(dispatch_get_main_queue(), ^{
[self.webView loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:#"http://google.com"]]]; // self.webView is a UISynchedWebView
NSLog(#"url:%#", [self.webView stringByEvaluatingJavaScriptFromString:#"window.location.href;"]); // shows google.com instead of about:blank
});
I created a new project "Single View Application" and designed the mainView with Storyboard. My main view contains a UIButton that opens the camera, the camera scans barcode and automatically goes to a website. Now I created a webView programmatically so that website can open and also created a UIButton inside the webView. Now I want that UIButton to act as home botton and return to mainview. I am unable to do that, please help.
ViewController.m code: http://cl.ly/FKj8
My storyboard looks like:
You really should look into the View Controller Programming Guide -- by switching around the contents of a single view controller, you're making a lot of extra work for yourself with little benefit. By using multiple view controllers when you want to have different "screens" in your app, you can take advantage of storyboarding for easier development, and you automatically get better memory management (read: less potential for crashes), too.
However, to more directly answer your question... if you're putting the WebView into the view hierarchy with [self.view addSubview:webView], you can remove it with [webView removeFromSuperview]. (This means you'll have to keep a reference to the WebView around so you can refer to it when you want to dismiss it.)
I also noticed in the code you posted to cl.ly an unrelated method -deviceModel which uses uname() to get device information. This is a bad idea, for two reasons:
uname() isn't guaranteed to do something useful on an iOS device (even if it currently does). Use the UIDevice class instead if you need this kind of info, or...
Generally, you don't want to test for the device name to enable functionality in your app; instead, you should test for the capabilities you need. (For example, if you look for a device name starting with "iPhone 4" to test for a Retina display, you'll miss the 4th-generation iPod touch, and the iPhone-5-or-whatever-they-call-what's-next. Instead, use the UIScreen class.)
Firstly, I studied apple's sample codes : SeismicXML and TopSongs but both of them and other tutorials generally calls NSURLConnection in app delegate.
In my ugly project, I have to call NSURLConnection after user reach some viewcontroller in uinavigationcontroller.
So, I'm asking this design issue, Should I still keep NSURLConnection methods in app delegate, and calling from my internet aware vc or completely move this NSURLConnection methods and delegates to my internet aware vc ?
Also, there is another design issues which mess my head since I'm not even starter :)
I have to keep the number of view uitableview which is constructed from xml, and its
detailed view. Therefore, I think that I must two request to my web service. One to getting xml file and the other one must be made in detailed view to increase view count of related data in web service.
But, I think that it's not a good solution, Is there any library or any other approach to keep this list and its detailed view counts and notify my server?
The way I do it is make a separate class that I use only for connection calls and methods, instantiate it from the delegate, set that instance from the delegate as a property (or manually create its setters and getters) and use in in any class/controller I want to.
This way you modularize your application and the classes don't get tangled up and it's easier to debug/follow the flow of the application.
I am creating a tabbar application. One of the tabs is for an rss feed, which is a navigation application. but when i click the tab bat button, it is taking a while to load the view of that tab. It is because the application is waiting for the feed to be loaded from the server. Is there any way to load the view before the loading of that feed takes place. As of now, i'm giving the request in the viewDidLoad method. Thats what is creating the problem. To which part shall i move the code so that the view is loaded instantaneously when clicking the tabbar button.
I recommend this great article on this subject on iCodeBlog, it's a very elegant way of doing this. If you submit your rss feed loading as an NSOperation, it will take place nicely in the background without blocking your main thread.
use:
[self performSelector:#selector(performRSS:) withObject:<nil afterDelay:0.3f];
or
[NSThread detachNewThreadSelector:#selector(performRSS:) toTarget:self withObject:nil];
and place RSS feed related code in a separate function named "performRSS".
I also think that the problem is more that you don't use the HTTP request asyncronously (as Apple recommends). See this document. http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/URLLoadingSystem/Tasks/UsingNSURLConnection.html
It worked for me in my applications.
I have an application that uses UIWebViews in several view controllers. The UIWebViews are used to render locally generated html, no slow network access required.
To save memory I only load these on demand as prompted by the viewcontroller viewWillAppear callback. (And unload offscreen instances in response to didReceiveMemoryWarning messages.)
The problem is that the user gets to see the html being rendered, sometimes accompanied by flashes of styling and other assorted unpleasant artifacts. I would much rather the rendering be done offscreen, and reveal the fully rendered view when its ready.
It would be very tidy to be able to have the viewWillAppear not return until the UIWebView is fully rendered. But how?
I tell the UIWebView what to render by sending it a loadHTMLString:baseURL: message. This is asynchronous, and some time (soon) later the webview's delegate gets called back webViewDidFinishLoad.
I experimented with running a runloop inside viewWillAppear, running either the NSDefaultRunLoopMode or UITrackingRunLoopMode. This works in the simulator (it complains to the log
[CATransaction synchronize] called within transaction
but does work) but on a device it deadlocks, with webViewDidFinishLoad never being called.
(Also, it seems like the UIWebView loading property doesn't work. At least, after I call loadHTMLString:baseURL: and before getting the callback it's not true.)
Lots of solutions here I think. A quick one is to load your UIWebView with it's hidden property set to YES. Then set your UIViewController as the UIWebViews delegate and implement:
- (void)webViewDidFinishLoad:(UIWebView *)webView
where you set the property back to NO.
A thing to note is that webViewDidFinishLoad will fire more than once if you have framed/embedded content. So you have to keep track of this. Shouldn't really be a problem if you are loading local content.
I like monowerker's solution best, but another solution would be to hold onto the already-rendered UIWebView all the time (in some more permanent object than the view controller). I'd only do that if the look of monowerker's solution is too disruptive.