I have a paged scroll view in my app and it works almost perfectly... Usually one page looks like this:
There is no content below this, but when i move it as if it should scroll down (clicking and swiping upwards) it stops moving at this stage:
It's as if its decided that that is an acceptable page loaction or something. If i drag it part way up it snaps the rest of the way up, and if i drag it part way down it snaps all the way down.
Why is it considering this an acceptable place to stop? Is there an easy property to set im missing? Or is there a way to allow only horizontal scrolling?
Thanks
Check the contentSize property of the scroll view. That determines how far it will scroll, and you can manually set it to control exactly where it will scroll to.
Is the scroll view on 0,0 on the canvas? It looks like it is not actually centered on the screen.
Related
Ok, I have a complicated scenario here. I have a scrollview which scrolls horizontally and contains tiles, 1 centered on the screen at a time with the user still able to see if there are more to the left or right by way of having the edges of the 2 views visible on either side. I am able to add the views programmatically to the scrollview and have paging work properly, so the user can swipe back and forth between them. Another requirement is to have an initial animation where the first view slides in, then is bounced off to the left by the second view. I accomplished this by using a series of UIView animations, and it works well.
Here is my problem: After the animation completes, you cannot scroll left to get to the first UIView that was created. I suspect that this is because it was animated out to the left of the content area of the scrollview. I have tried to increase the contentSize of the scrollview, but I still get the same behavior.Once the initial scrollview has been moved off to the left, I cannot swipe to page to it.
Is there a common pattern I could use to accomplish this in a better way?
It sounds to me like you're animating the child view's frame to the left so that the x coordinate of that first view's frame is negative, instead of animating the scroll view's contentOffset to the right. If that's the case, is there a reason you aren't just setting the scroll view's contentOffset inside an animation block? If there is a reason, what if after the animation completes you "fix up" the content offset and the frames of the child views so that none of the views are in a negative position.
But, I guess I have more questions than answers right now, so it might help to post the code showing how you do your animations to make it easier to answer your question.
I'm having a really hard time trying to animate the resizing of a UIWebView, and just don't know where else to go.
Here's what I want to accomplish: I have two views, one above the other (imagine two squares, one on the top of the other). The top view is a UIWebView, and the bottom one will be referred to as a general UIView (I'm not having any problems with the bottom one). I adjust the two views every time new content is loaded just fine. I also have a button that should hide the bottom view or show it, depending on its previous state.
That's where the problem kicks in. When the bottom view is hidden, pressing the button will enlarge its frame and reduce the UIWebView frame. That's fine. But if the bottom view is being shown and the button is pressed, the UIWebView frame will become larger, and there are some issues with it:
If the UIWebView is scrolled all the way to the bottom, it "jumps" up a little bit before coming down (becoming larger);
If the UIWebView is scrolled all the way to the top, it comes down as expected, as long as there is enough content to be scrolled behind the bottom view.
In general, what I've learned is that if the content yet behind the bottom view is LARGER than the amount of resizing happening, no jumping happens. Otherwise, it does.
I've done a lot of research, asked a previous question and so I'm assuming this is a consequence of lazy loading the UIWebView. This "jump" happens so that it is automatically resized (showing all the content, even if some of it is offscreen) and then moves down. Otherwise, it would be expanding and loading new content at the same time, requiring a lot more processor power.
I've experimented with frames, bounds and centers, and so far have got nowhere. Is my assumption correct? Is there no simple way to resize way to resize the UIWebView so that it goes only down (when becoming larger) and keeps the bottom scroll?
In theory, I think the right way would be to make the UIWebView larger to the top, keeping its current bottom position, and then animate bringing it down. This way, the top content would already be loaded. But I haven't had any success with it.
If anyone has any experience with this, please share. And thanks a lot.
If scrolled to the bottom of a tall enough web page, try animating the web view downwards without changing it's size, then change the web views height so that the top goes back to where it should be. You can temporarily fill the space left as the web view moves down with some sort of pattern.
Client wants some tricky stuff and i don't really know where to start with it.
The idea is that there is a horizontal scrollView whose each page consists of a vertical scrollView.
For example, on the horizontal axis there are galleries, on the vertical we scroll through selected gallery's images. Is this even possible?
I'd be very glad to hear comments on this one!
You will have to manage the state yourself. When one scrollbar is selected the other has to be disabled and vice versa. You can also disable the user scrolling and handle the swiping yourself with the touch events. (on a clearColor UIView as a topmost view).
They all works magically, there's no additional work for this unless there's an issue about memory consumption which will require more coding.
Simply, create a horizontal scroll view then add vertical scroll views into it. Don't forget to update the contentSize property.
I would like to be able to build a scroll view capable of scrolling an unbounded (infinite) distance (this is question number one, how to do this with the contentSize property). The reason for this is so that I can implement a scrolling calendar view, which the user can use to scroll through time along a single axis.
Now, I need to put a view/s in there to mark the dates as they scroll by. My second question is how to implement a view like this in a scroll view. I could have a long view, 3 or 4 times wider than the scrollview frame and just reposition and update that every time the scrolling stops, faking a continuous bar. Any other ideas?
Thanks!
I know it's been a while since you posted this question, but just for future reference:
At WWDC 2011, Apple gave a great presentation called "Session 104 - Advanced Scroll View Techniques". The video can be seen from developer.apple.com or from iTunes.
The main concept:
1 - Start off with a subview that is larger than your scrollView's bounds.
2 - In -layoutSubViews from the scrollView, you check whether the contentOffset in the direction you want to scroll infinitely is past some threshold that you specify (this doesn't have to be any specific value, it could be 1 point in the extreme).
3 - If this is the case, you reset the contentOffset to zero, and you adjust the subview's frame by the same amount.
These last two steps happen within the same run loop cycle, hence the transition will not be visible. Beware that the scrollBar will jump, though. But as your scrollView is infinite, there is no visual feedback the scrollBars could give, anyway, so you'd better hide them when you've finished implementing this.
Not sure it can be... You could try CGSizeZero
http://developer.apple.com/library/ios/#documentation/uikit/reference/UIScrollView_Class/Reference/UIScrollView.html#//apple_ref/occ/instp/UIScrollView/contentSize
contentSize
The size of the content view. #property(nonatomic) CGSize contentSize Discussion
The unit of size is points. The default size is CGSizeZero.
The real question is do you truely want "infinate" or do you want mostly infinate and just make the view ungodly large? Or do you want auto-resizing.
Also a continuous bar for an infinite scrollview? The bar would never move as it wouldn't get any closer to the beginning or the end... You could make a bar that dragging to the right would go into the future and dragging it to the left would go back and then just always reposition it in the center.... Other then that I dunno what would make sense here.
Looping UIScrollView Horizontally sounds like the same sort of problem, hopefully my comments there might give you some ideas as well.
Making an 'infinite' scrollview doesn't work - the memory requirements get way too large. The best way to do it is fake it.
3 screen scrollview:
|---|---|---|
| | | |
|---|---|---|
Make a scrollview that is 3 times as large as one screen, then when the user finishes scrolling to the next third of the scrollview, move the scroll position back to the center third and scoot the content over to the left. This happens so fast that there is no visible feedback to the user that the scrollview & content was just recentered.
Similarly, when the user scrolls back to the first third, change the scroll position to the center third and move all the content to the right.
For memory management, you should only load as much content as will fit onto those three screens. When you scroll to the next third, you'll reposition, and load the next screen of content.
I'm working on an iPhone game, and trying to use a UIScrollView to display some icons, which I then want to enable the user to drag off the bar being scrolled, onto another view (basically, dragging them from their hand into play on the game board). The problem is that the UIScrollView clips everything outside it's own bounds.
Here is a picture of what I'm trying to do:
Functionally, it actually works, in that you can drag the icons up to the white board fine...but you can't see them as you are dragging...which is not acceptable.
Does anyone know if you can temporarily disable the clipping that a scroll view does, or is there some way to get around it? Hacky or not, I would really like to make it happen.
Does anyone have any other possible solutions for this? Or maybe any alternate approaches? I've considered if maybe a page view might work, but haven't tried it yet...and it's not at all as good of a solution as the scroll view.
Worst case I can just go back to not having the bar scrollable, but that really puts a damper on some of my game mechanics, and I'm really not too excited about that.
I think you're looking for the clipsToBounds property of UIView. I've used it successfully with UIScrollView:
scrollView.clipsToBounds = NO;
However, the dragging you want to do from the scroll view to the game view may require you to remove the icon view from the scroll view, place it in the superview at a position corresponding to its visible position within the scroll view (calculated using the scroll view's origin and content offset), and have that track the user's finger movements. On a release of the touch, either drop it on the game view at the proper position or return it to the scroll view.
I'm not 100% sure I understand the question but I think you should look into the z order of the scrollview and the whiteboard. It may be that the drag is just going behind the whiteboard.
Failing that, it would be useful to see all the bounds of your view heirarchy.
I also think a better solution allround might be to create a "sprite" to animate underneath the players finger - you could offset the drawpoint of the sprite from the touchlocation so that the player can see what they are dragging.