i need the following view layout in my application.
the green view is the viewport of the ios application.
on the top (the blue ones) are views that should be swipeable left and right but only one view (different content) is visible at a time. this views should snap in place if i swipe.
under this, there are more views arranged horizontally (the orange ones). this should also snap in place (always centered so that one view is in the grey section) after swiping. here is more than one view visible at a time.
there are concepts like PageViewController, UIScrollView, UICollectionView and so one.
which one to choose for something like this?
Also is it a good idea to add subViewControllers with this layout? A Controller for each of the scroll views?
thanks in advance.
For the Top I would go with a 3 UIViewController's UIView (depending on the complexity of the objects). If they are simple things I would just add 3 UIView's and and handle the logic in the same UIViewController. Either putting the 3 inside a UIScrollView (with pagingEnabled) or you handling the gestures are both valid possibilities. The botton UIViews (orange) could be with a UICollectionView (so it could handle the memory for you). A UIScrollView for the botton, could work, but if you have too many you can have performance issues.
Related
I have been battling this transition animation and I am pretty much out of ideas. I am attempting something similar to going from the collection to the individual photos in the Photos app on iOS.
It all works to my satisfaction with the exception that the frame for the "big" detail view of the image is not correct. It is the right size but it is about 87 points closer to the top of the screen compared to the actual position of the image in the final state. This is pretty much the same height as what is above the "safe area" (iPhone X titles + navItem) and irritatingly close to what is also below the safe area (toolbar and iPhone X home area).
I have Googled (and "SO'd") a bunch of different solutions to similar sounding problems. E.g: UIViewControllerAnimatedTransitioning with Safe Area Insets on iPhone X
I have downloaded and perused example code from Github. E.g: https://github.com/SamStone92/CustomTransitions
It seems to me that I have something in my view (controller) hierarchy which is complicating this more than most. I would love some hints as to what might be causing the problem and how I might go about fixing it.
My hierarchy is:
NavigationController containing the root VC with a UICollectionView.
Tapping a cell transitions to a UIPageViewController for a "detail view" where I can page between items in the collection.
UIPageViewController has a bottom toolbar in addition to the navigation bar.
The content ViewController has a ScrollView with a UIImageView in it to get some zooming.
Seems like the common approach is to add the destination view to the container, force a layout pass and then get the frame. I have tried many variants of this with and without converting the coordinates. (they appear to always remain the same before and after conversion)
My Theory
I am leaning towards the UIPageViewController being the complicating factor. But I have not been able to untangle how to get the correct coordinates.
The destination view (in the animation) is not the content view but the PageVC view which in turn may or may not have added the content view, adapted it to the navigation item or the toolbar.
Seems like viewWillAppear on the content VC does not have the right coordinates. I can tell that the detail content view is getting a call to viewWillLayoutSubviews after that and also after all the animation delegation stuff has had its turn.
This is a color overlay of my main views. Grey is the top and bottom areas outside the safe area. Blue is where the transition animates to before revealing the green, underlying actual position it should have animated to.
I am pretty sure this has something to do with the dreaded AutoLayout. (been trying since 2days to get hang of it)
So I mastered it somewhat, but now I have problem where my UIScrollView is not scrolling fully down, pictures are much better at explaining these things
this is the scroll view
this is the content view
so the problem is the scrolling is happening but then again it springs back up. So I am not able to click on the signup button
EDIt 1
Edit:
I have created a little example on github for you to look at, here. The project illustrates the answer below and uses the techniques I describe and nothing else.
Original Answer:
couple of things I would advise here.
First, I know you've been trying for a while but remove all the current constraints (painful I know but). Do this for clarity as ....
The view should be the size of the scene, it looks like you want the scrollview to be the full screen so that too needs to be the size of the scene.
e.g. if you are designing at 6Plus by default the scene size is 414x736 so the view and the scrollview it contains should also be 414x736.
Only the content view needs to be the size of the real content you wish to show. Let's say for arguments sake that the content is 414x1000.
Now the constraints for the scrollview are simple. It needs zero spacing to all it's edges.
You can add the content view to the scrollview in a couple of ways. The way I try to do this varies from project to project and depends mostly on how complex the scene is. If it's a really busy scene I keep the content view outside of the scrollview in interface builder so that I can work on it easily and visualize the whole of the view. Then I add the content view to the scrollview in code.
If its a simpler view You can add it inside the scrollview in interface builder. Ultimately whichever way you do it, you can lose visibility of the content view in interface builder because the contentview is larger than the scrollview and the content gets obscured. So play about and find a good way for you.
Define the content view and all it's subviews. The content view needs to be taller than the scrollview otherwise it wont scroll. All of the content view's subviews need to have defined heights from top to bottom and widths from left to right. In your case the scrollview is scrolling vertically not horizontally so all the widths need to add up to the width of the scroll view BUT the heights need to add up to the full height of the content view.
Note: if you do this proportially your life will be easier later. If you do all this with fixed heights the storyboard will break on different device sizes.
Now the "tricky bit" and it's a bit counter intuitive. You need to pin the content view to the scrollview, remember the height of the content view is taller than the scrollview. In all other circumstances in Interface Builder pinning a view to a superview (0 padding) will adjust the height (or width) accordingly. For the relationship between a scrollview and it's content view this doesn't happen.
First pin the contentview
Notice the -400? Remember the content view is taller than the scrollview and we will change this immediately.
Select the bottom constraint (-400) that we have just created:
Select the drop down arrow next to the constant value:
Select Standard Value and type in 0 for the constant.
You should now have a storyboard with no broken constraints and if you build and run you should get a scrollview as desired.
Your bottomspace to superview on your content view is set to -74.0, I don't know if there is a reason you had to do that, but try setting it to -8.0. I think your scroll view is scrolling up to the 0.0 mark automatically
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.
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.
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.