Let's say, I have a scene (pushed view controller with a navigation bar), which displays some tabular data in a table view.
In the navigation bar of that scene I have a + sign, which should open a new scene, where the user can add a new item (row to a core data table).
In the table view, each row has an arrow on the right side of each cell, which opens a scene where the user can edit that particular item's details.
Should I use a push or modal segue for the +?
Should I use a push or modal segue for the arrow?
What is the "best practise"?
I understand the difference between push and modal segues, but I want to know which is better suited for the above use cases.
If you want to follow Apple's best practices, I would suggest the following :
For the "Add" functionality, use a modal segue.
For example look at the contacts app. Pressing + shows a modal view controller.
What's the logic ? for start, modal view controllers usually have a "cancel" button, as opposed to the "back" button on a pushed vc.
When the user presses "back" - he'd expect a way to come back to the vc. Usually "back" saves your data on iOS (auto-saved).
So by using a modal segue you force the user to submit the form , or cancel. The modal presentation hints that you really need to fill this screen.
For editing - push. but modal could work as well (and you could reuse the same VC).
Reasons for push :
you get a hierarchy of vc's , going back and forward while drilling down.
(you should implement) auto saving when going back (just like other iOS apps)
For adding a new entity to the core data table, on tapping the + button (I assume its a right bar bar button item on the navigation bar), use the modal segue.
The view for adding a new row for the enity has to be presented modally and once the save is completed, dismiss the modal view and reload the table view to display the newly added item.
Also for displaying the details of an entity row, use the push segue. A user expects a push action when he selects a table cell and it is the ideal way to do that.
I hope this quick summary will help you :
When you want to show a detail view of a summary view, use a navigation controller and Push Segues. If the "parent" view doesn't really relate as far as data is concerned to the "child" view, then use a modal. A good example for a modal view would be any entry view. This view doesn't really have any relationship as far as data is concerned to the "parent" view., the entry screen will just take data dat from user & will save & can go away & giving control back to parent
Related
I'm currently implementing an app really close to the native Contacts app. The app consists of:
A Master View listing items
A Detail View showing the selected item details
An add button to add an item which:
Allows to take a picture if the camera is available then go to the input view (a form basically). The camera is presented modally.
Directly goes to the input view (the form) is no camera or no authorization. The input view is presented modally.
The QUESTION
When the user presses the OK button after filling the form in the Input View, how can I jump to the Detail View, with the Back Button of the Detail View pointing towards the Master View (and not the Input View where the user comes from) ?
This is exactly the behavior of the native Contacts app, when you add a contact and press OK, you land on the Detail View with the back button leading to the list of contacts.
Here is how my storyboard looks like:
I searched a lot for a solution, but nothing good sor far...
Thank you in advance for the help.
MasterViewController is a NavigationController.
DetailViewController is a ChildViewController of MasterViewController
CreationViewController is presented modally from MasterViewController
You need to provide delegate for the MasterViewController to know the CreationViewController have finished the creation flow and the created info. Then you dismiss the CreationViewController in MasterViewController. Finally, you push DetailViewController with the created info.
I just started with Xcode and Swift.
I try to build my first little App for iOS. But now I have the problem, that I don't know how to implement a the back button, so that i come back to the view before.
My Storyboard look like this:
When I open the A-Z view, I want to display the Back Arrow, which turn me back to the Item 2 view.
To open the A - Z view I connect the button "Medikamente A - Z" with the Navigation Controller.
When using storyboards the back button is usually implemented with unwind segue.
I usually like to follow raywenderlich toturials on UI related topics, like this - http://www.raywenderlich.com/113394/storyboards-tutorial-in-ios-9-part-2
It include a detailed example of how to implement back button in storyboards. Quoting from it -
Storyboards provide the ability to ‘go back’ with something called an unwind segue, which you’ll implement next.
There are three main steps:
1. Create an object for the user to select, usually a button.
2. Create an unwind method in the controller that you want to return to.
3. Hook up the method and the object in the storyboard.
When using UINavigationController, whenever you push to a new ViewController the back button will automatically appear, so you can jump back to the previous View Controller.
So it's works like:
UIViewController -> UIViewController -> UIViewController
A back button will appear on the last 2 so you can pop back the the previous ViewController.
You don't have to do any additional coding for the back button to appear, it'll do it on its own. I hope this clears it up. Let me know if you have any questions.
To implement a back button, your root view controller has to be a Navigation Controller.
The first view controller becomes the navigation root of the navigation controller.
If you want to present another view controller, you select a "Show Detail" relationship as the action for the button which should show the view controller. To do this, Ctrl-click and drag from the button to the destination view controller and select "Show Detail".
I had the same problem, even when on the storyboard the back button was visible at design time.
I deleted the segue, and recreated it with "Show" instead of "Show detail". Changing the segue to "Show" had no effect. I think this is a bug, so if you miss that back button delete and recreate the segue.
I cannot find the answer to this although I have implemented this rather a few times already, but maybe the wrong way.
Say I have an App for iOS, it has a main screen, which goes to a list, that list has a < back (to main) and an add button. Now when I click < back, I go back to main as that's the pop() from the stack. No issues so far.
Now when I click the add button, that is added to the stack as well; when I click back on that screen I go back to the list which is fine.
The problem is; when I save the new item, I want to go to the detail screen, but I don't actually want to have the add screen on the stack anymore while it will be there. I want the < back button for the detail item pointing to the list.
I know how to do this, but what is actually the best to implement this with the navigation stack?
Well for adding elements the best practice is to present an ModalViewController.
In this way it is not added to the stack.
Update
Let's take as examples simple apps that apple provide with iOS, Contacts app. When you want to add a new contact a VC is presented.
You'll need to implement "Done" or "Save" button that will dismiss the modalViewController and if you want to take the user into detail screen you could post a notification or other mechanism on dismissViewController method's completion block that will push the detail page from the list. But be careful on animations if you dismiss the modal VC animated and push the detail page animated you could get some unexpected behaviour. My proposal is to dismiss the Modal VC animated and push the detail page without animation.
You can override UINavigationController's viewControllers property after you pushed detail view controller. Just get current viewControllers property array, iterate and find the one you don't want to see and remove it. Remember to set viewControllers array again.
https://developer.apple.com/library/ios/documentation/Uikit/reference/UINavigationController_Class/index.html#//apple_ref/occ/instp/UINavigationController/viewControllers
I don't know when I should use Navigation Controller instead of use segue with normal View Controller?
And if use segue, which different between Modal and Push segue?
Can you give me an example?
Short answer: Use a Navigation Controller with "show" segues only to implement DRILL DOWN behavior.
For example,
Navigation Controller → Authors → Books → Book
For each level below the "root" (Authors), the Navigation Controller automatically adds the title bar and back button. So on Books, the back button is automatically named "<Authors".
The child View Controllers must be connected with SHOW segues -- show segues tell the Navigation Controller "this is a parent-child relationship" and cause the expected slide-in-from-the-right transition. (To jump outside the hierarchy, for example, Books → Login, use a modal segue instead.)
The root View Controller has a navigation bar that you can add more bar buttons to, but child View Controllers don't, because it's added automatically.
FoodTracker Example
Now the odd-seeming layout of the FoodTracker tutorial in Apple's Start Developing iOS Apps (Swift) can be explained. **What's up with that second nested Navigation Controller? It's just a simple list of meals: tap a meal to show it in Meal Detail, or tap Add to and Meal Detail becomes Add Meal.
FoodTracker Storyboard
The first Navigation Controller makes My Meals the root of the drill-down hierarchy for any number of views "pushed" from there on (no further Navigation Controllers are needed just to do that).
But, Meal Detail is used for both displaying an existing meal and adding a new meal. To add a new meal, Cancel and Save buttons are needed. The second Navigation Controller allows those buttons to be added (see 3rd point above) by making Meal Detail a root.
Displaying an existing meal is a push segue, but adding a meal is a modal segue (a new meal isn't a drill-down). This is important: the reason Add Meal can't just be pushed is that the automatic back button ("< My Meals") becomes ambiguous: does it save or cancel?
Because "navigation" and "push" are very general terms, and because it's nice to get a free back button, it's tempting to think Navigation Controllers are to go from anywhere to anywhere, but the behavior is intended just for hierarchical traversal.
(This is an old question but I was also confused about this as an iOS n00b and like the OP I still had questions.)
In my experience, there is no a general rule to decide this kind of things, it depends on the usability of your future App...
Navigation controller helps the user to remember where they are in every moment, and how they can go back, but could not be the best thing to use if you have too many levels... And more important, if you are using a NavigationController or a TabBarController, you have a class, accessible from all the other ViewControllers where you can have general functionality or data...
The difference between the modal and push segue is that in the first you will always return to the parent ViewController, because you are only showing new information on top, while in the push one you are replacing one ViewController with other...
You use navigation controllers when you want to enable back button functionality. You still use 'normal' view controllers, you just embed them in a navigation controller. Then, you can push view controllers and be able to go back.
I'm developing an iOS app just now with a Tab Bar navigation.
I have two screens which show the same information but in different formats (say, list and grid).
The two screens are different enough that they require separate controllers.
Users can toggle between the two views from a shared control bar button (toggle) at the top.
Scenario:
User presses the 'Places' button for the first time and it shows the places as a list.
They press 'grid' to see the same places displayed as a grid.
The user presses another tab bar button to navigate to a different screen.
When they press the "Places" button again, the app remembers their last viewed screen for places was the grid so the grid view is shown.
The user may then toggle back to list view. etc...
Can anybody recommend the best approach to achieving this?
One approach is to use one view controller that manages both views. That way, you don't have to bother with synchronizing data or subverting the normal function of UITabBarController -- there's just one controller. Also, don't try to overload the meaning of the tab for that controller. Instead, add a button to both views that tells the controller to switch to the other view. That'll be easier for your to build, and (more importantly) easier for the user to understand. It's not nice to make familiar controls do unfamiliar tricks.
If your view controllers are such that combining them into one would be complicated, then you can use two controllers and simply swap them in and out of the tab bar by modifying the tab bar controller's viewControllers array. You can still avoid having to sync data between them by having both controllers refer to the same data model.
I was trying to achieve this same thing, and it can actually be done with a basic setup of a TabBarController, NavigationControllers, ViewControllers, push segues, and unwinds.
TabBarController
|==> NavigationController --> PlacesController(grid view) --(push segue from nav bar)--> PlacesController(list view)
|==> NavigationController --> OtherController
|...
Make sure to have an unwind segue back from the list view controller to the grid view controller.
If you toggle between views then go to another tab (e.g. otherController) and come back, you'll return to the last view you were seeing because that's what is at the top of the stack of the NavigationController.