I am trying to check which view presented the current view as there are many views that could have brought me there.
Is there code that i can use to determine if it was a specific view? If it was the sepecific view that i want, i need to do something on viewDidLoad.
This is not something you should do. A view shouldn't care which view presented it. That is fragile and it doesn't scale well.
A proper approach would be for your view to have one or more properties that can be set by whatever will present the new view. Then the view can display itself accordingly.
I assume when you say "view" you really mean UIViewController. You will find that UIViewController has a presentingViewController property you can access to find the view controller that presented it. (If this is not the scenario you're working with, you need to provide more specific information.)
A better pattern may be to instead pass a boolean or enum to your view controller's init method that controls the behavior.
Related
I have a viewcontroller with default view associated with it.
If I want to discard the view only not viewcontroller, is it ok to set self.view = nil? So that view gets discarded and new view gets allocated with new values.
I want to fill the view with new UI, based on a condition I did that in viewdidLoad. So If I set self.view = nil, and try to access the view from anywhere, it will again create the view. So the new properties will be set.
Is it a right approach to do it. Or I have to write a separate method to refresh view with new properties.
Please provide me the correct approach to do it.
I don't think there is a correct approach, but here is some advice.
Don't interrupt the view lifecycle (make sure -viewWillAppear:, -viewDidAppear:, -viewWillDisappear:, -viewDidDisappear: all get called).
Consider multiple view controllers contained within a custom container view controller instead of swapping views. It will keep each view controller focused on a specific task.
Consider having an empty self.view and use -addSubview:/-removeFromSuperview to swap the content. That way you will not need to reset self.view.
Don't remove the default view which comes with the uiviewcontroller. If you want to show the custom uiview based on conditions then I would suggest, create your custom uiview and then initialize it and add it on your default view for respective conditions.
This might be a stupid question, but I'll shoot.
I made a little test project to test out a concept I had for a sliding view controller type of thing. I naively assumed I could create a UIView (let's call it peekView) with an outlet in a controller, and call something like [slidingControllerSlideFrom:self.view] from any visible view controller, the implementation of such being:
- (void)slidingControllerSlideFrom(UIView*)controllersMainView
{
// push side controller to top of navigation stack
self.peekView = controllersMainView;
// sliding animation
}
But there is no effect. No crash, no warning, no change of view in the pushed controller.
Of course, the pushed controller crashes when trying to add self's view as a subview, but assigning it to a predefined UIView just results in nothing.
So, why? And if a mere 'why' is not enough of a question- what happens when I try to assign one controller's view another controller's subview, and what was the reason for designing UIKit where you cannot set views from self.view?
To do that you have two options:
1 - If the controller in the peekView is always the same one in a given scene, use a "Container View". Those are explained here. Basically, they allow you to add a view in your scene that is managed by another controller.
2 - If the controller in the peekView depends on different conditions, you will have to create something similar to a custom tabbarcontroller. That means that you instantiate the controller that you need, add it's view as a subview of peekView (not assign the controller's view to the peekView itself) and then use didmovetoparentviewcontroller to notify the child controller. This question might help.
UPDATE:
Just saw your comment, so let me answer what you actually asked: The peekview property is actually just a reference to the real UIView you placed in the screen. When you do this:
self.peekView = controllersMainView;
You are changing the reference, but no the view object itself. That's why you are not seeing any changes. There are ways of adding a new view to the controller from code, but it is much simpler to simply use addSubview to add your controllers view to a UIView that is already in the controller.
Check out the discussion here: subView Slide up from bottom of the screen
and here: SubView slide in animation, iphone
Hopefully that gives you a bit of framework on how to approach this task!
This is probably a very simple question but I can't find the answer to it.
I am working on a new project that uses Storyboards for the first time.
I have a number of view controllers that connect the way I want them to.
Each view controller has an info button.
I have one view controller (AboutViewController) that I want to use to display the info for all the view controllers. I am currently calling this via a popover segue from each screen. So I have one destination view controller (AVC) that I am calling from a number of VCs- VC1toAVC, VC2toAVC, VC3toAVC etc. I want two textfields in AVC to change, depending on which VC called it.
So here's the problem- how can I tell which view controller called the popup? It's basically the view that's below the popover. Currently I'm storing it as a variable but that's not ideal. I'm guessing it has something to do with the segue identifiers?
Any and all help much appreciated!
One approach to this is adding a property to your pop up view controller and then define the
prepareForSegue:sender:
method so you set your destination view controller's property to the sender of the segue.
I am having a hard time wording this when searching the internet so I am just going to ask the question.
I have an options view in my app that slides into view when the user clicks a button. This options view will display app information like settings. I want this options view to be displayed on every view controller in my app. I do not want to copy and paste the code for the options view into every viewcontroller file. The options view has quite a few outlets and actions and also calls many delegates.
How can I reuse this options view in all my view controllers without adding all the outlets, actions, and delegate methods each time?
I was going to make a new file with public methods, but I would still have to copy the outlets. Would this public methods file have to include delegate methods as well then?
Let me know if my question does not make sense. I am hoping there is a standard way of implementing something like this.
You can just have the options view be the view of an options view controller, and show it modally from any view controller you want. Is there some reason you're not doing it this way? This is the usual way to do this, not by having a view that you reuse in different controllers.
Add the options as a subview of the window, then make your App Delegate handle all of the options view's outlets
When using custom container view controller, I don't quite understand why the presenting view controller needs to specify the from, because being the container class, it should already know what's in the view hierarchy, no?
transitionFromViewController:toViewController:duration:options:animations:completion:
Container view controllers sometimes need to put the views of the contained controllers into specific subviews of their own view. (For example, a SplitViewController reimplementation might have left and right positioning views holding the master and detail controller views respectively.) Providing the fromViewController tells UIViewController where in the view hierarchy the new controller's view should be inserted, and also which specific view should be removed after the animation.
(contrary to another answer, the frames of the views aren't set for you at all. You do that, before the call, and in the animation block. The "Creating Custom Container View Controllers" system guide in the docs has a pretty good example.)
As it happens, actually using transitionFromViewController:... appears to be optional. You can manage your view hierarchy manually, with or without animations, and it works fine. I'm still forming my opinions, but I think I prefer to do it manually, to more easily handle cases where one of the VCs is nil.
This is done this way to allow you to have a view controller that has views with viewControllers in it. The from defines the originating view controller and gives the system the ability to position the animations appropriately.
Imaging you had a view with 4 views in it like tiles. the main view controller can consecutively call this on its "child" view controllers and with the from -> to specification, it won't make the assumption that the caller is the from viewController.