I'm working on a car app.
I have a tabBar linked to different view controllers (CarInfoViewController is one of them).
I'm passing data to one of the view controller using the following way
CarInfoViewController *myCarInfoController = [self.tabBarController.viewControllers objectAtIndex:2];
[myCarInfoController setSearchParam:vin];
I want to know what is the difference between getting the view controller directly from the TabBar using objectAtIndex vs. doing the following :
CarInfoViewController *myCarInfoController = [[CarInfoViewController alloc] init];
[myCarInfoController setSearchParam:vin];
Both ways are working! I'm curious to see what is the best practice in such case.
I doubt that both work fine.
Unless, of course, when you create the view controllers programmatically anyway and it is the very myCarInfoController object that you created and add it to the tab bar controller later.
With your first statement you receive a controller from your tab bar. That may well be a controller which was created in Interface Builder or Storyboard Editor respecteively. Of this view controller you know that it is the one in tab no. 3 (index no. 2)
Your second statement allocated a brand new instance of your CarInfoViewController. Assuming that there is one already that was created before (in IB or so) and resides as 3rd controller in your tab bar controller, then you have two intances of the same class which are not related to each other. if you know pass any data to myCarInfoController (of variant 2) then nothing at all will happen in/to that very instance that is acutally used by the tab bar controller.
Related
I am interested in creating an app that starts with a menu which may possibly contain an options view, then steps from the menu view to a data-item selection view, then to a configuration view, and finally a result view that displays progress or changes. I want to have this process be repeatable like a loop, and have the user be able to jump backwards to a previous view if necessary. Jumping from view to view would of course be a user input / output with a button or something. FYI, I am using Xcode 5.1.1.
What would be the best approach to this? What kind of view controller is going to do the trick? I have heard a lot about navigation controllers, tables, etc.. but am having a hard time figuring out what to use in my case.
Below is a state-diagram similar to what I would like to do...
A UINavigationController should work great as your root view controller. It automatically includes a back button, and you can use the popToRootViewController method to return to the root of the navigation controller. You can set up a navigation controller as your root view controller from the applicationDidFinishLaunching method using this code.
MainMenuViewController *mainMenuViewController = [[MainMenuViewController alloc] init];
UINavigationController *navController = [[UINavigationController alloc] initWithRootViewController:mainMenuViewController;
self.window.rootViewController = navController;
For more information take a look at apples UINavigationController programming guide https://developer.apple.com/library/ios/documentation/uikit/reference/UINavigationController_Class/Reference/Reference.html
Each of your other screens may use different types of view controllers depending on their specific needs. If you need to display a list of items, definitely look into a UITableView. Apple's documentation for a UITableViewController can be found here https://developer.apple.com/library/ios/documentation/uikit/reference/UITableViewController_Class/Reference/Reference.html
I have read here a lots of questions and answers regarding segues and story board , and i became even more confused about the way i build the hierarchy between views
My questions are very basic and simple, and i think they may be helpful to others :
1.In a simple words, when should i use push , modal, or costume segues ?
2.When go from view1 to view2 to view3,how should i go back from 3 to 1? can i just drag a segue from 3 back to 1? and what happens with 2 and 3 with memory aspects in that case ?
3 when dismissing a view, why it always go back to the previous view? is there a way to make a segue that dismiss automatically the previous view ?
I think a very simple and short summing on the way it works would be so helpful.
thanks.
If you are using Storyboards and segues you may want to take advantage of exit segues for going back. In your example you want to go from View 3 back to View 1. Depending on how you got there, you may have multiple options to go back. For example, if you used a UINavigationController and pushed your way there, if View 1 is the rootViewController you could simply call popToRootViewControllerAnimated: and it would handle what is necessary to get from wherever you're at in the navigation stack back to the root. If View 1 is not the root you could opt to use the popToViewController:animated: API instead, assuming you have a reference to View 1 from View 3 which usually isn't ideal if you're keeping concerns separated. As Renish pointed out you do have the option of accessing the viewControllers property of your navigationController.
Back to Storyboards, for better or worse, they can handle this all for you via an exit segue. The storyboard configuration determines the proper way to go back to a view that you came from. Check out this great explanation in this answer, https://stackoverflow.com/a/15839298/250190
I think u want How to Go 3view to 1view.Simply make array of Your view controller.
How do I get the RootViewController from a pushed controller?
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UINavigationController_Class/Reference/Reference.html#//apple_ref/occ/instp/UINavigationController/viewControllers
Use the viewControllers property of the UINavigationController. Example code:
// Inside another ViewController
NSArray *viewControllers = self.navigationController.viewControllers;
UIViewController *rootViewController = [viewControllers objectAtIndex:viewControllers.count - 2];
This is the standard way of getting the "back" view controller. The reason objectAtIndex:0 works is because the view controller you're trying to access is also the root one, if you were deeper in the navigation, the back view would not be the same as the root view.
Now, I have a table view called Products with a add button on the navigation bar. When click on add button, the new view controller will be pushed to show which called AddItem. Here is the thing, Can I open a new view controllers A from AddItem and reopen Products from A?
May be my description a little bit confused.
ProductsTableViewController --(Push)--> AddItemViewController --(Modal/Push)--> AViewController --(Modal)--> ProductsTableViewController(Should be exact same as the first one)
And there may be some controllers between AddItemViewController and AViewController.
I have two solution:
1. When open ProductsTableViewController from A, get the same instance as before
2. Create a new instance of ProductsTableViewController and get data from an singleton class.
My concern is that is there any memory leak or protential risk?
your best bet is to use delegates. not sure why you want to do this, but if you have all your vcs in the stack, and your "ProductsTableViewController" is the root, then just have it move to the top of the stack.
I just have a quick question about recommended ways to implement a master-detail view hierarchy in iOS--the kind where selecting a row in a table on one screen pushes a details view for that item onto the navigation stack.
Specifically, should I reuse the same instance of the details view controller and just change its target and reload it each time, or should I instantiate a new instance of the view controller each time?
I'd prefer the first method, as it just seems generally more efficient, but I'm having trouble figuring out how to set the target and do the reload (especially the first time, when the view controller has not yet even been initialized--I'm using storyboards and that pretty much handles all of the initialization itself).
Or perhaps instead of setting the target on the child view controller, I could set it on the parent, such that each time the child view controller is shown, it reloads itself based on the parent selection? That actually sounds like the best bet so far, just looking for tips/warnings from anyone who's run into this before.
First, there's nothing wrong with creating a new view controller each time. If you use segues, that's what you'll get, since segues always instantiate new controllers. The detail controller will be deallocated when you pop or dismiss it anyway, so it won't persist.
If you want to use the same controller, you have to do your push or presentViewController in code. You can still setup the controller in the storyboard. Give it an identifier, but don't connect it up with a segue. In code, you check for the existence of your controller (you'll need a property for it), and if it doesn't exist, create it.
if (! self.detailController) {
DetailController *dvc = [self.storyboard instantiateViewControllerWithIdentifier:#"MyIdentifier"];
}
self.dvc.whateverProperty = self.somePropertyIWantToPass; // pass some date to it
[self.navigationController pushViewController:dvc animated:YES completion:nil];
What is the difference beetween calling presentModalViewController and pushViewController, when :
animation is set to NO (even if yes, that's just an animation style that can be changed).
a navigation controller is defined when presenting the modal view, so it can be navigable too, with a call stack, ....
Is this just to be able to go back from the first pushed view ? Woooaaaaaa.....
I guess the difference is elsewhere and deeper. No ?
Ignoring transitions/animations and how things are structured behind the scenes (which aleph_null's alswer provides a good discussion of), the only user-facing difference is the ability to return to the preceding view automatically using the navigation bar.
If you use pushViewController you will automatically get a "Back" button in the navigation bar. If you use presentModalViewController you do not, and generally will have to implement your own controls and/or callbacks to handle dismissing the controller.
Conceptually the modal presentation style is generally used for atomic tasks that you cannot navigate away from (i.e. you either complete the task, or you cancel, and you cannot do anything else within the app until you do one or the other).
If you're wondering why have the difference in the first place, I can't say. Personally I think frameworks that provide a unified API for moving from one controller to another (like cocos2d, or Android) make a lot more sense.
The most important difference is about semantics. Modal view controllers typically indicate that the user has to provide some information or do something. This link explains it more in depth: http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/ModalViewControllers/ModalViewControllers.html
Here's another, less abstract difference they talk about:
"When you present a modal view controller, the system creates a parent-child relationship between the view controller that did the presenting and the view controller that was presented. Specifically, the view controller that did the presenting updates its modalViewController property to point to its presented (child) view controller. Similarly, the presented view controller updates its parentViewController property to point back to the view controller that presented it."
Also see this thread: why "present modal view controller"?
Take a look into the viewControllers in the image
The top 2 viewControllers(login & submit) at the top left are disconnected from the tabBarController & NavigationController
The rest of the viewControllers are embedded in a NavigationController. They somehow belong to the natural flow of the app.
Now you have to ask yourself
Do I need to always show login + submit page every time? It would be pain in the neck for the user to each time go to login even if they logged in last time. These 2 screen really don't fit the natural flow of the screens. So what do we do? We just add them modally using presentViewController
However for the rest of the viewControllers we want to keep them inside 2 navigation so we can easily go back and forth so we use pushViewController
For more information I recommend you to see this video
The image was also picked from this great answer. It's worthy of a look.
This is what my experience says,if you want to manage a hierarchy of views,better go for pushViewController in the navigation controller. It works like a stack of view-controllers in the navigation controller. If however the requirement is just to show a view on executing some actions on the parent view controller then the best way is presenting it modally.
If you need a complex push pop logic always prefer a pushViewController.
UINavigationController are used when you want to have some sort of hierarchal representation of your data (ie drill down). They work using a stack of UIViewController subclasses. Every time you “drill down”, you simply add another view controller to the stack. Then, the “back” logic is simply a matter of popping view controllers off of a stack.
You can check out this link:
http://www.icodeblog.com/2011/10/11/back-to-basics-an-introduction-to-view-controllers/