After looking for many hours to find a working view switching code, I finally found a great tutorial on YouTube. It was exactly what I needed as I needed to switch views when buttons are pressed.
I just wonder if the techniques used in that video are valid. The used code to switch screens is
viewsViewController *second = [[viewsViewController alloc] initWithNibName:nil bundle:nil];
[self presentModalViewController:second animated:YES];
Where viewsViewController (or any class that is used there) is a class that's a subclass of UIViewController. This class is made by clicking File > New File > Add UIViewController subclass.
Is this method according to the Apple guidelines? Is this method memory friendly?
I sure hope the technique is valid. All other examples contained too little information so I couldn't make the example to work. And this is very stylish and short code which works .
That's one way to do it. When you present a view controller modally, there's some expectation that the view controller will go away at some point and the user will return to the parent view controller.
Another option is to employ a UINavigationController, to which you can send -pushViewController:animated: messages.
Yet another way is to let a UITabBarController switch view controllers for you when the user hits the corresponding tab.
One more: you can set the window's rootViewController property, at which point the window will add the view controller's view as a subview of itself.
Your best bet is to read through the View Controller Programming Guide for iOS.
This is one way of doing it. Be aware of some issues. Both views will be in memory, which is okay if they are a reasonable size. The modal view animates above the parent.
There are other models that you can use for simple navigation, if that's your main goal. I would suggest looking at UINavigationController and see if that might better meet your needs. It is probably the most common method to navigate views and provided a lot of the foundation of view management saving you that effort.
Related
So I pretty much built my first app(single view) but i've now decided I should add a little "about/info" button and just give a tiny amount of information on how to use the app and a website to go to.
I wasn't sure about the best way to go about this but storyboards seemed really convenient. A user here answered my question about adding a storyboard to my existing project which seems to work.
Now one question is can I use my current viewcontroller h and m files for the second view (the about screen). I suppose it would technically work if I set the Viewcontroller to the same one as my primary app view.
the only thing this second view is going to have is text and a button to go back. Is it OK to set the connections in the storyboard and just let them use the same Viewcontroller files or is this a big no-no?
Thanks
It is recommended you use a different view controller for each view. In case of a static view controller in which the user doesn't interact with the view except maybe for navigation (which can be handled in the storyboard in many cases), I would just leave that view controller as a generic UIViewController, not a subclass.
Yes you can use the same view controller to control more than one view, however, from what I understand, that doesn't seem like good practice in your case
For instance, if you had similar views with almost identical outlets (say the views have the same UI widgets such as buttons, titles but their layouts vary significantly) you co[uld create a separate view for each different layout and use a single view controller. But from what I understand, in your case, those two views will have different outlets (buttons, labels, etc.)
For this reason, I'd suggest creating a new view controller. Then when you want to show this second view, you will have to present it from your active view controller. I'd highly recommend you read tutorials on view controllers in Apple developer resources. But very quickly, I'd suggest the following
UIViewController *vc2 = [[UIViewController alloc] initWithNibName:#"View2" bundle:[NSBundle mainBundle]]
[self presentViewController:vc2 animated:YES completion:nil];
And to go back to your main view, you'll have to dismiss this second view controller
[self dismissViewControllerAnimated:YES completion:nil];
Of course, they don't have to be animated, you can set them to NO.
Im officially getting annoyed with objective-c and xcode now. Programming in PHP and Java is so much easier haha.
Anyway I could do with some help.
I have created a tab bar application with three tab items for the iPhone, on one of the items it loads a nib named mapView, this contains a button that I want to use to load up another nib named OverlayViewController.
Ive been following this tutorial this tutorial
to create a camera overlay. I understand how it works, but I don't understand how to run the view controller from a button or direct from the tab bar. I can only get the overlay to work if I load it like in the example on application launch in the app delegate. If I try and load it from the tab bar item I just get a grey screen, looks like the blank view controller is loaded and the code hasnt been run to show the overlay.
If anyone can suggest how I would go about loading the overlay from the button click, or even direct from the tab bar item I would be really grateful.
Thanks Alex
p.s. Heres the link to the project if you wish to view the files
#AlexApps I took a look through your project and have several pieces of feedback.
I think before you get too into trying to get the OverlayViewController working you should back up a bit and give some of the Apple docs a read, especially the View Controller Programming Guide. The Apple docs are for the most part well written and should help you gain a better understanding of views and view controllers than what is evident in your code.
Another suggestion is to grab some of the freely available source code from a book such as Beginning iPhone Programming which has a good example of how to lay out a tabBarController based app. I am sure there are other good samples out there that will show you how to organize your views and view controllers to load them into the different tabs.
I think that if you follow this advice that by the time you have restructured your app by what you learn you will have less problem doing what you are trying to do.
BTW, you may want to consider using a NavigationViewController for what you are trying to do with loading the OverlayViewController with a button press but take a few hours, slow down and do some focused reading. It will make a world of difference. Then if you have more specific questions, Stack Overflow (and Google) are your friends.
One last tip, you do not need to put IBOutlet in your instance variables AND in your properties, just one or the other, and really, you don't even need the instance variables at all anymore. I usually just use properties for everything.
I have done it with storyboard and the solution is to create a segue between the tab bar view controller and the view controller you want to load, then you have to put an identifier to that segue. Finally, in the method called when the button is pressed you have to put this:
[self performSegueWithIdentifier:#"segueId" sender:sender];
I have done it right now and it works perfect!
First import uiviewcontroller class in frist page like below:
#import "page2viewcontroller.h"
on button click event code below:
page2viewcontroller *page2 =[page2viewcontroller alloc] ;
[self presentModalViewController:page2 animated:NO];
[page2 release];
after back page2viewcontroller to page1viewcontroller same as like below:
#import "page1viewcontroller.h"
on backbutton click event code below:
page1viewcontroller *page1 =[page2viewcontroller alloc] ;
[self presentModalViewController:page1 animated:NO];
[page1 release];
That's all....!
I have a three view tab bar app the second view of which I want to contain a navigation controller. in the navcontroller the first/root view will be a custom uiview containing a uitableview that when you touch a cell will push another custom uiview in to disclose details about the touched cell.
I have found the documentation on doing this but it is not making sense to me or seems to be flying over my head. The docs say that you have to create the uiviewcontroller located in the navcontroller views or at least refer to them programatically. I have been using Interface builder and have become quite comfortable using it, so doing it programatically scares me a bit.
Also, This piece of code from the documentation seems troubling:
- (void)applicationDidFinishLaunching:(UIApplication *)application {
[window addSubview:myNavigationController.view];
}
above taken from "ViewController Programming for iPhoneOS" apple documentation
wouldn't this load up and display the UINavigationView immediately?
one problem is I dont want to display the navView immediately. the navController/stack is a secondary tab. So how and where do I impliment my navController(right now I have it instaciated in my delegate(which I think is correct)? I've been able to load up a basic UInavigationController with a navigation bar and a blank view, --minus the custom content view, through interface builder but I'm at a loss as to how to populate the custom content views.
Hope this makes sense.
Any help would be appreciated,
Nick
The first thing to understand is how UINavigationController works. It pushes UIViewControllers, not views. So, when something happens in your second tab (where the UINavigationController lives) you will push a UIViewController onto the stack.
This is typically done in:
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath;
Which is part of the UITableViewDelegate Protocol.
So, when tableView:didSelectRowAtIndexPath is called, you need to figure out which UIViewController to push onto the stack. You can either load this View Controller from a nib, or create it programatically. Since you feel comfortable with IB, I would suggest loading it from a nib.
I would not worry about trivia like "where should I instantiate my UINavigationController?" right now. First, get it working. Then worry about where things "should" go.
It might be best to get the UINavigationController stuff working in a separate project, then fold it into your main project. This lets you ignore lots of little details while you focus on the Navigation Controller.
I'm learning this right now so the questions might be a little juvenile. Here's what I'm trying to do. I have the first view come up with a cell of the table populated statically, when you select one of the cells it will pull up a form to input data.
Now, I've been reading the documentation about navigation buttons and navigation in general and it seems that I need two separate viewControllers. One for the basic app and another for the new page being brought forward when the cell is picked. Is this correct?
Sorry, this might be a little bit basic but I'm not sure what to do here. Thanks.
That is correct. You would have two view controllers: a "root" view controller that is the top-most view, and the second view controller that contains the editing form.
The second view controller would get pushed onto the navigation stack when you tap a cell.
Basically you need to create a second UIViewController subclass, this viewcontroller needs to be attached to your main window when switching views.
-(IBAction) SwitchView:(id)sender
{
MySubViewController *subViewController = [[MySubViewController] alloc]
initWithNibName:#"SubView" bundle:nil];
self.view insertSubView:subViewController.view atIndex:0];
[subViewController release];
}
Yes, you need two view controllers.
Check out lesson 7 from Stanfords CS193P iPhone Application Programming course. It is available online. Both slides and the lecture through iTunes U.
CS193P iPhone Application Programming
I really enjoyed watching the course!
I have always sort of wondered when to use a UIView vs. a UIViewController on the iPhone.
I understand that you shouldn't use a UIViewController unless it's a full-screen view, but what other guidelines are there?
For example, I want to build a modal overlay - a screen that will slide into place over the current screen. If this modal overlay is full-screen, should it be a UIViewController? The last time I built something like this, I subclassed UIViewController, but now I wonder if that was correct.
From Apple's View Controller Programming Guide for iOS:
"The most important role of a view controller is to manage a hierarchy of views. Every view controller has a single root view that encloses all of the view controller’s content. To that root view, you add the views you need to display your content."
Also:
"There are two types of view controllers:
Content view controllers manage a discrete piece of your app’s content and are the main type of view controller that you create.
Container view controllers collect information from other view controllers (known as child view controllers) and present it in a way that facilitates navigation or presents the content of those view controllers differently.
Most apps are a mixture of both types of view controllers."
This is a great question.
My basic rule of thumb. Is that every major 'page' of an application gets it's own view controller. What I mean by that is that during the wire framing stage of application design, everything that exists as its own entity will eventually be managed by its own View Controller. If there is a modal screen that slides over an existing screen, I will consider that to be a separate 'page' and give it its own view controller. If there is a view that overlays and existing page (such as a loading screen or help popup.) I would treat those differently, implement them as UIView subclasses and keep the logic in that 'pages' view controller. It the popup has behavior I will communicate back to that pages View Controller using the delegate pattern.
I hope this helps. It is very much a philosophical and architectural question and much could be written about it.
I use UIViewController whenever a view is full screen and either has outlets/actions and/or subviews.
Put everything on a screen into a UIViewController until the view controller starts to have too much code, then break out the screen into multiple UIViewControllers contained by one master view controller...
To put that into context of your answer, make a view controller for that modal overlay. It will have one anyway if you are using a nav controller to present it (and you probably should).
I have a somewhat different approach:
Override UIView if you plan to do custom drawing in drawRect. Otherwise, subclass UIViewController and use [self.view addSubview: blah] to add the components of the page.
There are a few other special cases, but that handles about 95% of the situations.
(You still will often need a UIViewController with a custom UIView. But it's common to have a custom UIViewController with no corresponding custom UIView.)
Is the thing that slides in a self contained screen? I mean, does it directly interact with the parent? If so, make it a UIView, if not, probably recommend a UIViewController.
A UIView is part of the UIViewController see the view property of UIViewController for this. As you pointed out correctly UIViewController manages a complete screen and there should be only one visible UIViewController at a time. But in most cases you will have more UIViews or subclasses of UIView visible on the screen.
The example you gave would be a correct use in most cases. As you may have noticed you will get a lot of functionality when subclassing the UIViewController. Animating the appearance and dismissal of the UIViewController would be one of them.
As marcc pointed out if the thing you want to slide in is not a self contained screen you would be better off using a UIView.
As a conclusion I would say that if you want to use the functionality that comes with subclassing UIViewController than go for it make it a UIViewController. Otherwise a UIView might be better.
The itunes U Standford class has a great lecture on UIViewControllers I would recommend watching it, because it has a lot of information regarding UIViewControllers in general.
If you are familiar with the MVC pattern, then you should be able to understand the difference between UIVIew and UIViewController. To make a simple statement, UIView is for rendering UI elements on screen. UIView is the superclass of pretty much all Cocoa Touch UI elements. Those elements do not know what information they are supposed to display, what they should do when a user clicks a button, what happens when an async network request is completed and so on. UIViewController is for all that and more. The view controller is responsible for placing the UI elements in the correct locations on screen, setting the contents of the UI elements, handling button presses and other user inputs, updating the model when needed etc.
Conceptually, a single UIViewController controls the contents of the whole screen in an iPhone App and that is why it is often easy to think of things in terms of view controllers. If you need a view where the user can select ingredients for a food recipe, you'll need a UIViewController for that. I made this distinction for myself because coming from a Java background I wasn't used to the framework enforcing MVC. I would think of things in terms of UIViews, and start implementing them that way and then run into all sorts of trouble because of that. If you are going to stick to UIKit for your App, then the workflow Apple has made for you is: for each separate view in your App, create a UIViewController subclass and then use Interface Builder to place the UI elements and to create connections for buttons etc. It works wonders, saves a ton of time and lets you concentrate on making your App function well.
I use UIViewController for showing View on full Screen.
For better control on custom view I prefer subclass of UIViewController instead of UIView, earlier I was using UIView for making custom sub class.