Trying to follow some best practices so looking for suggestions.
Have 2 types of users: user, admin
And want to present a different “version” of a particular view controller to certain user types. This particular view controller is nested into a tab bar controller, and the other view controllers in the tab bar controller will be the same for each user.
Possibly overthinking this, and thought about going the the route of hiding storyboard elements based on user type, but there must be a better way to accomplish presenting different versions of a view controller nested in a tab bar controller.
You can simply create two different ViewControllers and segue to the correct one based on the user type.
If you start at InitialViewController, then create two different segues that go to AdminViewController and UserViewController. Afterwards, perform the type-checking in InitialViewController and segue accordingly to the correct one.
There are a lot of other ways to overcome your problem. If you need any further clarification or a different way of doing so, do not hesitate commenting!
Related
i have one question about using multiple segues to one ViewController. Ill try to create an article management, so you can add/edit/delete articles.
When you add a new article you can choose between a maincategory and a subcategory, choose the article and then edit some inital values.
but if ill try to edit one of my selected articles, i would like to jump to the "latest" ViewController in navigation stack.
I thought i could easily create another segue to my last viewController, but ill always get an error when i try to load this segue (i guess this could be a problem with the existing NavigationController).
I could provide some code, but i dont know if this is a possible solution to solve such things - or is there a better way?
Thanks in advance.
You can, but the new segue should take you to a navigation controller that just contains the last view controller (as the root). In this way you are duplicating the normal situation but with only 1 view controller.
If you wanted to allow the last view controller to have a 'back' button which took you to some 'earlier' screens (if that makes any kind of sense in your app) then you would need to write some code. It's more likely that other screens should be accessed via bar button items or similar (which would also likely be done in code).
So suppose you need some functionality that requires next storyboard. For example you need to upload different content to view depending on what tab is clicked.
But the problem comes out when you try to use this storyboard. When you switch tabs you getting this behaviour.
But in first tab everything fine. So looks like it doesn't load view second time. Can somebody explain or give a link to the behaviour of navigation controller in this case, because I can't find anything useful in reference. Or how should I correct this behaviour in IB or programatically? Thanks.
a simple work-around is to put a "fake-viewcontroller" as root for the second navigation. On this "fake" controller execute in viewDidLoad a [self performSegueWithIdentifier: #"goToTheControllerHereWeGo" sender: self];
So, as I mentioned in my comment I do think this is a bug but we'll see how Apple responds. But yeah, segues have no love for view controllers that are the root view controllers of multiple navigation controllers. There are a number of workarounds depending on the context under which it comes up.
Best workaround : Share the navigation controllers, not their root view controllers
So for the simple example given above you could do this and everything would be fine:
Other workaround : This one is more applicable to complex storyboards that may have different custom navigation controllers so that sharing the nav controller isn't possible. One hilarious aspect of this issue is that when a view controller has two parent nav controllers in the storyboard, you won't know until runtime which one gets it! And further, on different runs they can switch :P (another reason I think this is a bug).
Sooooo from within prepareForSegue you can check if your navigation controller got unpacked with a rootViewController and, if it didn't, force it in there yourself:
UINavigationController* nc = segue.destinationViewController ;
if (nc.viewControllers.count == 0) {
nc.viewControllers = #[[self.storyboard instantiateViewControllerWithIdentifier:#"MyDetailVC"]];
}
Just provide more explanation beside the comments 'You cannot make a UIViewController as the root view controller of two different Navigation controller'. Suppose you can do so, then the view of the controller will be child view of the two navigation controller's view. It cannot happen as "it" cannot be a child of A but simultaneously a child of B.
On what condition will the tabview items switch , also trigger one of the two separate view controllers? what is the logic? when is it implemented? and no matter whatever the logic maybe, why does a single view controller (let us assume it is being filled up with different data according to the root) has 2 separate roots? we cannot add anything separately from the navigation controller itself,
Navigation controller is the flow that sets the storyboard in motion, but putting a VC as a subview of two different NC just has no point.
Think it of like this,
No additional information is provided by the Navigation controller itself, it just sets things in motion. So why would you want to put a VC as the child of 2root NC.
More easily think it as multiple inheritance, in objc, java its not possible because of the
Diamond problem. look it up and i hope it helps u understand
What I need to do is basically build a container(view controller) that can change its child view controller dynamically and also set it's initial view controller dynamically.
I never used the Embed segue before so I thought I'll give it a shot.
However, using it seems to allow me to change the child view controller dynamically using a custom segue between the children view controllers but the initial view controllers seem to be fixed to the one I dragged the segue to in the StoryBoard(The custom segue here would be something alone these lines).
I know I can achieve what i'm looking for by creating x custom segue (where x is the number of children VCs I need) from the container view controller directly to the children and just calling these segues in code based on my needs.
But if that's the only way, what's the reason for using the "Embed" segue, is it only for really simple scenario's ?
An embed segue is not just for really simple scenarii. It can get pretty complicated. A major purpose is to cleanly separate code related to different concerns, that may still coexist on the same screen, into different view controllers. For instance, you could have an authentication controller and a preferences controller, both embedded into a single profile controller.
I'm very new to iOS but have been put on a complex app. All the tutorials I have seen on storyboards, segues, views, etc. are very simple.
I have been able to use a segue to show a view and go back, but management doesn't care about segues. After moving through a complex app the user is supposed to be able to just jump way over to another part of the app, as if the user had gone back twice then selected another view, and then selected another view.
I'm just lost as to how to make this happen. Add a new direct segue in the storyboard editor? Or something to do with a custom segue created programatically? I need some hints on direction, like what methods to look at, what to google or a advanced tutorial and such. Thanks in advance.
Usually, the Navigation Controller allows single 'pop's of view controllers in the stack. This works great for master-detail apps and linear workflows.
When one view controller is connected to another in a web-like fashion, things get difficult to manage.
If you want to rely on the automatted management of a view controller stack but go back more than one item at once, have a look at unwind segues: What are Unwind segues for and how do you use them? -- the answer is illustrated really well.
If you can navigate in circles, it gets more intricate. Essentially, your navigation controller would put new objects of already intantiated classes onto the stack to maintain its breadcrumb trail all the way back to the root view controller.
In some cases, this is not desirable. You could use a UINavigationControllerDelegate which removes items from the stack when certain conditions are met.
Let's say you have 4 view controllers, A--D. The possible connections are: A - B - C - {B,D} - A. From D, when you're finished, you want to unwind to A. From C, you may want to add an additional item at B, but you don't want to keep track of all the B-C-B-C-B-C-... connections. In these cases, altering the navigation controller history is useful and won't break the expected behavior of the "back" button.
I have a View Controller and need to segue into another View Controller (which is customized based on what scenario I want to show). Trying to decide what is the best approach here in regards to simplicity vs efficiency
Three options I can think of:
(a) Have my View Controller segue into a View Controller that holds a View Container linked to multiple View Controllers
(b) Have my View Controller segue into a View Controller with multiple views that can be hidden and rearranged
(c) Have my View Controller segue into different View Controllers depending upon the criteria
I'm still uncertain how much each View Controller should differ from each other, but given that one View Controller might segue into another View Controller that's irrelevant for the other two scenarios, what are your guys' thoughts on the three approaches in terms of code complexity, ease of use, general efficiency in terms of speed/memory management. It's possible that the View Controllers that are being segued into might differ by just a little, but also by a lot!
I think all depends on difference between viewControllers for each scenario. BUT what I can certainly say is do not use varriant (B), because even if difference seems tiny now, as only it begins growing, your code that compose views will becomes more complicated and unreadable, at least in my case it usually happens. So, if you must show different viewControllers with same or pretty similar use (e.g. save for, show list, select item from list. go next, go previouse), try to use one viewController and load different views that are already composed. And if usage of those controllers different - use multiple controllers.