I'm trying to make a custom view controller for use in my projects, that has possible 3 segues from it. But those are not mandatory.
When view controller loads i'm calling a method "trySegues()" that should try to perform all 3 of those segues. Segues are custom, so each successful call will be handled and registered in my code.
In Objective-C i would do that using "#try - #catch" so all the successful calls will go forward, while if one of those segues is not set, it'll raise an exception, but it will be handled by me manually so it won't break the execution of the program.
Is there a way to do the same in Swift?
Using Optionals to simulate an exception won't work, since the performSegueWithIdentifier function returns no value.
In no imaginable way is #try-#catch-ing a performSegueWithIdentifier: the appropriate approach to this challenge. Not in Objective-C. Not in Swift.
Segues can't (or shouldn't) exist independently of storyboards. After all, if you were try to instantiate a segue, the class name is UIStoryboardSegue. The fact that this class even exists publicly is not so that you can instantiate it and add it at run time. It exists so that you can subclass the segue, choose your subclass on the storyboard, and set up a segue with custom behavior:
In Objective-C and Swift, exceptions are reserved for truly exceptional behavior. Behavior which can be prevented at development time. We should not be relying on #try-#catch blocks during run-time by the time we've released our app. We should have fixed our app so that there's nothing to #catch.
So with this said, the only way that performSegueWithIdentifier: can throw an exception is if the segue identifier we gave it does not exist. The only reason the segue shouldn't exist is because we made a typo somewhere.
The segues are hooked up and defined at compile time. There is no public mechanism for checking whether or not a particular segue exists because we just shouldn't be doing this at all.
Now, with all that said, if we want to dynamically push or modally present a particular view controller at run time, and we can't know at compile time what view controller it will be (or from what view controller we're getting to it from), then we shouldn't be presenting it via a segue.
Instead, we should be using one of the presentation options the UIViewController class defines.
Your options are:
presentViewController(_:animated:completion:)
showViewController(_:sender:)
showDetailViewController(_:sender:)
And in place of an unwind segue, you'd want something like this:
dismissViewControllerAnimated(_:completion:)
Related
I still don't have an answer after viewing many answers to a similar question eg. https://stackoverflow.com/questions/12509422/how-to-perform-unwind-segue-programmatically
I would like to try to restate what "programmatically" means to the question I'm posing.
All the solutions show using a storyboard and connecting the view controllers "exit" with an unwind method defined in some view controller. This works but isn't programmatically, but rather directly connecting through use by the Xcode tool. Sure the prepare method is programmatically involved in the final steps.
My challenge is that I'm using Cocoapods as a reusable library, and the storyboard has no way to know about users of this library. So they cannot connect to an unwind method, as there isn't one yet.
I want to use the language generic capabilities to specify the unwind method, programmatically (Swift or Objective-C).
The unwind method might also be in another bundle, further complicating things.
Note: Creating a placeholder unwind would be ok, assuming the value of the view controller name can be changed programmatically through the UIStoryboardSegue object (which has an unwindAction).
Thanks for any insight.
UPDATE ANSWER (it won't let me answer)
First, my answer involves clarifying the original question, in particular the "without storboard" statement. This was meant to "unwind" to a ViewController that wasn't specified via the storyboard, in particular a new user of this library. My answer shows I can do this, but a storyboard is still required (just not for this new ViewController).
My question did state that a placeholder unwind could be created via a storyboard.
Note: Creating a placeholder unwind would be ok, assuming the value of the view controller name can be changed programmatically through the UIStoryboardSegue object (which has an unwindAction).
So my answer can call code that wasn't specified via the Xcode user interface (which is the UI process of connecting to a named unwind though dragging to the 'exit').
I was under the (wrong) assumption this was connecting to my unwind method (eg. unwindFromHelp), much like connecting a button to an IBAction in code. Instead it connects dynamically to anything matching that name in the runtime hierarchy.
The key insight to the answer is from What are Unwind segues for and how do you use them? where #shawkinaw states:
In other words, think of the unwind action as describing where the segue is coming from, rather than where it is going to.
This also means there can be many implementations of the same unwind method name! At runtime, the ViewController hierarchy keeps track of the unwind methods it's encountered along the way, and calling the Segue Unwind will unwind to the first one it finds.
Based on that new understanding, my quest to call an unwind method in some future ViewController is possible by creating a placeholder unwind that is manually added through the Xcode exit approach. That operation shows all the unwind methods available at that time.
So the solution involves using the storyboard, and a (potentially) unused ViewController, where an unwind method is defined. Then the exit of the desired ViewController connects through Xcode to that unwind.
A future user can also define this same unwind method in new code (eg. unwindFromHelp) and if the ViewHierarchy runtime stack is such that no other unwind is matched, their code is executed. Thus this delegation approach achieves my original question, where the future user must provide an implementation for the delegation (which here is an unwind method name, eg. unwindFromHelp).
I wrote a sample that shows how this can be accomplished and the unwind returns to different ViewControllers based on how it got there: github UnwindExample
An example flow diagram is based on the
A or B calling Help idea.
This is a design pattern question.
I have a 'framework' I'm building, and depending on the current displayed ViewController the framework needs to inject a UIButton into that ViewControllers view.
I don't want the ViewControllers to 'know' explicitly about the 'framework', so I was initially using the delegate pattern but that required a 'over-seer' to ensure that when only specific view controllers were loaded, that they knew about the 'framework'.
However, it occurred to me if I could, via a protocol, ensure that all delete ViewControllers fired off the same two custom NSNotifications i.e. subscribeToRequestButton and unsubscribeForButton, then the 'framework' would listen out for those, and upon receiving them, have the view controller object passed to it (via the Notification) so that it can inject the button.
Thereby preventing the view controller from knowing about or having a reference to the 'framework'; it just knows, if it want's that button, to fire those two notifications, and ensure that it implements a method for when that button is touched.
Is this possible or is there a better approach?
The key problems are that
a) I cannot have the View Controllers that need the button know about the framework; as they never have the opportunity to have a reference to is passed to them by some manager class, and
b) The framework doesn't know about the view controllers existence until it receives a notification that is needs to inject a button into something.
EDIT:
I'll just use a singleton pattern with a few public accessor methods for passing data in or querying.
In my storyboard I have a TextInputViewController (subclass of UIViewController). I have multiples push segues leading to TextInputViewController with different identifiers from various view controllers. However every time one of these segues are called they seem to go to the same instance of TextInputViewController which causes a very strange behaviour.
Is there a way to make each segue create a different instance of TextInputViewController?
Segues always create a new instance of the destinationViewController (with the exception of the unwind segue which simply returns to a previously created viewController).
The behavior you are seeing must be caused by some other state external to the viewController since it is a new instance.
You can read more about using Segues here.
This is a kinda conceptual question (not trying to solve a particular problem but to understand things better) that I encountered.
IBOutlets in view controllers are "forcedly unwrapped" variables by default and I don't know exactly why but it tells me that iOS expects each one of them to be initialized when the VC is called.
I have a view controller A and two other ones B and C. I have a click listener to a custom button of mine in A that depending a certain variable, decides after the click if B or C are going to be called.
I tried implementing this with presentViewController but for some reason my program crashed in runtime because of non-initialized outlets in either B or C.
However, I named by segues and tried the same thing with performSegueWithIdentifier and it just worked.
I wanna know, what are all the differences between them and is everything I told I know correct?
Thanks in advance
I am trying to create a class that is similar in functionality to the UITabBarController, but with some fundamentally different functionality. It is called a dropdownViewController and has a primary content view with a UITabBar-like interface at the top of the screen that allows for other UIViewControllers to be modally presented and dismissed over this primary viewController.
I would like this class to be able to be set up using the storyboard to some extent, and I have created a custom Segue that connects my dropDownViewController class with each of its child viewControllers.
My current solution is to assign identifiers to each of the Segues that are then stored in array within the dropdownViewController. I can call the segues programmatically using the performSegueWithIdentifer: method, but this solution isn't as flexible or intuitive as I would like to to be.
Right now, all the custom Segues that I have setup are connected to the "manual" triggered segue in the storyboard connections panel for the dropdownViewController. (I would put screenshots but this is my first post)
However, I want to mimic the functionality of the UITabBarController class, which has an alternate triggered segue in the storyboard connections panel called viewControllers that each of its child views are assigned to. Unless there are some compile-time macros handling these story board interactions, I assume that the UITabBarController uses these connections to determine what it's view controllers are. However, I can't figure out how to setup this functionality with my own class
After searching around for a solution, it seems likely that this is functionality Apple kept for its own use and is limited to their own classes as a feature in Xcode, but if anyone has solutions or ideas it would be greatly appreciated.
I haven't tried this, but I think you should be able to do it with your own custom segues. In the perform method, you would just add the destination view controller to the source view controller's (DropDownViewController) array of view controllers. In the DropDownViewController's viewDidLoad method (or maybe in an initializer or awakeFromNib, not sure which is most appropriate), you would execute all these segues so that they run right after the controller is loaded like is done for a tab bar controller.