I don't like the UINavigationController because the tree/drill-down navigation style does not work in all situations. What I'm looking for is a sort of UISwitchController where a view controller can tell the UISwitchController what the next view is and the data to pass to it. Then the current view closes itself and the UISwitchController would handle opening the next view and passing in the data from the previous view. The UISwitchController could remember the name/type of the last view opened so the current view could tell who opened it (also allows the UISwitchController to handle a Back request by the current view without the current view specifying the name of the view that opened it). A view could also flag the UISwitchController to keep it in memory and not to release it after it closes so the view controller is essential reused for each call to that view. Is there such an framework?
So basically you are talking of a UIViewController that holds several UIView(Controller)s and handles the presentation.
In iOS < 5 I would just use a UIViewController, that adds views to another view, that is displayed.
in iOS 5+ you should familiarize yourself with UIViewController Containment, that is actually a pattern of how to use UIViewControllers with other child view controllers.
form the UIViewController doc
Implementing a Container View Controller
In iOS 5.0 and later, custom UIViewController subclasses can also act
as container view controllers. A container view controller manages the
presentation of content of other view controllers it owns, also known
as its child view controllers. A child’s view can be presented as-is
or in conjunction with views owned by the container view controller.
Your container view controller subclass should declare a public
interface to associate its children. The nature of these methods is up
to you and depends on the semantics of the container you are creating.
You need to decide how many children can be displayed by your view
controller at once, when those children are displayed, and where they
appear in your view controller’s view hierarchy. Your view controller
class defines what relationships, if any, are shared by the children.
By establishing a clean public interface for your container, you
ensure that children use its capabilities logically, without accessing
too many private details about how your container implements the
behavior.
Session 102 - Implementing UIViewController Containment — WWDC 2011
I haven't used it much so I don't know if it's exactly what you're looking for, but you can use TTNavigator from the three20 framework to do URL based navigation which sounds like it could be what you want.
https://github.com/facebook/three20
Related
I'm new to iOS dev and am working with an existing project. I just have a quick question regarding how views and view-controllers should be conceptualized and what the conventions are for dealing with them.
I noticed that the base UIViewController class has a property view which references an actual "physical" (for lack of a better word) view, while the controller essentially manages that physical view (and ties it to the model, etc--standard mvc stuff I understand).
This would suggest the view controller takes conceptual precedence in cocoa touch. However, when adding a subview (to a parent physical view? or to a parent view controller?) it accepts a physical view, not a view controller.
Is it expected that I first create the sub view controller (which presumably creates its own physical view) and then pass its view property to addSubView? I just want to make sure I'm not missing something obvious in the conventional workflow here.
Views and view controllers aren't in a 1:1 ratio. A view controller manages as many views as it needs to for a given area of functionality - on the iPhone, typically a screen full of content but this definition is shifting slightly.
The view property of a controller is simply the parent view - this can have as many subviews as you need to do the job. The controller coordinates between those views and the data model to deliver the functionality of your app.
You can have child view controllers, which are added to the view controller hierarchy as well as the view hierarchy (the child view controller's view is added as a subview of the parent view controller's view) but you wouldn't do this for every subview.
There was an excellent talk in WWDC 2012 ("The evolution of view controllers", IIRC) which explained this pretty well.
I'm looking to implement a custom segue that pushes to a UIViewController, but completes before the new UIViewController fully fills the screen, leaving some of the source view controller still in view and functional. (For example; new view controller covers half of the user interface).
I'm keen to use a segue rather than a view that is moved using CGRect, Quartz framework method, or similar, as constraints get messy really easily, unless a custom segue could utilise such methods(?)
Any pointers greatly welcomed! :)
For this task you would use a container view controller, which manages and displays the content of multiple other view controllers at a time while letting them interact with their views like normal. An example of this would be the UISplitViewController, which displays two view controllers' views at a time, one on each side of the screen. You can design segues that swap out one view controller of the multiple on display in a container view controller, similarly to the Replace Segue implemented by Apple to swap out a UISplitViewController's detail view controller (the one on the right hand side).
I have something like a modal view controller that I need to display above my other view controllers. I’m not using the regular modal controller feature (presentViewController: and friends), since I need better control over the process. Instead I am using the view controller containment feature (the addChildViewController: method group).
The containment feature makes the code fairly straightforward. When I need to present the “modal” view controller, I add it as a child to the view controller hierarchy and everything works as expected. One small catch is that the regular view controllers are wrapped in a navigation controller. Therefore I have to add the modal controller as a child of the navigation controller, otherwise it would be covered by the navigation bar and toolbar.
Now the problem is that calling addChildViewController: on a navigation controller also sets the new controller as the topViewController, as if the controller was pushed using the regular pushViewController: method. This means that while the modal controller is displayed, the regular controller underneath it does not receive the appearance and rotation callbacks.
This feels like a bug, or am I missing something?
I had the same problem. I resolved this by writing my own custom view controller, containing a UINavigationController (added via addChildViewController:) and then exposing the UINavigationController as a readonly property. Then you can add your modal view controller as a child of your new custom view controller instead of as a child of the UINavigationController
I missed this sentence in the documentation for addChildViewController:
This method is only intended to be called by an implementation of a
custom container view controller.
So I guess it’s my fault and this scenario is simply not supported. Which sucks, because it’s very convenient to design whatever modal things as regular view controllers and connect them to the hierarchy like proper first-class citizens. I would probably have to rewrite the navigation controller on my own to have built-in support for this.
Is it possible to access a NSWindowController's element from a child NSViewController?
Essentially I have a NSProgressIndicator that spins on the bottom corner of the NSWindow. This works because my WebView is in my NSWindowController instead of my NSViewController.
I want to break the logic apart now but I'm having trouble understanding how I'd access these elements from my View Controller.
Thanks!
You can't connect an outlet from one NIB to an object in another and the desire to do so indicates a problem with your design. If the view is so intimately connected to other things in the window, maybe it shouldn't be separated out into a different NIB.
A view should only go into a separate NIB when it makes sense as a self-contained unit. It should represent and manipulate its controller's representedObject and not much more. The controller might have a delegate that it informs about what's being done and asks to make customizing decisions.
Maybe you can continue to use a separate NIB if you adopt that sort of design. Perhaps the window will have a reference to some model object. It would configure the view controller to use that model object as its represented object. And perhaps the progress indicator would be bound to that same model object. Then, as the view manipulates its represented object, it would indirectly also affect the progress indicator.
Another option would be for the window controller to set itself as the delegate for the view controller and your view controller could invoke it at appropriate points to inform it of things going on in the view. Then the window controller could do whatever was appropriate to the progress indicator or other stuff in the window outside of the view. This hypothetical delegate is something you would have to add to the view controller class and you'd design its protocol.
I was trying to understand what's going on in a UIViewController->UIView when loaded from Interface Builder or Storyboards.
I start wondering about how things works in background when facing the most commons of problem, which is passing parameters between controllers.
In a Storyboards using the navigation controller I have a table view loaded by CoreData element, and the single element is passed as NSManagedObjectID onto the next controller via #property in the segue method for displaying a detail view.
On the receiving controller I am doing a check of the existence and reconstruct the full object when needed.
At this point, comes the question, where's the best place to put and handle this logic ?
I come from a Java EE background, where the controller is called a servlet, and a servlet for performance reason may be initialized once and shared by many users (by means of Thread Pool) and therefore is discouraged (dangerous is more appropriate) to have instance variable.
Just because a #property is an instance variable I don't want to fall in the same mechanism, my UIViewController is instantiated once and the CoreData object stays the same in case of view controller.
On iOS, each view controller manages a single view and its subviews. Even if you used a UISplitViewController to put two identical view controllers on the screen at once, they would be two separate instances of the view controller class, and I believe storyboards instantiate a new view controller for each segue performed (though I could be wrong). Thus it's not only perfectly safe to use properties—it's expected practice.