I have a UIView which I am using as a seperate module and can include it anywhere I want to. Now I want to navigate to a UIViewController on click of the button inside the UIView.
Hope this is pretty clear.
Short answer: You shouldn't. You need to read up on the MVC design pattern. A UIView is a view object. You are trying to add controller behavior to a view object.
You should take a look at parent/child view controllers, container views, and embed segues. You could easily create a view controller that manages a "tile" inside another view controller, and sends messages to it's parent when the user taps buttons. This is a very common way of doing things.
The best way to do this is to supply the ViewController to the view as a delegate, conforming to a protocol you create for it.
For instance, if you UIView is used to pick an image, then the delegate should have a method akin to:
(void)view:(UIView*)view choseImage:(UIImage*)image;
Related
My app header is currently a full width, 65pt height UIView which I then use as a generic header for all pages.
class AppHeader: UIView {
...
}
Then, in my Main.storyboard I have a UIViewController with a View from the object library which has its class specified as AppHeader.
My AppHeader (UIView) has multiple buttons which should, if clicked, take you to from the page/controller you're currently on to another.
From the AppHeader class I do not have access to use the present method to show another controller as its not within scope.
Here is my AppHeader.xib:
How can I resolve this?
This is very bad behaviour, you should not use a UIView as a header. You should add a Navigation View Controller as the first view controller of your app. Navigation view controller has the navigation bar where you can put the buttons you want there. From that ones, you will be able to push or present other view controllers.
Check the official documentation: https://developer.apple.com/library/content/documentation/WindowsViews/Conceptual/ViewControllerCatalog/Chapters/NavigationControllers.html
Make your AppHeader view a custom subclass of UIView if it isn't already. Wire the actions on the button to IBAction methods in the view.
Create a protocol AppHeaderDelegateProtocol. Give your AppHeader class a weak delegate property. Define methods in that protocol that let the AppHeader notify it's owning view controller about button presses.
Implement your AppHeaderDelegateProtocol in view controllers that will contain instances of AppHeader.
Connect the delegate property to each instance of AppHeader's owning view controller.
That should do it.
You can create a protocol - call it AppHeaderDelegate or something - and set up your other viewControllers to adopt that protocol. You could define functions to let your delegate know that a certain button was pressed, and your delegate viewController can react to that by presenting the correct view controller.
Apple's docs on protocols here.
Alternatively, you can use NotificationCenter to broadcast notifications to let subscribers know that a certain button was pressed, and have your viewControllers listening for these notifications and reacting to them accordingly. You have to manage when classes start/stop listening, though, as you may have several objects trying to react to a single notification.
Can any one explain when should we add a UIViewController as ChildViewController?
What is the benefits of adding it as ChildViewController instead of subView?
Please help me to understand the purpose of ChildViewController.
When you add a view controller as child view controller, the parent view controller will hold a strong pointer to the child view controller so it doesn't get released instantly. This does not automatically add child's view to parent's view. So you will have to call them both.
I only used it when I needed to create multiple view controllers to be inserted in another view controller and didn't need to directly access it.
its all about UI and code management if you are using subview to achieve what you want to implement inside your app you need to code for your view inside same viewcontrollers class but something interesting i found by creating childviewcontrollers.
empowered to work on a seprate viewcontroller will invoked along with its parent viewcontroller along with its seprate class.
infinite controllers that will be updated tapping a button.
Creation of childViewControllers can be achived by implementing containerView.
or you must have a look of this link hope its helpful to understand.
I have a PageViewController that has 3 child views contained within. I would like to see a simple Objective-C example using protocols/delegates for how I can trigger a method of the PageViewController when a user clicks a button in the child view controllers?
What you want is a simple delegation. You can create a page based project which will generate the code for you. After that create the protocol you want with its methods and add a delegate property to the Page child view controller. The only change you need to make is inside the pageViewController:viewControllerBeforeViewController and pageViewController:viewControllerAfterViewController methods. Before you return the page child controller there set also the delegate and implement the methods from the protocol.
I have a UIImageView subclass (in swift) set up so I can access touchesBegan/touchesMoved/touchesEnded.
When one of these methods is called, I need to change a property of a different, loaded view.
It seems to me that I will now need to access the active view controller in order to set the properties of this other view. Is there are better way to go about this (such as event methods called in the view controller)?
Note that I'm new to iOS and I am not extremely familiar with the event system yet, as most information I've found is written in Objective C and not in Swift. (Don't worry, I'm looking through Apple's Documentation.)
Also, no, I can't change the UIImageView to a UIButton. Even if I changed to a UIButton, I need access to the individual touchesBegan, etc. methods and the same problem would persist.
If I'm understanding you correctly, you need to reference the UIViewController from the UIImageVIew to push/present a new UIViewController. You have a few options:
Fire an NSNotification from the image view and have an event listener on the view controller.
Create a delegate on the image view that fires a selector on the view controller.
Hold a reference to the view controller on the image view, and push a new view controller from the image view with that reference.
Modally present a new view controller on the application window's rootViewController.
I need to implement an accordion control for iOS. By accordion, I mean a UI like this:
I see two basic ways to do this, but I'm not sure which one to choose.
Method #1: Create a ViewController container, something like a UITabBarController, except that instead of showing tabs at the bottom, I draw a vertical stack of buttons, and when you tap one, the corresponding panel opens and shows the corresponding view controller's view.
Method #2: Create a composite view, add a bunch of views directly to it, and show/hide them as needed.
How do I choose here? What would make me want to treat the sub-units as view controllers vs views?
Generally speaking, if I can avoid it I try not to subclass UIView and instead do everything within UIViewController subclasses. A controller is usually required anyway (model/view glue code, user interaction, delegate stuff, notification handling, etc.), so if no custom drawing is needed it is usually possible to do without a UIView subclass.
In your case I could envision one reusable UIViewController subclass that represents a list entry. It has the following responsibilities:
Create two alternate view hierarchies (collapsed/button, expanded/panel)
Toggle between the view hierarchies in reaction to user interaction (with/without animation)
And another UIViewController subclass that represents the entire list. It has the following responsibilities:
Override the appropriate methods from UIViewController to make it into a container VC
Add/remove child VCs as appropriate to the internal model
Possibly adjust the container view in reaction to collapse/expand events in its child VCs