I am using a UIWebView in my UIViewController.
After web-view finished loading i am programmatically added a UIButton in the bottom of UIWebView with extended ContentSize.
When the app enters background and comes back again, it seems as if the contentSize that i dynamically added was changed to the content size of UIWebView content.
Does anyone have an idea what I am missing here and/or why this happens? Thanks for your time!
Best Regards,
Gison
Related
In an app I am currently working on, UIWebView is used to display files such as PowerPoints and such. There is a drawer to the right of the web view that can be opened and closed via a UIPanGestureRecognizer. As you resize, then open or close, a black artifact will appear on the right side of the web view, exactly as seen on this question: Black bar appearing in UIWebview when device orientation changes.
Between that issue, and the issue in iOS 8 with PDFs rendering with a black background, I decided to try out WKWebView. That doesn't have either issue, however when the web view's width changes dynamically (the right constraint is bound to the pan gesture) the content in the web view is very slow. The web view either doesn't resize, or is very choppy/blocky as it does. This issue isn't present when using UIWebView. Does anyone have either any pointers to fix the issue with UIWebView and that black artifact, or why WKWebView is performing so badly?
re: the WKWebView
My guess is that the webview is attempting to re-render its contents several times as the frame is adjusted. This could cause the choppiness, and there may not be much you can do about that. (not sure)
One way you could 'cheat' is by taking a snapshot of the webview before adjusting its frame, and laying it over top of the webview.
set the webview's hidden property to YES in hopes of killing the re-rendering as the frame is adjusted.
hook up the snapshot to the pan gesture recognizer, and when the gesture ends, give the webview its final frame and set hidden back to NO
at this point, you can remove the snapshot (maybe with an alpha animation) and the webview should only ever have to re-render its content once.
there will probably be a disparity between the snapshot's appearance and the webview's final appearance, but it should be workable.
I am trying to show some content on webview. No problem in showing the content. But, I have a text field at the end of the content. I want to fix it on my webview even I am in starting of the webview scroll.
It was done automatically if I enable page to fit for my webview. But, scale page to fit does not satisfy my requirement.
Any suggestions appreciated.
Thanks!
I have an editable UIWebView into an UIScrollView.
I disabled the scrollview and the bounces on the UIWebView to only rely on the UIScrollView' scrollview.
Each 0.1 second, I have a Timer which detects if the UIWebView content has changed since last check. If so, and if the caret is greater than a given position, the offset fo the scrollView is updated, and the result is pretty good.
My issue is when I go back to edit an already written text.
The UIWebView scrolls on its own view, and the text disappears.
I'd like to use the UIScrollView instead.
Here are two pictures showing the issue:
EDIT: Here is a video showing the bug: http://dl.dropbox.com/u/9666723/Bug.mov
Thanks for any piece of help.
I have a UIWebView inside UIScrollView.
This idea is to be able to create more reading space on screen when user scroll the webpage upwards - by scrolling the UIScrollView upwards till the toolbar is visible, and obviously when the toolbars is nomore visible actually scroll the webpage to show more content that's on the page.
IPhone Safari browser does exactly the same functionality.
see screenshot (first) for default behavior i am getting - i guess because : the scrolling message is consumed by the webview since the touch/scroll is happening directly on webview area.
what i would like to do here is programatiicaly decide when to forward the 'upward scroll' to the UIScrollivew and when not to.
Any tips on how to get around this will be so helpful. Thanks!!
The UIWebView class reference discourages embedding a UIWebView in a UIScrollView:
Important: You should not embed UIWebView or UITableView objects in
UIScrollView objects. If you do so, unexpected behavior can result
because touch events for the two objects can be mixed up and wrongly
handled.
However I suppose you still want to implement your feature ;-)
Idea 1: Don't embed the UIWebView in a UIScrollView, instead run javascript using UIWebView's stringByEvaluatingJavaScriptFromString: method, modifying the DOM to add a toolbar below. If required, you can callback objective-c code from any buttons pushed on the toolbar by registering some custom URL schemes.
Idea 2: Don't embed the UIWebView in a UIScrollView, but in a normal UIView. Building on Vignesh's suggestion, listen for your webView's inner scrollView's scrollViewDidScroll: callback via the delegate, checking the contentOffset vs. the contentSize's height each time the callback is called. Once they are equal, it means you got to the bottom. Once this happens you can animate your toolbar's frame to "enter" the containing UIView and "push" the webView's frame away.
Idea 3: Ignore Apple's recommendation, and embed the UIWebView in a UIScrollView. Building on Vignesh's suggestion, listen for your webView's inner scrollView's scrollViewDidScroll: callback via the delegate, checking the contentOffset vs. the contentSize's height each time the callback is called. Once they are equal, it means you got to the bottom. Once this happens set the userInteractionEnabled property of the webView to NO, and set it to YES on the scrollView which contains the webView and the toolbar. Hopefully the scroll will continue smoothly enough. Of course you have to listen to the containing scroll view in the same way to determine when to switch back the userInteractionEnabled.
A variation on this idea would be to just set userInteractionEnabled to NO for the webView, but set the webView's frame's height to match its contentSize, and also enlarge the contentSize of the containing scrollView accordingly.
Both variations have the drawback that in some cases you won't be able to do things such as click on links :-( But maybe that's good enough for your case. At least in the first variation it's not so bad.
You can add a searchbox and uiwebview in a UIscrollview one below another. To get the content offset when webview is scrolled you can use the following code snippet.
UIScrollView* currentScrollView;
for (UIView* subView in testWebView.subviews) {
if ([subView isKindOfClass:[UIScrollView class]]) {
currentScrollView = (UIScrollView*)subView;
currentScrollView.delegate = (id)self;
}
}
Now you can change your base scrollview offset's y value to the offset value you get from the scrollview didscroll delegate method.
Advanced ScrollView Techniques
https://developer.apple.com/videos/wwdc/2011/
I have an iOS app that loads a xib file for the UI. When I first load the app the interface is about thirty pixels higher than it should be. In the app if I go down one screen and then come back to my main UI it's lined up how it should be.
Right now my view controller is subclassing UIViewController and in the app delegate it loads the nib using initWithNib:
Any ideas what I could do to get the first load to be properly centered on screen?
Within Interface Builder check the actual size of the view in question. I've found when you add and remove simulated elements on a view, such as the status bar, this can cause the height to be reduced but not always increased.
Thanks, that did it. The only thing that you have to watch is if you have the status bar or any other extra bars turned on in Interface Builder, it won't let you change the size of the view.
I tried to vote up your answer, Dave, but I'm too new to.