This question already has answers here:
Presenting modal in iOS 13 fullscreen
(27 answers)
Closed 3 years ago.
I'm using Xcode 11 since a few days. From the startup screen you can press a button to go to the next screen via a show-segue. In this second screen you can swipe down. This results in returning to the startup screen. However I expected that this behavior is only possible for modal screens, using the Present Modally segue.
I tried the different segue kinds (Show, Show Detail, Present Modally, Present as Popover), but they all result in that the second screen can be swiped down.
I tried to use isModalInPresentation = true, but this the user can still pull down the window (however it does not get dismissed).
I expect that the second screen is as the startup screen which cannot be dismissed by pulling it down, nor give the feeling it is a modal dialog (which it isn't to begin with).
Show segue with navigation controller
isModalInPresentation = true has to work if you specify it in the second view controller which you have presented.
For example: if you are presenting HomeViewController, make sure in the viewDidLoad() of HomeViewController, you have a line of code that says isModalInPresentation = true.
If you still wish to stop the little bouncing down behavior of the second view controller, unfortunately you have to create your own custom presentation style similar to that to achieve what you want. It's not yet possible from the Apple docs at the moment.
Related
This question already has answers here:
Detecting sheet was dismissed on iOS 13
(13 answers)
Closed 3 years ago.
Apple introduced card style presentation with iOS13 i.e (https://medium.com/#hacknicity/view-controller-presentation-changes-in-ios-13-ac8c901ebc4e). With this change all pagesheets and formsheets will show up as card with a feature to dismiss as swipe that apple gives us. Now we have two ways to dismiss the app.
Dismiss with swipe
Dismiss by clicking close/cancel button on presented controller
The things affected by this change. Since view is no longer removed from hierarchy, life cycle methods like (viewWillAppear, viewDidAppear, viewWillDisappear, viewDidDisappear) won't be invoked on the presentedViewController.
I have several modals in my app. Is there a better way to handle this situation where my life cycle methods get invoked instead of writing delegates throughout the app and calling them only for iOS13 as earlier versions they will get invoked.
Also tried setting isInModalPresentation = true which will stop the dismissing functionality. But, Dismiss by clicking close/cancel button on presented controller will still not call life cycle methods in the presenting view controller.
I don't want them to force them to fullscreen as well.
The uiadaptivepresentationcontrollerdelegate methods are called only if user dismisses via swipe. So need a better way to handle the delegates instead of changing code throughout the app.
Use secondViewController.modalPresentationStyle = .fullScreen before presenting the secondViewController controller.
I have been charged with updating an existing TVOS project. I have run into a bit of a snag.
If I am on the root controller(ie: the controller that presents on app launch.)
Pressing the Menu button takes me to an empty gray/white screen. A second press of menu returns me to the Dashboard.
I have tried to use the hierarchy viewer to see what exactly that gray/white screen is, but it has not helped. The gray/white screen consists of a UIWindow with a UILayoutContainerView, that contains a single UINavigationTransitionView in it. I can find no other identifiable characteristics about it to help me identify what exactly is going on.
When launched the app loads a UINavigationController that presents a UIViewController. Neither the Nav controller nor the presented ViewController override pressesBegin, pressesEnd or assign any gestureRecongnizers to intercept or otherwise override the Menu button functionality.
Near as I can tell the app should exhibit the default Menu button pressed behavior of navigate back to the root, then exit to the Dashboard once at the root. That said, the Menu button does navigate backwards as it should. It just does not terminate the app once at the root. When it does go to the gray/white screen none of the functions: applicationWill... are executed until after the second press of the Menu button on the remote. The app will also resume to this gray/white screen instead.
My question is thus, what is going on here. Baring that how can I
debug this behavior more effectively.
I have tried to be thorough with this explanation. I recognize that without code things get hard. Thing is, I have no idea what code would be relevant so any guidance or requests for specific code that may be useful will be posted.
Thanks.
Let's call your navigation controller A and the presented view controller B.
It sounds like what's happening is that A doesn't actually have any children, or it has a blank view controller as it's only child. I'm assuming that you never call pushViewController(_, animated:) on A? What are you passing to A when you create it with init(rootViewController:)?
When you press the Menu button the first time, UIKit is automatically dismissing the presented view controller B, and revealing the empty navigation controller A. The gray screen you see is actually the tvOS wallpaper, which is rendered outside the app's view hierarchy.
Then pressing the Menu button the second time actually causes the app to resign, since the navigation controller A doesn't have any more children to pop.
So it sounds like you should either:
Add the view controller B as a child of A, instead of presenting it.
Or, set B as the root view controller and forget about A.
So I have an iPhone app. It has a simple structure, all based on a UINavigationController.
I have a storyboard that has one view, a segue to another view, etc. Now this other view has a UITextView that I do not want to edit on this screen - if the user taps this, I want it instead to fly over to a second screen which basically has the same text view, but this one is full-screen, and the user will edit the text on that screen before returning to the previous screen.
So I capture the textViewShouldBeginEditing method. I previously, in the storyboard editor, manually created a push segue from the previous view controller to this new view controller, and named it so that I can call it by it's identity, which I do with:
- (BOOL)textViewShouldBeginEditing:(UITextView *)textView
{
// This is called when the user clicks into the textView as if to edit it.
// Instead of editing it, go to this other view here:
[self performSegueWithIdentifier:#"editMemoSegue" sender:self];
// Return NO, as I don't actually want to edit the text on this screen:
return NO;
}
Seems reasonable. And it works. Sorta. It does in fact shoot me over to that other view. That other view's events fire up, I set it's text view to become first responder, I edit the text on that screen. Everyone's happy.
Until I want to use the back button to return to the previous view.
Then I quickly find out - my navigation stack is foobared. Most of the time, I have, for some reason, TWO instances of my new editing controller on the stack, so the first time I hit the back button I get the same stuff over again. Then, oddly, occasionally, it will work as intended, and I will see my previous controller with only one back click.
I started reading the log, and I found this:
2012-12-09 09:41:03.463 APP[8368:c07] nested push animation can result in corrupted navigation bar
2012-12-09 09:41:03.818 APP[8368:c07] Finishing up a navigation transition in an unexpected state. Navigation Bar subview tree might get corrupted.
2012-12-09 09:41:03.819 APP[8368:c07] Unbalanced calls to begin/end appearance transitions for <SecondController: 0x83881d0>.
So obviously, I'm doing something incorrectly here. The question is, what? And how do I do what I want in the way that correctly appeases the tiki gods of the iPhone framework?
Check to see if the textViewShouldBeginEditing is being called twice. I've noticed that these kinds of delegate calls sometimes are.
How is your #"editMemoSegue" being created on the storyboard? is it created from the textView? if it is then you should recreate it directly from the view controller or from the top status bar on the view controller that way it wont be called twice when you touch the trigger object and when you call it programmatically.
I'm writing an iPhone app using Appcelerator Titanium Mobile. I am hiding and showing the tab group based on what window has focus.
dashWin.addEventListener("focus",function(e) {
if (dashWin.tabGroupVisible == true) {
dashWin.tabGroupVisible=false;
tabGroup.animate({bottom:-50,duration:500});
}
});
The code above hides the tab group when dashWin receives a focus event. However, I see this message in the Titanium console when the event fires while running in the iPhone simulator:
Finishing up a navigation transition in an unexpected state. Navigation Bar subview tree might get corrupted.
A Google search turns up one result: Another StackOverflow question that may have a hint as to what's going on.
I got this error when I linked Action Segue or Selection Segue from one view to another view through storyboard and performed the same segue programmatically again, which makes the navigation controller perform the same segue twice.
2 solutions for this case:
Removing the code that pushes the view. Just let storyboard perform the segue for you. This is good for most situations.
Replacing Action Segue or Selection Segue with Manual Section and do - (void)performSegueWithIdentifier:(NSString *)identifier sender:(id)sender by yourself. You may find this solution useful when you want to customize the behavior of segue according to the sender.
Usually a tab group acts as the root of your app's navigation. When a user taps a tab, that tab's window is focused.
Next, when a user triggers an action that requires a new window appear, it usually appears either modally or on top (in the navigation stack sense) of the current window. In the latter case, tell the current tab to open the new window.
If you set the tabBarHidden property to false (when you create the new window), the tab bar will be hidden for you when the new window is opened by the current tab.
Will this more standard approach work for you?
I had segues that were leading back to my main navigation controller which was causing this. I fixed the problem by setting the main navigation controller back to the top of the stack. Here is the code:
- (void) viewDidAppear:(BOOL)animated
{
[self.navigationController popToRootViewControllerAnimated:NO];
}
Recently, I've faced the same problem. The reason was:
-I was trying to pop view controller twice by mistake.
you can check this crash by setting breakpoints on push and pop View controllers
I'm aware some of you may not be familiar with Monotouch, but this could certainly be a general iOS issue rather than a specific Monotouch issue.
I'm recreating an app with similar functionality to the default mail app:
This is a simple recreation of our app. It's a UIView which contains a UITableView and a UIToolbar. It's loaded from a XIB file (which contains accompanying view controller code). This view is a UITabController view (though I'm sure this shouldnt affect things?).
This has been pushed from a navigation Controller using
controller.PushViewController(inboxItem.Controller, true);
(where inboxItem is a custom object I've made, the Controller property being the inboxItem's view controller).
Pressing the right hand button on the toolbar presents a new modal view (compose new message) - which does its thing and no matter which way its dismissed, upon dismissal, the UIToolbar disappears. However, if I am to click on another tab then click back onto this tab, the Toolbar reappears. Is this a redraw issue?
Am I doing something wrong with the way I'm structuring my app? Or have I happened to stumble across some bizarre iOS/Monotouch bug? (I'm hoping it's for the former - so I can improve my iOS development).
I solved the problem. Basically, what was happening was when the ModalView was being presented and then dismissed, the toolBar was being moved down by 44 pixels each time.
In my example, the toolBar is placed above a UITabBar, so when the modal view was dismissed the toolbar was being moved out of view. I'm not sure why this is happening but I'll be sure to file appropriate bug reports.
One quick and (very) dirty way around this is to move the toolBar up 44 pixels when displaying the modalview, so that when it is dismissed, it will move it back down to the appropriate position.