I am developing an app where I have create, display and change views.
I want to share the screen between these views, but I thought embedding the whole screen as a fragment is not advisable because fragments are for small reusable pieces.
However, embedding the screen as a view means I have to specify a controller, but I want to use the parent view's controller, as that implements the logic of the create/display/change action. (The views have some shared functions in a library file).
Is there a way that I can embed a view but still use the parent view's controller, or should I embed the screen as a fragment?
Related
I am coming from a Windows Visual Studio (VS) background, so I'm finding the Xcode environment, well, overly complex for lack of a better description.
I'm planning an app which will need 4 views (what I would call windows in VS).
1) The main (starting) view would have a Toolbar at the bottom which opens any of 3 views.
2) View A would have a Nav bar at the top for "Cancel" and "Done" which would return to Main.
3) View B would have a Nav bar at the top for "Back" which would return to Main
4) View C would have no Nav bar but would return to Main using a DoubleTap.
I'm finding it very confusing to piece this together without a straightforward example.
Where can I find some clear explanations of Views vs Controllers, what they're each used for, and how to use them, preferably with examples/tutorials/etc?
Online is best, books are fine.
I'm using Xcode 4.2, no storyboards (for ios 4.2 compatibility).
Thanks.
The general distinction between view controllers and view is something that you can understand independently of Xcode/Cocoa - it's a design pattern called MVC (Model, View, Controller).
In MVC, your application structure is split into 3 layers:
1) The model is your data layer, such as files, databases, network services, and objects that exist independently of the display such as a user.
2) The view is what you see on screen. A view is often composed of several sub views in a hierarchy, for example a window (which is a type of view) contains a toolbar (another type of view) and some buttons (each a view), labels, text fields, etc. These are all views.
3) The controller, aka view controller is the glue that connects these two together. A user object for example has no idea how to display itself, and a label has no knowledge of a user object, so it is the job of the view controller to tell a particular label to display the name of a particular user. Similarly when you type text into a text field, the text field doesn't know that text is a password, so it's the job of the controller to take that text and store it in the correct place, or submit it to the correct web service, or whatever.
So basically a controller converts your model data into the right format to display within your views, and handles feedback from your views (a button press, a text entry, etc) and modifies your model accordingly.
In cocoa every view controller owns a main view (it's "view" property) and may also manage the subviews of that view such as buttons, labels, etc.
Normally there is one view controller class per screen of your app. Occasionally parts of your screen that have standard behaviours are managed by other view controllers.
So for example the navbar is managed by something called a navigation controller. A navigation controller actually manages a stack of view controllers as well as the navigation bar view itself. When you push or pop a view controller onto the navigation controller stack, it makes sure that the view from the current view controller gets displayed and that the navbar shows the correct title. When you tap the back button in the navbar view, the navigation controller receives that button event and pops the current view controller (and it's associated view) off the stack.
The advantage of this approach (MVC) is that is massively cuts down on the amount of subclassing you need to do. Every button on your screen is probably just an instance of a standard UIButton object. You don't need to subclass each button just to change it's behaviour because the button doesn't need to know anything about what happens when it is pressed, it just delegates that press to the view controller to manage.
Generally, you rarely need to create custom view subclasses. Almost all of your application can be built by arranging standard views on a screen and managing them with a custom view controller subclass.
Nibs/xibs are particularly useful for this because they let you visually lay out your views and visually bind their actions (e.g. button taps) to methods on your view controller using drag a drop. This saves you filling up your view controller with pointless layout code (create a button with these coordinates and this colour and attach it to this subview, etc). Unfortunately nibs can be confusing for new developers because they hide a lot of what is going on behind the scenes.
For multi-screen apps, iOS provides a set of so-called container controllers, which are controllers that manage multiple sub-controllers. UITabBarController and UINavigationController are the main examples. UITabBarController is good if you have several screens that you want to tab between, UINavigationController is good if you have a hierarchy of screens that the user can go back and forth between like a browser.
If you scroll down a bit at this Apple Developer Page you'll find the section "Creating an Alternate Landscape Interface". The basic approach described there is to present a different NIB file as a modal view when orientation changes. I am using the Storyboard feature, so I don't have NIBs. How do I load a different "scene" in that case?
Besides that, I am using a Tab Bar controller, I don't want to show a modal view. I just want to replace the current portrait view with a landscape view designed with interface builder and keep my tab bar. What would be the Storyboard way to achieve the task "Creating an Alternate Landscape Interface"? Thank you.
When you add a view controller to the storyboard it comes with a view. Call that the container view. Add two views to the container view: a portrait view and a landscape view. Set the dimension of the portrait view and the landscape view appropriately using the size inspector. Add buttons, more views, labels or whatever to the portrait and landscape views as needed for your application. Then when the orientation changes hide one view and show the other.
You can setup a navigation controller and one main view. Then you can use a template view for the portrait and landscape layouts (2 additional views).
You will need to setup the controls on the main view and make sure each one has a unique tag. Your main view will not be used, instead you will copy the controls to the two template views and set them up based on how you want each view to look. The benefit to this is each view will retain its tag which becomes a very important piece of this implementation.
Doing this you use a hybrid approach in regards to writing some UI code and using Interface Builder. After getting the two templates setup, create a unique identifier for each one. You will have to write some logic to handle the view and its subviews. A recursive method to return a collection of these based on the template you choose.
The core logic in the root view controller implementation will need to check for isPortrait and based on this you will want to load the correct view based on the identifier.
Experiment with this concept and see if it works for you. The main benefits to not using two separate views with unique controls (not the shared approach with same tags) is that you maintain access to your original subviews. Any instance variables you define in your view controller that points to a text filed, label, etc... continue to do so regardless of which template view is used. This maintains the model, view, controller approach as the data structure remains unchanged.
Using this approach you can still maximize the use of interface builder, and layout the templates for each view, while still having the flexibility to to write some custom UI code if you desire. Using only interface builder can be a bit limiting at times, and writing custom code based on orientation locks you in to a bit of tedious work.
Hope this helps some.
You can make a xib file that contains 2 uiviews, one fore portrait and one for landscape.
Assign as file's owner of the xib, the same viewcontroller of the view thet you have in the storyboard.
In viewDidLoad load the xib file, and add the appropriete view for portrait or landscape.
So if you have a storyboard with many viewcontrollers, you can set the two possibility (portrait or landscape view) only in the viewcontrollers that you are interested to change the orientation.
I used this solution and work very fine !
I'd like to display some small tutorial dialogs on top of my exiting views. I want to be able to see my existing views behind these smaller views.
Do I have to use view controllers in the same I way I would me normal views, and presentmodalviewcontroller etc ?
I haven't tried making a smaller view in interface builder before.
Also, say I want to move to another one of my existing views, full screen, while in my tutorial view. How would I close my tutorial view move to the next full screen view and launch another tutorial view ?
Example code or pseudo code would be welcome.
If your tutorial dialogs are just text, you could use UIAlertView to show the information to the user, so they can just read it and click the OK button when they're done. It's a very easy way to show some text to the user.
If you need to include images or other interactive items in your tutorial dialogs, the easiest way might be for you to just have your fullscreen view's view controller create a new view and put it up. So in this case, you'd create your view in Interface Builder, and when you want to show it, instantiate it using -[UIBundle loadNibNamed:owner:options:] and add it as a subview of your main view. Of course, it may even be easier to create the tutorial view programmatically from your view controller rather than using a nib for them at all.
Regarding the question of moving on to another fullscreen view, you would probably want to look into embedding your view controllers in a UINavigationController. This would allow you to push from the first controller to the second very easily, and the user would be able to just tap the Back button to get back to the first. If you're not looking for a navigation bar type of interface, you could present the second view controller as a modal view controller by calling -[UIViewController presentModalViewController:animated:] on your main view controller. This will pop up the second view controller fullscreen, and the user can dismiss it when they're done. Check out Apple's great documentation on UINavigationController to get a feel for how to use that:
http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/NavigationControllers/NavigationControllers.html%23//apple_ref/doc/uid/TP40007457-CH103-SW1
I would think that you could use existing UIViewController and simply add a new UIView that is of desired dimensions, that sits in front of other views and which is non-opaque and has alpha less than 1.
If you want a general purpose tutorial mechanism that can be placed atop any one of many UIViewControllers, then you would want to extract the navigation logic, etc.
Sorry, no code - just a few quick thoughts.
I'm tinkering with an iPad app that (like many iPad apps) doesn't use the UINavigation root view control system, so I don't have natural ownership for each app "view". I essentially have two basic views: a document list view, and a document edit view.
I'm playing with UIView animation for getting from a selected document to the edit view.
I also have a toolbar on top that exists (with different buttons) in both "views".
Because I don't have UINavigation running the show for me, I have a tendency to just throw more and more stuff into one NIB and one view controller that owns the whole container. But now I'm trying to figure out how to segue from the document list view to the edit view if the edit view lives inside a different NIB, preserving the toolbar too.
Anyone have thoughts or experience on app structures like this? I find the docs lacking on best practices around code/UI structure for anything except trivial one-screen apps or full-on navigation apps.
You're not "supposed" to have parent/child view controllers owning subcomponents of the same "screen" according to the docs, but this implies one massive honking view controller that basically contains the whole app, and that can't be right.
Not sure if there's a "right answer" to this; I'm looking for some intelligent examples or suggestions. Nobody's touched this question in months, so I'm adding a bounty to generate good chatter. :)
Thanks!
UPDATE: I'm not talking about a split view, which is clearly well handled by a split view controller. Instead, take a look at Apple's iWork apps (e.g. Pages) which have a document list view and an independent edit view, but these are related by animation.
Maybe the real question here is: how would you (or could you even?) build a "container" view controller like the split view or navigation controller, yourself? Are you required to build the whole damn thing from scratch? I sense that you are, because seems to be hidden wiring in the interaction between view controllers. If so, thoughts on this?
I think the only hidden wiring in view controllers is setting parentViewController, which is required to support the categories declared for split and navigation.
View controllers are designed to be nested, with each controller owning a part of the view hierarchy. The only design goal is that no view controller reach into the view hierarchy of another controller. A parent view controller will usually have some call for adding child controllers so that it can set the frame of the view within the view hierarchy it owns. A child view controller should not do anything to the superview of the view it controls, as that is owned by another controller. Not should it set the center or frame of the view it controls.
For example, a navigation controller has a push method, in which it removes the previous controller view, adds the new controller view, and sets the frame of the newly added view. In general, a parent view controller is free to set the frame of the view of a child controller, but not the bounds.
If you want to change the animation of a navigation controller, I think you would start by implementing every method with an animated: argument. Set up your animation then call super with the animated flag off before committing the animation.
I haven't tried the multiple-view-controllers thing outside of the UIKit-provided ones (navigation/tab-bar/modal/etc) but I don't see why it shouldn't work. Under the hood, everything is a view, though I'll note that UIKit has special views for view controllers which no doubt have some kind of special handling by the system (UIViewController has a wrapper view, UINavigationController has a UINavigationTransitionView or something, ...).
I'd advise not worrying too much about "best practice" — just code something which does what you want. A couple of options:
Stick logic into view classes (ewwww!). One of our apps does this so it can handle rotation in a custom way (views slide in/out instead of rotating). We should've probably implemented our own view controller logic instead.
Break the model into components which correspond to views. Make each view know how to load its component and recursively load subcomponents. Then the view controller only needs to worry about "big picture" stuff.
Also note that you can load multiple nibs into the same view controller by e.g. connecting it to an outlet called editView.The big difference is that it's not done automatically by -[UIViewController loadView] so you need to do something like
-(EditView*)editView {
if (!editView) {
// Loads EditView into the outlet editView
[NSBundle loadNibNamed:#"EditView" owner:self];
}
return editView;
}
You'll also need to worry about adding it to your view hierarchy, unloading it on -(void)viewDidUnload (iPhone OS 3.0+), setting it up in -(void)viewDidLoad in case there was a memory warning during editing mode, etc...
It's not easy, but UI never is.
You need a master-detail view implemented with a split-view/popover-view and controlled with a UISplitViewController.
The master view is the document list and the detail view is the edit view. Each has its own controller. The two controllers themselves are managed by the UISplitViewController.
If you don't use the splitview controller you will just end up hand coding something that works very much like it. This is really the only way to do what you want easily in the API and it is the layout that iPad users will expect.
See Creating a Split View Interface in the iPad programming guide for details.
I have looked at the PageControl example from Apple and have an architectural requirement difference. In the example the scroll view and page control objects are at the app delegate level. This means the scroll view and page control appears on every view of the application.
However, I have a "settings" view toggled from an info button (for now) that should not have these controls displayed. Therefore, I need to move my scroll view, page control, and view controllers objects down a layer and I'm struggling with how to best do this.
For example, the primary application view consists of metals (periodic elements). From this view I need a scroll view, page control, and info button on every view descending from here. Each metal will have it's own subclass where different images, calculations, etc will be displayed but I believe I need each of these subclassed elements to share the same scroll view, page control, and viewControllers array, right? Do I need a singleton?
What you are describing is kind of like how the native Weather application works. Each time you swipe, the info light is rendered as part of the page you are viewing. However, no matter what info light you tap, when it flips over you still get the same settings. Obviously this is how Apple thinks the UI should work because they did it that way. There is no reason you can't do the same.
In this situation, you don't need to create a singleton, you can use [UIApplication sharedApplication] as your singleton to get to your custom application delegate via the delegate property.
Look at Crème where I do exactly what you describe. The main view is scrollview+pagecontrol. Upon triggering the app into settings mode, the settings panel comes up that does not have a page control.
The solution is simply that you have a simple top-level UIViewController, and you make both the scrollview and pageview children of that viewcontroller. And for settings, you animate the modal settings dialog with a flip animation into the top-level UIViewController.