Hey guys,
So I'm trying to make sense of the IGSideMenuView and what exactly it really is, because I need to fit it into a complex view hierarchy.
So with a simplest example, at first glance, it looked like Option A (pictured), where you'd add a side menu view as a subview of your root view controller.
However, looking at it closer and learning the API, it actually appears closer to Option B (pictured), where your root view controller actually becomes a CHILD view of the menu view, and the menu view is really a full screen view that sits behind the root view controller, and it's partitioned to a left side, and right side, and uses a gesture to slide the root view controller to the left or right, revealing the parent view controller... aka the menu view controller.
The thing that still has me really confused though is how the side views gestures are hooked up.
How does the side view know that I'm not already using a "long press, slide" gesture on my root view controller, or one of it's subviews??
Please help me get a handle on what's really going on here.
Thanks
Dave.
Hi David,
I'll try my best to explain the hierarchy and the control. The IGSideMenuView is a UIView that contains a contentView (another UIView) that will cover a configurable UIView on the left, right, or both sides of the IGSideMenuView. By default, the control uses the long press gesture to expose any configured side menus. Properties exist where the long press gesture for exposing a side menu can be disabled and use of an API call can expose the menu. This is useful for scenarios where a developer would want to use a hamburger menu.
A simplified form of the hierarchy can be thought of like this:
UIWindow > UIViewController > UIView > IGSideMenuView
Gestures in iOS are not aware of each other, so if you'd like to use multiple gestures simultaneously, here is one example tutorial I found that covered the subject.
Does this give you a better idea of how it's laid out?
Well, I'm going to try and work on a particular example, then I'll come revisit this with issues I run into.
I see how you described it...
... but if the IGSideMenuView is the frontmost view in the hierarchy, then the whole screen will be obscured by the IGSideMenuView.contentView (assuming you use self.bounds to size it)
So if you're regular application was
UIWindow > UIViewController (root VC) > UIView (root view), then adding IGSideMenuView would cover the root view with a full screen white (default) IGSideMenuView.contentView.
So I assume you'd drop your root view into the IGSideMenuView.contentView in order for it to be visible.
Hence
UIWindow > IGSideMenuView.contentView > UIViewController (formerly root VC) > UIView (formerly root view)
Anyway, I'm still trying to figure it out, but I'll come back with a more specific example later tonight or tomorrow (Wed, Jan 13)
One thing that may help you understand UIView in iOS is to think of them as containers for other UIViews where the top most ones will have rendered content that the user interacts with. In the general IGSideMenuView scenario, the paradigm would be adding the IGSideMenuView to the UIViewController's view and all the content you want displayed and interacted with by the user to the contentView. Adding the UIViewController's view property as a subview to another view is bad practice and not what should be done in any case.
Here's an example image taken from Apple's View and Window Architecture topic. By looking at the image below, it'll help you visualize how the IGSideMenuView sits on top of the UIViewController's view.