I have a fixed top header, bottom footer, with content in the middle. Keep in mind, the header and footer have the safe area insets written to avoid the safe area content from clashing with the page components. Is it possible to attach the UIRefreshControl to the middle content only, if it is all under one element with an ID?
What is happening now is that I can pull the whole body, after attaching the UIRefreshControl to the WKWebView ScrollView. The refresh spinner will come from behind the header as needed, but it will require a long pull (pulling the whole body) and the spinner will not show fully before the refresh action has been called as the body starts from the top of screen (where the safe area starts).
Don't mind the glitching, its just the pulling effect while the whole page is refreshing (the refresh callback will be changed later).
What can be done to target the middle content only, in a WKWebView?
Related
As it can be seen in the gif from the link, I was able to add the refresh control to the scrollView but it is only shown for the first page. It still works for the other pages but it is not showing the refresh indicator which might be confusing for the user.
I have tried already a couple of ideas but nothing seems to work.
I am looking for a solution, which either only makes it possible to use the refresh control on the first page and disables vertical scrolling for the other pages or a solution which shows the refresh indicator at every page.
I would also like to disable the diagonal dragging. I added this in case there is a solution which solves both problems.
https://giphy.com/gifs/KfqJnVlwKE9fwFc07R/html5
Help will be very appreciated.
The indicator looks like it is probably added as a child of the scrollview, meaning it is scrolled along with the other contained views, and hence scrolled off-screen.
For an element you want to always be displayed over the scroll view add the indicator as a sibling of the scroll view (i.e. a subview of the scroll view's parent).
I am building an iPad app that requires only the middle section of a web page to be visible in a UIWebView. (The entire page without the header and footer)
The portion I need to show is a form where someone enters information into and hits submit. If I position the UIWebView to only show the middle section, when I click on a text area it scrolls up / down to show the right text area on top of the iPad keyboard. This causes the header / footer to be revealed.
It doesn't seem like modifying the source code before it enters the UIWebView will work either, because the form has to work afterwards. (Like I need to be able to hit submit and have it work properly)
I'm wondering if it's possible to add a view to the top and bottom of a UIWebview so that it covers up the header and footer?
Any help would be much appreciated. I can't find a solution that will work for this situation anywhere.
Figured it out -- I was able to add a view onto the UIWebView's scroll view
// Create new view
UIView* view = [[UIView alloc] initWithFrame:CGRectMake(0,0,768,200)];
// Add to scrollView so that the added view scrolls with the UIWebView
[webView.scrollView addSubview:view];
The default behavior in jquerymobile when I have header, content and footer (where header/footer are fixed) is that when I scroll the content the header/footer show/hide. I mean when you start scrolling the header/footer hides and when u stop scrolling the header/footer are shown again. On devices its looks very bad/none-user friendly. I want to avoid this show/hide effects of header/footer. Is there any thing thats available in jquerymobile or some of its plugin to avoid it? If nothing then I want to apply iScroll on the content. Can someone guide me how to make data-role="content" using full-screen height?
If this is what you are referring to, then you can just remove the data-position: fixed from the headers and footers. I tried it on the iPhone, and it is still buggy (seems to flicker whenever a touch event it generated, even if it is not necessary).
I'm creating a mock-up of a function to be added to a mobile version of a site. The idea is to have a horizontally scrolling footer of links with vertically scrolling content; in effect, recreating the functionality of the native iOS behavior when double-tapping the home button.
Problem: when the page loads, it appears the viewport is not getting recalculated to match the new content area height. This leaves an ugly blank area (apparently the size of the URL bar in iOS Safari) below the scrollable footer.
I've tried adding a timeout to recalculate the height (using the function in scrollview.js). When using a fixed-position footer, the footer behaves strangely but eventually reappears in the expected place - the blank space remains, however.
Link to jsfiddle code.
Link to imgur screenshot from my iPhone.
I came across this question. I see that both stickyHeader and scroller works kind of the same in the way that they both keep the header row visible and there's a scroller bar on the side. Could someone please kindly explain the difference between them?
The stickyHeader widget makes the table head "stick" to the top of the browser, or table container (if options are set), window as the user scrolls down the table; this is similar to the sticky menu some sites use for site navigation. Check out this demo especially the last one on that page which is an example of nested tables stacking the sticky headers while you scroll down the document. There is also a css3 version of this widget which uses css3 transforms to position the table head at the top of the browser window.
The scroller widget, on the other hand, has to make a copy of the table header placed above the table, hides the original table header, then makes the tbody of the table scrollable, within a fixed height. So, the browser window position doesn't change which the user is scrolling through the table content, just a scrollable window of content is seen. If you look at this demo, you'll see that the table body is scrollable, but the head does not "stick" to the browser window (unless you set the scroller_jumpToHeader which forces the table head to become visible while scrolling up the document.