I am displaying a modal UIViewController on top of another. If the requisite UIPanGestureRecognizer triggers, I have an interactive UIPercentDrivenInteractiveTransition which basically pulls the modal view down to eventually dismiss it.
I notice that the view controller beneath does not receive any of the usual appearance methods when typically presenting and dismissing view controllers:
-viewWillAppear:,-viewWillDisappear, etc.
Is there any way, considering that this is an Apple-provided view controller API, to have these methods still be called at the appropriate times during the interaction?
Make sure you're calling transitionContext.completeTransition within your custom transition class which handles all the animations and gestures.
It may depend on the type of UIModalPresentationStyle you're using. Some styles don't trigger the appearance methods.
see here for example.
Related
Scenario
NavigationController is a root controller of a TabBarController
TabBarController has 2 UIViewControllers
One UIViewController has a function that presents another UIViewController
UIVIewController that is presented has a StackView
Instantiates a subclass of FormController (eg: FormVC) and adds to Stack as subview
Problem
The keyboardWillShow function of FormVC does not get called. The keyboard actually adds the input to the row, but the auto scrolling does not happen
Is this only a problem in Eureka or perhaps a problem using the Navigation controller's pushViewController?
Answer
The correct way to use the FormVC is with the Container, as per the comment in the question.
Here is a great explanation credit to Miguel Revetria - source, github:
Hi chefren the problem with your approach is that the
FormViewController lifecycle is not being handled because you are not
adding it to the view controllers hierarchy. Actually you are only
adding its view to one of your views.
The function keyboardWillShow is not being called due to the
FormViewController adds this observer to the notification
Notification.Name.UIKeyboardWillShow from the function viewWillAppear,
which in your case is not being called. As this, other stuff may not
work properly, because the view controller lifecycle is not being
handled.
That is not the way the FormViewController should be used. Using it in
that way may end up with an undesired behavior like you experienced.
The correct way to embed a FormViewController in other view
controller's view is by adding it as a Child View Controller. See this
Apple guide for further information Implementing a Container View
Controller. Additionally, in storyboards you can use a Container
View.
Regards
I haven't really seen any resource that gives a good and simple explanations on relationship among window, rootviewcontroller, childviewcontroller, navigationcontroller and how they piece together in iOS development. Anyone one knows how to put this in a easy-to-understand way or any online resource or book that does a good job in explaining it?
Per the documentation on UIWindow:
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIWindow_Class/
A UIWindow object provides the backdrop for your app’s user interface and provides important event-handling behaviors. Windows do not have any visual appearance of their own, but they are crucial to the presentation of your app’s views.
Xcode typically provides your application's main window, but you can add more if you need to.
From the documentation link you can see that UIWindow is actually a UIView
Enter your first view controller. Like providing a main window, when you start a new Project in Xcode the project template usually wires up your initial view controller, which as the name implies controls a view (UIView).
You could call this initial view controller your RootViewController but if you get a handle on the UIWindow you could just as easily swap out the current initial view controller's view for any other view controller view you like.
That probably doesn't help with hard and fast rules for things, but if I understand what you are asking, RootViewController is likely the initial view controller for you application. For example, if you are using Storyboards, Xcode typically makes Main.storyboard, you will see a gray arrow pointing to the UIViewController representation.
This is pointing to the Storyboards Initial View Controller. You can verify this from the Attributes Inspector. Select the view controller then select the attribute inspector:
So that's basically RootViewController. ChildViewController is just any other view controller that is a child of a view controller.
I assume what you are referring to is:
addChildViewController:
removeFromParentViewController
willMoveToParentViewController:
didMoveToParentViewController:
You can read more about these methods here:
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIViewController_Class/
Under Implementing a Container View Controller
The quick gist of it is, A View Controller controls a view. View's can have subviews. Those subviews can come from other View Controllers. The methods outlined above pretty much just enable things like viewWillAppear, or viewWillDiappear to be called on the child view controller automatically when those methods are invoked on the parent view controller.
Per the docs:
By default, rotation and appearance callbacks are automatically forwarded to children. You may optionally override the shouldAutomaticallyForwardRotationMethods and shouldAutomaticallyForwardAppearanceMethods methods to take control of this behavior yourself.
a NavigationController is just like any other View Controller. It contains some special behavior for transitioning between views, but like other View Controllers it has a View (UIView) that it manages. A navigation controller could be your Initial View Controller / RootViewController just as any other View Controller can be, it all just depends on what you are trying to do. For example, a simple app that is just a list view, where you can tap an item and get a detail view could be constructed as:
1) Initial View Controller -> NavigationController
2) The NavigationController's first ViewController (Apple calls this a RootViewController) would then be a TableViewController.
3) Selecting a TableCell in the TableView (TableViewController manages a TableView) would then transition you to your Detail View Controller. The Navigation Controller knows how to do all that Sliding back and forth drama.
That's a pretty simplistic overview you can search the internet/youtube for more full featured tutorials outlining the same thing in more detail.
Example: https://www.raywenderlich.com/113388/storyboards-tutorial-in-ios-9-part-1
It's worth your time to do a few of these to get your bearings. Yes, it will likely cost you a few hours of your day. Take heart, everyone who ever started doing iOS development had to go though the same thing. =)
I am attempting to create a custom view controller container, which will display a drawer at the bottom of the screen, like the Apple mail or music apps, and I want the user to either be able to tap on it to transition it to fullscreen, or slide it up interactively to reveal the content.
I have the drawer working, using a UIPanGestureRecognizer to slide it.
I can implement this by adding the content controller as a child controller, the content view to the hierarchy and call viewWillAppear: and viewDidAppear: when appropriate.
But I wish to allow the content view controller to animate alongside the swipe (e.g. any animations in viewWillAppear:, like with interactive pop), thus I am looking at custom modal presentation and UIPercentDrivenInteractiveTransition, but I am hitting a wall, and I can't see why this is happening. I have setup a transitioning delegate, returning a custom animation controllers and an interaction controller which is a UIPercentDrivenInteractiveTransition object.
My drawer is part of the container controller's view hierarchy, and naturally I want the content controller's view to be a subview of the drawer. But when calling presentViewController:animated:completion:, a new UITransitionViewsubview is added to the UIWindow, supposedly for where the transition animation should occur. But this kills my UIPanGestureRecognizer and the user cannot perform the swipe to open the drawer.
I tried creating a custom UIPresentationController and other ways to control where in the hierarchy this containerView should be, but I am unable to change the behavior.
Is what I am attempting to do the correct way? What have I missed?
If anyone is interested, here is my framework: LNPopupController
Update 2015.11.19
A demo project as well
Obj-C -> https://github.com/saiday/DraggableViewControllerDemo
Swift 2.x -> https://github.com/ostatnicky/DraggableViewController
Swift 4.x -> https://github.com/satishVekariya/DraggableViewController
Thanks #avdyushin mentioned my blog post.
And yes, my post Draggable view controller? Interactive view controller! is a tutorial just about your topic.
Quoted from my blog post:
How to do it
Design philosophy
There is no two UIViewController in together, instead there's only one UIViewController at a time. When user begin drag on certain subview, present another view controller with custom UIViewControllerAnimatedTransitioning by custom UIPercentDrivenInteractiveTransition protocol.
Technical things
These two protocols is the foundation of customize interactive UIViewController transitions. In case you don't know yet, take a glance before starting.
1. UIViewControllerAnimatedTransitioning protocol
2. UIPercentDrivenInteractiveTransition protocol
An updated answer for iOS 10: this is now trivial using UIViewPropertyAnimator.
UIViewPropertyAnimator is a continuation of the block-based animation concept, taken to its logical continuation - an object oriented wrapper around animations. This allows for much more control, such as controlling the completion of the animation using fractionComplete - precisely what was needed here.
Is it possible to subclass UICollectionViewTransitionLayout to change the automatic (e.g. non-interactive) animation when pushing/popping a view controller onto/off a UINavigationController stack?
Apples documentation and some articles in the internet suggest it should be possible:
If you want to provide more than just a linear transition from the old to new layout over time, you need to subclass and provide the layout attributes for items yourself
…but I didn’t find a way yet.
I would like to use UICollectionViewController’s useLayoutToLayoutNavigationTransitions to push one collection view controller on top of another (using the same data source). The two view controllers use different subclasses of UICollectionViewLayout which I want to transition using custom UICollectionViewLayoutAttributes that need to be keyframed and modified by the transitionProgress.
I was hoping, just implementing collectionView:transitionLayoutForOldLayout:newLayout: would do the trick, but that method only is called when transitioning interactively.
The best way I could come up with for the pushing is to call startInteractiveTransitionToCollectionViewLayout:completion: on the UICollectionView and pushing the new view controller without animation in the completion handler. For popping the view controller I would hook into -viewWillDisappear: of the view controller and check for the current view controller in the stack; if it is not there, I could again perform startInteractiveTransitionToCollectionViewLayout:completion:
Somehow I guess there is a better way…
I am trying to learn programming for the iPhone and I keep seeing these files and I am not sure when is each file and content of those files referred to in the execution of a program built for the iPhone. I am trying to follow tutorials and tips available online but nowhere is there a point by point comparison or something like that. It would be great if any of you could list a few basic differences like when is each file referred and what should ideally go into each file and so on. Thanks for your time already.
In general, delegates can be thought of as event handlers. Accordingly, the AppDelegate is the main event handler for your entire application. It is told when the application has launched, when it will exit, when a Push notification comes in, when the app has gone into the background, etc. One of those events - applicationDidFinishLaunching - is typically responsible for creating the application's window and adding views to that window.
In most applications, the view that is added to the window is actually controlled by a UIViewController. Each UIViewController is responsible for managing the appearance of one main view plus all of its subviews. For example, a UITableViewController is responsible for managing a UITableView (main view) and all of the UITableViewCells (subview) that are inserted into that UITableView. The UIViewController typically acts as a delegate (event handler) to the views it is responsible for. When a user taps a table view cell, a method in the UITableViewController is called. When the user swipes to delete a separate method is called.
A generic UIViewController provides the same basic functionality, but for custom views. For example, the UIViewController may be responsible for displaying a few text views and a button. The UIViewController would create its main view, the text views and the button view. The text views and button view would be added to the view controller's main view as subviews. The UIViewController would register itself as the delegate for events from the text view (for example learning when the user has finished editing the text in the text view). It would also register a method to handle a button press originating from the button it owned. When any of these registered events occur, methods on the UIViewController are called allowing you to take whatever action is needed.
The rootViewController is a specific type of view controller used with navigation controllers. If you want an application that has the typical iOS navigation view hierarchy, your AppDelegate would typically add a UINavigationController to the app's window. That UINavigationController is useless without actually having content to display. That is where the rootViewController comes into play. You are responsible for providing a view controller (such as the one described above) to act as the first view stored in the UINavigationController's stack of views. This view will be displayed when the app starts up and anytime that the user pops subsequent ViewControllers off of the UINavigationController's stack.
Long winded I realize - but hope it helps.