I have an application with a tabBar containing 3 UISplitiViewControllers. Everything works well except for one scenario:
I have the ipad in landscape position on tab1. I click on tab3, then I rotate the ipad portrait mode. I click on tab1, it is well displayed in portrait mode, I'm happy.
I now come back to landscape position.
I click again on tab3 and there, the splitView controller is still displayed in "portrait mode". the delegate of my splitviewController in tab3 was never called.
Is there a way to force the rotation of this splitViewController in the "viewWillAppear"?
Your might find this git useful.
It is just a simple subclass of UISplitViewController that is notified of rotation changes.
Alternatively, this is a more robust replacement that adds lots of features.
Hope it helps.
BTW I have gotten apps approved using these classes.
After a deep analysis of event bubbling, it appears that rotation events are not forwarded to hidden splitViews...
There is no way to forward these events without using hidden apis.
Lots a developers have the same problem and this implementation of event management in splitView has been reported as a bug to apple, even though guidelines are to use only one splitView added to the root view of application.
Related
In our app we are tracking screen views manually by adding relevant codes in viewWillAppear functions. With iOS 13, with the non fullscreen modals, the viewWillAppear of the parent screen won't get called when the modal is dismissed and hence wrong screen names are reported there after, for events originating from the parent screen.
I have checked the Detecting sheet was dismissed on iOS 13 , but the solution to implement UIAdaptivePresentationControllerDelegate helps when you manually swipes down.
I then turned off manual tracking and turned on Automatic tracking and surprisingly the screen classes are determined right. Question is how Firebase is figuring that out?
Of-course I can't use auto tracking as we need custom screen names.
I believe this could be a generic issue for whoever using manual screen name tracking and have non full screen modals. Just wanted to check what's the best way to solve this.
Couple of ideas I had was
Make all modals full screen. Not nice for our app
Implement extra delegates in those modals to let the parent know its dismissed. Not sure its a nice way
Setting screen names on each event? Could that be even possible?
If there are any other nicer/ cleaner option let me know.
When i present a modal screen from a page in page based navigation, the whole screen shifts up and the status bar is no longer visible.
Here is a gif of the issue:
I am using xCode 6.2 version.
This was not happening in xCode 6.2 Beta 4..
I am not sure if this is a simulator issue or this will actually happen on a real device too.
Does anyone have the same issue? Is there a workaround?
I reported a bug to apple (20109240) and it was marked as a duplicate of (19862945), and that one is still open.
Thanks in advance
This is a known issue in the final release that exhibits itself in two cases:
When presenting a second modal controller (paging or single) over an existing paging modal controller
When presenting a menu using Force Touch over a paging modal controller
This has been discussed in the Apple Developer Forums, and the only workaround I've heard about is one that I use in my app. Unfortunately, there's no simple code to share that solves the problem, so I'll describe the approach (which I'd consider messy, but workable).
First, you need to keep track of interface controller presentations. I have a framework for this, but you may have to roll your own. When a child interface controller has its willActivate called two times in a row (in other words, without a call to a different child interface controller) you can assume that a modal was presented/dismissed on top of it.
Your presenting/parent controller can then inform all children that the modal menu bug has happened, and those child controllers can unhide a replacement status bar with its own Cancel/Close button. With some work, you can recreate a pixel-perfect version of the standard status bar with identical behavior.
The final twist is to detect when your Watch app is suspended, then resumes. In that case, willActivate is also called twice. If you don't handle that situation, you'll end up unhiding the replacement status bar and have two on the screen simultaneously. Not a great scenario.
Getting this right is very tricky, but it does work. I just wish I had a simple code sample that you could inject.
Update: I pushed some of my workaround code to GitHub: https://github.com/mikeswanson/JBInterfaceController
I found several problems with rotations in ios6 using iPAD...all of us...I resolved mostly all of them using the new method shouldAutorotate and shouldAutorotateToInterfaceOrientation. But in one of the views is not updating properly the rotation. You can see (more or less) what happen:
The top images describes the behaviour from landscape to portrait...if I change the rotation of my app in other different of the first image, and come back to the first tab, the app doesn't update properly the view in portrait.
The bottom images describes what happen when I am comming from portrait to landscape...in the last screen I can the half of the screen completely black.
My level in iOS is really basic I will like some tips...what do you think which could be the problem? because in other tabs is not happen of the same app it is not happen.
If you need a piece of code, let me know...thank you!
Try this:
https://github.com/alexth/TBSV
Sample how to have NavigationBar, TabBar and SplitViewController in one project with correct looking transitions between orienations
Thanks for your reaction (ironic). I've discovered what was the problem with the rotation only in a particular screen of my app. The problem is that the one that built the app before me, used one UISplitViewController inside of a UITabBarController. This mix of ViewController, in iOS 6 bring a bunch of problems, specially with the rotations. After thousands of tries, I found this link and it is solved.
UISplitViewController inside UITabBarController in iOS6:
http://objectiveseesharp.wordpress.com/
That's all.
Should I change the title of the question?
As the title describes I am having a big "what the * is this" at my app atm. It seems I can't get the control over the orientation at all in the different slides.
I can only manage the orientation in one way, via the info-plist file. The problem is, info-plist file sets the orientation for the whole app and I am not interested in that.In some slides I want to allow Landscape left/right and others only Portrait and this is not doable vie info-plist?
I have tried my best to understand the problem but I can not say I have gained any bigger "aha moment" so far. I am using UINavigatorbar and Tabbar in my IOS-app which may occur the problem. How can I make the app to start listening to the code in each-file so I can manage the orientation localy ?
Are you using iOS 6? If so, the -shouldAutorotateToInterfaceOrientation method was deprecated.
You now have to override -supportedInterfaceOrientations and -preferredInterfaceOrientationForPresentation methods in order to manage screen orientation. You can do this globally or within individual view controllers.
See the UIViewController class reference for more details.
What I meant is, When we use a UISplitViewController project
In portrait mode, whole window will be covered by the view and a popoverController will be presented to navigate to other views. In landscape mode, 40% of the window will be covered by a tableView using which we can change the view/page. And navigation button as well as popoverController will be hidden.
What I want is,
Even in landscape mode, it should be like portrait mode. No tablewView should be there. Whole window should be covered with the view in landscape mode. For navigating to other pages, a navigation button as well as the popoverController should be there.
How can I do this?? Plz help me...
Login to your developer account, goto dev forums and search for "UISplitViewController settings.app". there's lots of talk about that there. The summary is you can't do it though that controller apparently has some private features which make it possible (file a bug report telling apple they should expose that capability). There is a long discussion about building a splitview controller from scratch that mostly works this way. Alternately, rethink your design.