I'm fairly new to ios programming and am implementing AQGridView in a project I'm working on.
I've noticed the example applications provided seem to be able to handle orientation changes and regroup the cells accordingly.
In my application, the AQGridView appears in a UINavigationController stack. Any views prior to the one with the AQGridView handle orientation changes fine and adjust content based off the orientation.
However, once my app reaches the view with the AQGridView it seems to get stuck into portrait mode. Any change of the orientation does not seem to do anything and the AQGridView does not regroup the cells.
I've looked into the source code of the example apps and can't see any difference in implementation to my app.
Am I missing anything here? Is there anything special I need to do for AQGridView to support orientation changes and regroup the cells?
Turns out it was a problem with UITabBarController.
If anyone is having the same problem as me, I'd suggest looking at all the root view controllers for the UITabBarController.
Make sure the following method returns YES for all the view controllers or autorotation will not work.
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
Related
I’m maintaining a universal iOS App whose development has started on iOS 6. I’m about the renew the UI for iOS 7. Now I’ve got a weird problem with the iPad part of the app. This part follows the „normal“ Master-Detail view pattern using a UISplitViewController. The UI is configured in a storyboard. The UISplitViewController is the root view controller as requested by Apples docs.
Here comes the weird part: When the detail view controller is embedded in a UINavigationController the navigation controller will be sized incorrectly by the UISplitViewController and so the whole interface looks broken. It appears as if the navigation controller remains in portrait orientation even if the device orientation is landscape. In portrait orientation the detail view controller is looking fine though.
If I avoid embedding the detail view controller in a navigation controller and connect it directly as detail view controller with the UISplitViewController everything is working perfectly in both orientations.
I tried to reproduce the problem in a simple sample App based on the Master-Detail project template provided by Apple without luck. There it works even with a detail view controller embedded in a navigation controller. No matter what I’ve tried so far (looking for categories interfering, rotation settings, method swizzling etc. pp.) I couldn’t find the cause for this problem. As I’m running out of options (if possible I’d rather avoid rolling my container view controller) I respectfully ask if anybody around here has a solution to this problem or further ideas on how to track down the problem.
Thanks in advance
Tino
Found the solution to my own problem. I created a category on UISplitViewController and added a method 'detailViewController' only meant to be a convenience method to access the detail view. Unfortunately the UISplitViewController has an equally named internal method which is was replacing. Would I have followed Apples guidelines to always prefix category methods in order to avoid name clashes I would have saved a lot of my own time. :(
I had a bug where I would call to transitionWithView and the new view would appear in Portrait while my app and all XIBs are only marked as Landscape as well as the origin view.
I found how to fix the problem thanks to this question (+1) :
I would like to understand though ( and it is not explained there ) - why does it behave this way ? Where in the application is the orientation stored, when is the view notified about the orientation and why views which are transitioned to are unaware of the orientation vs views which are added using addSubview...
Searched a lot but did not find clues .
thanks
I want to have multiple views in my application that I switch between.
What is the proper way to switch between UIViews that also supports UISplitViewController?
Is there a support way to switch or are Apple's controller classes designed to be root and root only?
I've tried having one root view and root controller and swap subviews in and out. One of the subviews is a UISplitViewController. It did not like the arrangement and does not display correctly. The detail view was not displayed, the master view displayed wrong orientation and wrong size.
I've then tried managing adding and removing one subview from the UIWindow in the app delegate. This works most of the time. However, the views added after the applicationDidFinishLaunching method do not appear setup correctly. They mostly look correct, however sometimes the orientation thinks its portrait when in reality its landscape. Also, when I try to display a popover, it shows up in an incorrect location. If I change the orientation, it redraws correctly. I've also have some random instances where the UISplitViewController view does not fully display, as if its frame is incorrectly sized.
Any suggestions heartily appreciated.
In applicationDidFinishLaunching, your objects haven't completed loaded from NIBs yet. Try using a viewDidLoad method instead.
What is the user-interface for switching between views? If one of these views represents a transient mode that the user enters and then exits, consider using a modal view. (See presentModalViewController:animated:.)
I would need more details about what you're doing to answer more particularly.
I have an UISplitViewController base project.
I want to have a different detail View depending the orientation of the app.
Exemple :
In landscape when I select a row in the TableView, I want the detailView to be an UIWebView.
But in portrait I want the detail view to be a complex custom view.
Is it possible ?
Thanks.
See the MultipleDetailView sample project for the basics.
The easiest way to shift views based on orientation is to use a navigation control to push an pop the each orientations custom views in response to changes to orientation. Put the nav code in willRotateToInterfaceOrientation:duration: and the view controllers will pop their views and push the other when the device rotates.
I would say, however, the using two different types of views for the same detail but different orientation will most likely confuse the user. That is not what the interface grammar teaches them to expect. In every other app, it is the same basic view with the same info just adjusted for the change in display dimensions.
You might want to think twice about whether this is a good UI design before spending the time to implement it.
I am trying to implement a split view controller like UISplitViewController on the iPad, but I don't want the left pane to be hidden when the device is in portrait orientation.
So I've created a UIViewController subclass for this in IB and it works fine without any sub-view controllers. Now I'm trying to wrap my head around what is required to setup and manage the two UIViewController objects for the left and right panes. In my app, they are going to both be UINavigationController with a UITableView in them.
I've hit a mental road block about how to set this up and was hoping someone could point me to some sample code or give me a recommendation for architecture here...
The only reason to use the UISplitView controller is the show/hide logic it gets you for free. I would think it a lot easier to simply take the two view controllers (Root View & Detail View) and lay them on a standard UIViewController. You can then manage them more diorectly without overriding the intended behavior of the implemented controller.
THe settings app on the iPad does what you are looking for and I believe this is the approach that app takes.
Good Luck!
is setHidesMasterViewInPortrait still a private Api and the app will get rejected?
Create your UISplitViewController instance and then call:
[splitViewController setHidesMasterViewInPortrait:NO];
The compiler will give you a warning message but it will do what you want. You can get rid of the compiler warning by making a category on UISplitViewController that implements that method.