views:

783

answers:

1

Hi

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:)

A: 

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.

wkw
Thanks wkw.Yeah you are right, the app store has that kind of functionality. I do find that a bit weird because it changes between vertical scroll and horizontal scroll in a strange way. I could maybe see if there is a way to split the scrollViews out, it is going to be a bit hard as the inner scrollView is part of the graphics of the outer scrollView. I.e. each "Page" in the outer scroll has their own little inner scrollView that they respond to.This is actually also the functionality you have in the photos app. You can swipe between pictures or zoom, but that is separate use cases…
RickiG
I ended up using wkw's approach. No point of bending backwards to force a framework component to do something it is not intended to do:)This also gives a nice portion of encapsulation that makes everything more readable.
RickiG
I did something pre-3.0 (and it may be a bit easier now) but was really proud of the achievement, if not exasperated working on it for several days... I wanted horizontal scrolling table cells. I was doing a NYTimes Best Sellers list and yanking Amazon data for the details. So each table row was one list (fiction, etc.), and the rows scrolled to show each book on the list. Sadly, halfway through, a friend alerted me to Amazon's disapproval of using their data in mobile apps.
wkw