AnchorView | An example of an AnchorView that enables relative layouting | Router library

After some debugging I managed to find a workaround to this problem.

In short, it looks like the safe area is not updated after UIViewController.viewWillDisappear is called, and hence any changes to .additionalSafeAreaInsets is ignored (since these insets modifies the safe area of the view controller's view).

My current workaround is somewhat hacky, but it gets the job done. Since UIViewControllerTransitioningDelegate.animationController(forDismissed...) is called right before UIViewController.viewWillDisappear and UIViewControllerAnimatedTransitioning.animateTransition(using transitionContext...), I start the dismiss animation already in that method. That way the layout calculations for the animation get correct, and the correct safe area is set.

Below is the code for my custom UIViewControllerTransitioningDelegate with the workaround. Note: I've removed the use of .additionalSafeAreaInsets since its not necessary at all! And I've no idea why I thought I needed it in the first place...

I managed to figure it out after playing around for a good while. And I think I've had a feeling about what the the problem was all along...

Short answer: Do not try to animate views by changing their .frame or .bounds when using Auto Layout Constraints. Changing these properties might cause undefined behaviour (like the one I experienced). Instead, animate views by changing their constraints or the .center and/or .transform property. These properties do not conflict with the layout engine. When querying a view for its size, use the .bounds property, since this property is more reliable than .frame when using Auto Layout Constraints.

Slightly longer answer: Since I was using Auto Layout Constraints all over the place, combining it with manually changing the frames of views during animation did not work. Or more correct - had undefined behaviours. Since the Auto Layout Engine uses constraints to modify the view's frame for you, you should avoid touching the .frame (and .bounds) property yourself. Instead, animate your views by changing properties like .center and .transform. It seems like these properties do not conflict with Auto Layout, and changes to these properties will be applied to your views after the Auto Layout Engine has done its calculations. Event thought changing the .frame and .bounds of the view might work sometimes in combinations with Auto Layout Constraints, like I experienced with my custom presentation animation (which seemed to work flawlessly!), you should really avoid it. A workaround in some cases might be to temporary turn .translatesAutoresizingMaskIntoConstraints == true, but this is really not a god idea since it causes UIKit to generate Auto Layout Constraints for you, and those constraints might conflict with your own constraints. When querying a view for its size, use the .bounds property, since this property is more reliable than .frame when using Auto Layout Constraints and the .transform property.

Worthy mentions from the Apple documentation:

UIView.center:

Use this property, instead of the frame property, when you want to change the position of a view. The center point is always valid, even when scaling or rotation factors are applied to the view's transform. Changes to this property can be animated.

UIView.transform:

In iOS 8.0 and later, the transform property does not affect Auto Layout. Auto layout calculates a view’s alignment rectangle based on its untransformed frame.

Warning: When the value of this property is anything other than the identity transform, the value in the frame property is undefined and should be ignored.

UIView.translatesAutoresizingMaskIntoConstraints:

If this property’s value is true, the system creates a set of constraints that duplicate the behavior specified by the view’s autoresizing mask. This also lets you modify the view’s size and location using the view’s frame, bounds, or center properties, allowing you to create a static, frame-based layout within Auto Layout.

Note that the autoresizing mask constraints fully specify the view’s size and position; therefore, you cannot add additional constraints to modify this size or position without introducing conflicts. If you want to use Auto Layout to dynamically calculate the size and position of your view, you must set this property to false, and then provide a non ambiguous, nonconflicting set of constraints for the view.

By default, the property is set to true for any view you programmatically create. If you add views in Interface Builder, the system automatically sets this property to false.

For those interested, below is my final code for the custom UIViewControllerTransitioningDelegate. Only using Auto Layout Constraints, and only modifying the view properties mentioned above. Note: I'm using TinyConstraints to make writing constraints more pleasant.

I can't write simple comment sorry about that. Can you try to add in your Manifest file below which activity you try to do that android:windowSoftInputMode="adjustResize"

You can use setEpicenterBounds(Rect) and pass a Rect width the full width but a flat height at the bottom of the anchor.

Obviously the anchor view needs to be already laid out when calling setEpicenterBounds(Rect) because its size is needed, the best place for the call is probably right before show(), if you really can't do it there and the anchor view is not using fixed sizing, you might use a ViewTreeObserver.OnGlobalLayoutListener.

PopupWindow is a window. Your navigation drawer is located on another window with its own view hierarchy.

Its like this:

-- activity
---- window1
------ viewhierarchy
--------NavigationDrawer
---- window2
------ popup

What you want is not possible using PopupWindow.

One possible work-around is to hide & show the popup when navigation is opened and closed. Here's the callback:

https://developer.android.com/reference/android/support/v4/widget/DrawerLayout.DrawerListener.html#ondrawerstatechanged

Or you may add a view as popup by yourself and take care of the positioning and gravity.

Last but not least, check out these libraries as they may have what you want. They work with view so you may manage it the way you want.

https://github.com/sephiroth74/android-target-tooltip

https://github.com/tomergoldst/tooltips