I have a view hierarchy that looks like this.
buttonsView <-- UIView with 1-3 small buttons
MKMapView <-- bottom most view
When my buttonsView is shown I still want the user to be able to scroll the MKMapView if the user is NOT touching any of the buttons.
I have tried different combinations of userInteractionEnabled = NO but nothing helps.
You have several ways to solve this:
The top view with the three small buttons can be much smaller, so that is only covers the area the three small buttons need. By this, the top view won't cover the map view, and you can still scroll it around.
Implement your own hitTest / pointInside functions to let the top view decide whether it wants to catch an event (when you tap on one of its buttons) or it decides to send the event further up the responder chain (when the user taps anything else). See for example here for possible ways to do it: Allowing interaction with a UIView under another UIView
The view on the front takes all the interactions. No matter if it is transparent or not. You should pass the gestures to the MKMapView in the bottom.
Another approach is to resize the view with the buttons to not cover the whole MKMapView, but only the part with the buttons. In that way, the user will be able to scroll only in the area where there are no buttons.
Related
I have a view where content is supposed to scroll over a few elements. One of which is a button. What I did is place the button and all background elements, and then created a scrollview on top of that.
However, the touch events now (obviously) go to the scrollview, and not to the elements in the back. Is it possible to enable interaction through the empty parts of a scroll view?
Screenshot here:
There is a scrollview on top of e.g. the "next" and "edit" buttons. but I'd like these to be clickable anyways.
Thanks.
I'm going to assume that the content you want to scroll is in a subview. ScrollViews always serve as the first layer of any scrollable UI. Put scrollview in your subview then UIView over your ScrollView and over that add your elements.
I've got a UITableView and a big "button" view in front of it. The "button" view, which has transparent areas, should be able to response to a tap. But enabling user interaction for this view blocks any scrolling touches from getting to the table view located under the "button" view.
The upper view is a UIView (not UIButton). Given how the two views work together, the upper view is essentially part of what's going on with the table view and reacts to the table view being scrolled. But scrolling is the main thing and I'd like the user to have the largest scrolling area possible.
How do I best resolve this conflict so that the table view is scrollable as usual?
I guess you could subclass your UIButton and UITableView common superview, and override its hitTest:withEvent: to verify which view is hit, something like if you are in a clear or an opaque part of the button?
As pbush25 is mentionning however, it goes more or less against Apple's recommendation.
I've have been trying for a while now, to implement a specific behavior in my app. On the initial view of my app, there must be a logo(imageView), a label and a textField. It should be possible to scroll down from the initial view, to a tableView. while the user scrolls down, the label in moved up in the window, to form a search field for the tableView. Then the scrollView should lock to the part with the tableView, and it should only be possible to scroll back up, if dragging elsewhere than the tableView.
What is best practice for doing as described?
The image show (only for illustration, i havn't been using story board when trying to implement it) an overview of the problem:
The way I've tried to do this so far, is by embedding the tableView in a scrollView (as seen on image), enabling paging on the scrollView, and than disabling scrolling on the scrollView, when the buttom part has been reached. I've added a gesture reconizer on the part with of the screen with the textField.
These two posts (Scrollview with embedded tableview and Use Pan Recognizer to Control ScrollView) descripe i further detail what i've tried so far.
But the question is more to, is there an alternate solution for making behaviour descriped above?
Maybe interactive animated transitioning between view controllers somehow?
YES there are! Implement a table view with a header view. And remove the scroll view.
self.tableView.tableHeaderView = topView
where topView will be the view wish as the UIImage, the label and textField
I'm not sure if this is possible, but I have a view that is able to be dragged around the screen via pan gestures. Once the view is selected, little grippers appear on the corners of the view that allow the user to resize the view. The problem is, those grippers go outside the bounds of the view (they still show up, because clipSubviews is off), but gesture recognizers on those grippers are not firing when selecting the part of them that is drawn outside of the view. Making the view bigger to actually hold the grippers would break a lot of already created logic that is based on the size of the view, so that is a last resort for me.
Is there any other way to get gesture recognizers to work on views that are drawn outside of their parent view?
You could try overriding hitTest:withEvent: in a UIView subclass, and return the gripper view.
I have a rotating carousel menu made up of 6 UIViews that were added as subViews to self.view. When you rotate the carousel, some subviews are partially behind the subview closest to the user but the problem is that the subview closest to the user may not have been added after the one behind it so when I touch it, the one behind it gets triggered.
My question is, is there a way to programmatically use bringToFront whenever a subview is touched so that it will not matter whether or not it was added first or last to the view.
When you have 2 views responding to touch events and one is in front of the other, the other one will never receive the touch.
Instead of messing around with the event chain (aka subclassing UIView and overriding hitTest…) I'd suggest you reorder the views while spinning the carousel.
The view which appears to be in front should be the topmost view in the view hierarchy.