I am trying to do something I am not really sure is possible :)
I have application that is in portrait mode and doesn't react to device rotation. Almost all parts of app work best in portrait so I disabled autorotation.
But one part should be viewed in landscape. I just drawed my view rotated by 90 degrees and with this forced user to rotate device (again no autorotation). Everything was ok until I added UITableViewController that is invoked from this (and only from this) rotated view. Table view is of course in portrait mode, so user has to rotate device again, which is not really user friendly experience.
My problem is, how to manually rotate table view so it is in landscape mode without using autorotation feature. I was able to rotate it using transform, but I can't position it properly. Is this right way of doing this or did I missed something that would make this trivial task?
I don't want to use autorotation because both part are pretty separated from each other and each of them would be almost useless in other's mode
First thing I'd suggest is to try to find an alternative UI. If you can come up with a better way to do it, you may be able to not have to tackle this issue.
That said, you could use the UIDevice setOrientation (private API) just before you do your push of your new view.
#SanHolo provided me with an answer recently regarding setOrientation that might be an even better solution, but I haven't tried it yet -- you could try putting your table view controller in as a modal view. He implied that it would check the new tables rotation affinity and would automatically rotate when it came into being.
Related
I've been working on my app for a while, and it've been out in appStore for a while as well, but I now want to add support for landscape orientation. I've thought I had just unchecked the orientation-icons in the Summary-page of the target to only enable portrait, but when I check them now, nothing happens! A lot of stash has been added, but I can't find any methods that should disable landscape.. What kind of method would that be? I didn't find anything in appDelegate either.. I don't even know where to start looking.. When opening an empty project in xcode, they orient just fine with no methods at all..
In storyboard, when clicking a view and going to inspector, it says Orientation:Inferred. So the problem isn't here.
I using a tabBar, and all the views in the viewControllers are set to Autoresize subviews, as a similar question got answered.
EDIT
When enabling landscape for iPhone using the buttons in the target properties summary, the iPhone is allowed to go landscape, but when enabling it for the iPad, nothing changes..
shouldAutorotate in iOS6 and shouldAutorotateToInterfaceOrientation for previous version.
Note that the orientation is mostly defined by the ViewController.
you can add or remove the supported orientations in info.plist
I solved the issue by making a class for the UITabBarController, and setting shouldAutorotate... to YES. I find it weird though that my iPad storyboard overrode the Summary-page.
EDIT
This is giving me a hard time with everything else.. The device rotates correctly now, but sometimes when launched in landscape, it thinks it's in portrait.. Still trying to figure that out. Even when I ask the app which orientation the devices statusbar is in, it returns portrait even if it really is in landscape..
This might be a question specific to my app.I have an iPad app functional. I am converting it to iPhone app. So on one of my iPad screens i have 40-50 controls (labels, textfields,buttons,etc). Now can i achieve something like that on my iPhone also. Screen for iPhone is small and i can barely put 20 controls on one screen. Can i have a long vertical scroll view to put all my controls on one screen. I mean user can scroll down and down and have the same exact controls on this iPhone screen as on iPad screen but with different orientation. Or should i separate that one screen into multiple UIViewControllers? Please let me know if you need more information. Thanks.
Simple answer: You can do anything you want.
More elaborate: You could do a scroll view like you mention, but I'm sure this would be sub-optimal. You have a few options to deal with the difference in devices. The one you choose usually depends on the view or the amount of content it contains. You can 1) Simply resize it for the other device (this only works in rare situations where you have a simple view or one without much content). 2. You create a separate view controller for each and launch the appropriate one for the device (per apple docs). You could just slap your view in a scroll view, but depending on the specifics, a tab view, navigation controller, or some other option may provide a better user experience. In the end it's up to you...
I have view that have many subviews, and each have it's own graphics, different for portrait and landscape orientations. When should I load the new graphics when the orientation changes?
If shouldn't be layoutSubviews, I don't also like the idea of reloading resources in view from UIViewController, because of complicated view hierarchy that I have (it would require to pass this information down).
There is also option to register in NSNotificationCenter for orientation changes in each view, and load new resources when it changes. But I don't quite like it either, because I believe that there should be mechanism in iOS that enables that. Or, maybe I should think in a different way, and build different views for portrait and landscape...
What do you suggest?
I would have your subviews all extend a custom view class that has a -setOrientation: method that swaps between the portrait and landscape graphics. Then in your view controller I would override -willRotateToInterfaceOrientation:duration: and add a loop that sets the orientation for all of the children, thereby causing the graphics to swap when the orientation changes.
I think that's the most straighforward way to do it. Using NSNotificationCenter could be tricky and you're left without a guarantee that every child will get the notification.
Anyway, that's how I'd do it. Let me know if you need examples.
Simple question, hope there is a simple answer.
My scenario: iPhone app with NavigationController
Level 1: View with shouldAutoRotate..orientation=..Portrait (works)
Level 2: View with shouldAutoRotate..orientation=..Portrait (works)
When the iPhone is rotated, the views stay on portrait mode, perfect.
Level 3: View with shouldAutoRotate..TRUE (doesn't work on first load)
The first load of the view is in portrait independent of iPhone orientation and stays there, bad. After the view is ready, all rotations are recognized and work perfect.
Is there a way to tell the app "check your orientation now"? Several tricks I found didn't work (anymore) and the apple documentation seems less than helpful on this special topic.
So far the newest suggestion I found was to create a dummy view, show it and release it again, but I tried several places in the app and it didn't work. The view always gets stuck until you rotate the iphone manually. I would prefer a working example, so I can test it directly and see if it works before changing my code, but I'm also thankful for an explanation what to do if it works.
Thanks
//edit: As mentioned in one of the links this is considered a bug and not fixed by Apple, I worked around the problem replacing the NavigationController with own Controllers each with a Scrollview. Not very nice when you have all running and just need the rotation to work as expected, but works at least as expected. Thx to occulus for pointing in the right direction.
Please see this question:
Transitioning to landscape rotation within a uinavigationcontroller
Also:
UINavigationController and autorotation
So a good strategy might be to use Modal dialogs.
I've been struggling for about four days now trying to figure out how to implement the functionality I need. Basically I want to make a tabbar app that you can swipe back and forth between the tabs. Say I have 4 tabs. Would it make any sense just to create a scrollview that's 4 times as wide as the device, and load up 4 individual views side by side? Then I could use the tabbar delegate to simple tell which page to make visible? I could also use itemSelected to update the tab itself if a user swipes to a new page.
does this make sense / is it a good idea? I just need a quick yes or no answer before I spend another whole day pursuing something doomed to failure. Thank you very much for your help...
A page control may help you. Or you can combine navigation controller with tab view. ie use navigate your page on tapping tab buttons.
Whether it's a good idea or not aside, one way you could achieve this is to register a UIGestureRecognizer on the UIViewController in each tab, that when a swipe is detected, changes the tab depending on the direction of the swipe.
My initial idea seemed to work. I made a UIScrollView with a contentsize width of the four views I needed. I turned paging on, and used the UITabBar delegate to switch the itemSelected when a new page comes up. When someone presses a tab, I use the delegate
-(void)tabBar:(UITabBar *)myTab didSelectItem:(UITabBarItem *)item { }
to change the contentOffset of my scrollview. This may not be the best solutions in many cases, however, my app is simple enough that it works quite splendidly for me.
The original question is, how do you enable side-swipe functionality in a tab-bar app implmented using the Storyboard feature.
This question remains unanswered in my opinion.
The way I see it, either the Storyboard tool addresses the problem domain fully, or else who needs it? If you're forced to do something ridiculous (no offense) like making a 4-page wide view to work around the lack of scrolling, then that it is an argument against the Storyboard. If you're forced to add code to do something that is in the middle of the Storyboard target feature set, then it's going to be confusing to anyone who comes to the project later - some things are done via Storyboard, some are done in seemingly unrelated code.
Storyboard is a great visual development idea, but it needs to have its capability heaving ramped up and soon. There is only one answer really to this question; it should be, just add another behavior element. The fact that that is not working is a bug or a defect.