I have a simple table view controller which has a plus button in the navigation bar. That modally leads to a place where users can insert information into text fields. These are situated throughout the view controller.
When it comes to editing a cell from the table view, I use a "Push" segue instead of modal because that seems more natural for the user experience rather than a view controller coming up. I have created a new view controller for the "editing" with the same text fields in the same location.
When I use the push segue, all of the text fields are a long way below where they should be. I've checked the x,y position and it's exactly the same as the modal view to add.
When I use Modal, then everything is exactly where it should be.
My table view is embedded inside a navigation controller so I thought when I push to another view, it would just accept that in the navigation controller.
Please could anyone shed some light on this as to why with a push segue, I'm getting messed up views, and how to fix this?
Thanks!
When doing the push is your controller using the whole height of the screen or not?
Could be the navigation bar and status bar are causing them to be out of place where as in the modal you would only have the status bar if not hidden
Related
I want to achieve something similar to Facebook's way of presenting the comments view controller for a specific post. In below picture one can see, that the pushed new view controller is presented "full screen" (for the lack of a better way of describing the behaviour). It seems to me like some kind of modal segue rather than a push one. When trying to recreate that in my own app I can't achieve that the whole navigation bar is included in the presentation segue. Only the view inside the presentation hierarchy is changed. I want the second view controller to be entirely white (the view as well as the navigation bar) but both view controllers should have the default swipe-to-go-back behaviour. How can that be done?
What they're probably doing is hiding the navigation bar.
You can achieve the same effect if you set navigationController?.navigationBar.isHidden = true (can also do it on navigation bar in UINavigationController from the storyboard), make a regular show segue and just display it using performSegue(withIdentifier: "nextScreen", sender: nil). You can then make your own UI logic for displaying back buttons etc.
This is a bit of a tricky one to explain here so I'm hoping the screenshot of the storyboard of the app I'm trying to build helps to clarify what I'm trying to do.
Basically the apps starts with a nav controller and table view, when you click on a cell in the table view you go to a tab bar controller with three tabs, each tab view has its own navigation controller and subsequently there is a navigation bar on each of them, so at this point there is a back button on all tab views which takes us back to the initial table view.
The first tab view simply has some text, the next has a table view with several table cells and the last has a map view with several markers. Both the table cell and the map markers link to a detail view via a navigation controller which shows more detailed information (both via named segues). It's at this point of clicking through to the detail view where the navigation is breaking, the detail page shows no navigation bar although it is there as the title text is set, but there is no back button and it seems that the navigation context / hierarchy has been broken here somehow. The appearance of the storyboard also reflects this as it shows no Back button on the navbar on the navigation controller or the Detail view.
Without initially getting into the code in any real way I am just trying to see if there is any significant reason why these type of structure / hierarchy is just now going to work. So, my main question is does this storyboard structure seem like the correct way to go about what I'm trying to do?
Here is the storyboard:
I have a TabBarApplication with four views in the main TabBarItem. The problem comes when I go to any of these views and click in any button to go to another view and when I go back by a button linked to the main view, the TabBarItem of the app disappear!!
For example, one view of the app is a tableView in which each element of the list is linked to his external view and it has a back button that should return to the tableView. All the segues are by modal, not push because push segue crash the application and by modal it runs correctly but the problem comes when I returned by clicking the back button of the NavigationItem in the header of the view to his main view and the TabBarItem of the app is not there, is empty.
Each tab should have the view controller set to a navigation controller, with the view controller you want set as the root view controller of the navigation controller. Now you can use push segues and the standard back button that will be added for you. This will bypass the issue (and work much better for you and users).
You current issue is likely related to not really ever going back. Instead, just always presenting new modal view controllers which replace any existing content on screen.
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
I am writing an iPhone application using the storyboards for an initial mockup. The problem I have right now is switching view controllers.
I have a table view controller and another view controller. All I want to do is use a back button to go back to the original screen, and I can do that, except the data disappears. The storyboard that I have is shown below.
I have the Back button going back to the original navigation controller. I have also had it going back to the Card view controller.
I have hard coded some example cells to just see how things look and they show up just fine when I run the simulation. When I click the back button though, it goes back to the All Cards screen and the cells that were there are now gone.
If I need to post some code just ask for what part would be helpful, I have done all of this through storyboards though.
I'm sure it's something stupid I've done, any point in the right direction would be greatly appreciated.
Basically: you pushed where you should have popped.
What you are seeing on the Storyboard does not exist yet. By segue-waying during runtime to a view controller it gets instantiated.
When you segue-wayed during runtime from the Add Card view controller "back" to the Card View Controller - here is what happened: instead of popping the navigation stack all the way back to the Card View Controller you already had, you just instantiated a new Card View Controller and pushed it onto the navigation stack. You could verify that by going all the way back to the original Card View Controller by tapping the back button several times.
What you could do to accomplish your task is this:
Instead of using the Storyboard for your back button use an IBAction in code:
- (IBAction)popToRoot:(id)sender {
[self.navigationController popToRootViewControllerAnimated:YES];
}