They "brush" the subject in this thread, but it does not really answer much:Stackoverflow UIScrollView question
I have a UIScrollView and a UIPageControl working together to present a set of views.
(Standard "Home screen" swipe style, in lack of better words)
Each of these views, inside the scrollView, has a thin menu in the bottom part, that can also be swiped from side to side. If anyone remember the previous FaceBook app, this also had a menu that could be swiped horizontally, however, not incased in another scrollView, but the idea is similar.
So the outer scrollView will scroll the entire view, including the view containing the inner scrollView, but the inner scrollView will only change a menu inside the view.
I already did a proof of concept test of this, what happens, is that delegate methods gets called in both the scrollViews no matter where on the screen the swipe takes place, and the innermost scrollView will crash the app when swiped left to right, but not right to left…
I sort of get the feeling that this can be done, but that Im going about it the wrong way.
Is there a way to set which area of the screen reacts to swipes? i.e. decide that the upper ¾ of the screen will call one set of delegate methods and the bottom ¼ will call another set.
Maybe through some sort of mediator that catches the swipes before they are "processed" and then determines which scrollView should react?
Hope someone can point me in a good direction on this one, thanks:)
What about de-nesting the scroll views? Instead of embedding a scrollview inside another scrollview, make them same-level siblings of a parent UIView.
In support of your nesting though, I can think of the App Store app which lets you scroll screen shots horizontally while the app description scrolls vertically.
Related
I have a UIScrollView which contains a timelime. Sometimes I may only want to let the user see say one third of the view and therefore I would like it to only show this part of the scrollview but still have this nice "bouncing" effect in both ends of the view to "preview" what is outside the scrollable area.
Is there any way to do this?
I think you should specify the size of the UIScrollView to end where you want your user to scroll to but leave the size of the inner view (subview) of the UIScrollView.
I have a UIScrollView instance with many views inside. I have touchesBegan: defined inside my implementation of a subclass of UIView, but touches are only detected for views that are originally shown inside the scrollview (without scrolling). That is, initially all touches are detected, but when I scroll down, no touches are detected, except for on those views which were originally above the fold (i.e. they originally fit in the scrollview), and moreover, only those parts of those views which were above the fold (in the cases of views that were partially shown originally).
I hope this is clear... anyone have any idea what could be causing a situation like this?
After a day of debugging, I found the simple solution. The height of the frame of the view inside the scrollview had been set to the height of the screen. I needed to extend it to the full height of the scrollview.
Imagine the situation when you have UITableView placed into UIScrollView.
If you tap on table view and begin vertical moving - UITableView become first responder and will scroll vertically. But if you will move finger horizontally - UIScrollView become first responder and will scroll horizontally.
I have similar situation but instead of UIScrollView I have simple UIView object that intercept - (void)touchesMoved: events and make moving (kinda self made ScrollView).
But how I can do the same trick that UIScrollView do - determine horizontal moving and take away first responder status from UITableView???
Thanks in advance!!!
You could try overriding canBecomeFirstResponder in your view and returning the appropriate value at the appropriate time.
Have you tried throwing a UIPanGestureRecodnizer on the view. You should then be able to set a #selector which will allow you to handle the event in question. Also with pan you can choose to only change the x element and leave the y element alone. Further more with the pan element attached to a view you will not have to worry about having a first responder. Pan elements can a lot of the time be used as a swiping element if you had acceleration and or deceleration. Beyond that I would say you could also add a UISwipeGestureRecognizer element left and right but I do not think you get information such as how far the user swiped meaning, if you want the screen to snap back when the user has not made it far enough to the right or left then you will not have that option. Also, swipe will not give the same effect as the UIScrollView but UIPanGestureRecognizer can, if you do a little extra coding. The extra coding would be observing the position of the x value and then using a little bit of animation for the view to snap to the right or left when the user lets go of the view. Other then that the view should and will follow the finger if you set the x properly.
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 have got a hierarchy where UIScrollviews exist within each other.
How may I redirect swipe events for a certain area to an inner scrollview?
If you set your UIScrollViews to only be scrollable in one axis or the other (ie, set their contentSize property appropriately for this. To have a view only be scrollable vertically, set its contentSize.width value to be the same as its bounds.size.width). then they should just work, assuming that no two views scroll in the same axis. Usually, you'll have the 'child' views scroll vertically, and the parent view scroll horizontally.
If it's at all possible, you should redesign to avoid this. Safari handles this kind of situation, i.e. iframes and textareas, by having the embedded view scroll with two fingers. This isn't very discoverable, but it's better than the alternative, which would be even more frustrating. If an embedded view were just barely onscreen, an attempt to scroll the outer view could instead scroll the inner view, but not display much of anything; it would just appear to be non-responsive.
That said, If you still want to do this, try setting the outer scroll view's canCancelContentTouches to NO. This should prevent the outer view from scrolling when a touch begins in the inner view. Getting Safari-style two finger scrolling would probably involve subclassing UIScrollView and implementing the -touchesShouldBegin:withEvent:inContentView: method.