i guess i missed something really important in the apple manuals which causes me having this problems.
I will describe what i want to have and what i get instaed + what i do.
Preamble:
goal of my work is a app having a login-screen. this screen is supposed to be placed ontop of all other views, to fade out later. so in this case i guess i already break a rule, in case i understood that "only-one-main-window-guideline" correctly.
What i want:
having an universal application √ check
having an universal application which has UIInterfaceRotation for iPad only √ check
not having troubles regarding uiinterfaceorientation or uideviceorientation on startup allowing me to show all views in proper dimension without having to rotate a few times to have it all properly positioned. - not checked
What i get:
when i start the app in landscape, which is default orientation from my views in interface-Builder, its perfeclty aligned and i can rotate all i want, its perfect, stays perfefct, hooray
when i start the app in portrait, i see the landscape-views flying around on the screen - each time on diffrent pace - at least that seems like. when i rotate the app now, forth and back, its all aligned as it should - also perfectly as wanted.
What i do:
99% of all rotation-related settings is made in interface builder, i currently just have some did-change-methods to change background-images when rotation is done and so on.
i noticed, that even when i build the screen after device knows its orientation, it leads to this.
so in other words:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
[[UIDevice currentDevice] beginGeneratingDeviceOrientationNotifications];
[self addEventListener:UIDeviceOrientationDidChangeNotification sel:#selector(buildScreen)];
....
note: addEventListener is a small notification-category i created for easier handling. so no magic in here.
in build-screen i add all subviews.
at first, the actualy screen in the background, this screen will get the login as subview (which does not matter since when i add login to main-window itself, situation is the same).
So in this case, i really dont know what do do next.
Once orientation-alignment is setup, it all fits perfectly as i defined in IB.
Any help, links, code, etc, appreciated. thank you very much! i tried searching for this, just found many similar problems, no solutions. so a little sorry in case i seem to ask the very same question, a big one if i really do.
Best Regards
I wouldn't normally recommend this because i think it's annoying as a user, but you could try the Info.plist setting
Initial interface orientation
and set this to the Landscape if this is what works for you.
Could be a temporary workaround. I recon your issues are much more complex though than a simple suggestive fix.
I did not find a proper solution, so i used multiple-xib files to get it done. It's annoying but it works well.
Related
Been trying to find some tips on suggested approach for this and not having much luck.
All I'm looking for is to know what is the best approach to handle custom layouts for portrait/landscape modes.
I've seen some posts say in the storyboard add 2 views to the same ViewController and show/hide based on orientation change while some people suggest to use a totally separate ViewController for each orientation.
Which of this is the preferred method. I'm just starting my application, So I'd rather go for the widely accepted method than have to deal with complications later on.
Apple documentation still keeps talking about nib files and not storyboards in this aspect, so not being of much help.
My main focus is performance (I'm fine with having to code stuff instead of depend on the graphical interface for it). separate ViewControllers seem to keep the code in a clean way however if that involves populating views / clearing them every time orientation changes, seems kind of expensive(not sure if it is relevant).
Also if each scene in the application has 2 layouts then managing them I'm not sure how much of a pain it's going to be when the application grows big.
Please point me in a suitable approach for my case,
am not concerned about backwards compatibility. Just worried about the latest Xcode and ios6 if it matters for the decision
Thanks
I would say this really depends on the level of customization of the UI in portrait vs landscape. A large number of implementations I have done can be handled by either autoresizing/autolayout when switching orientation, or simply moving the elements yourself when the UI is rotated and the callbacks are fired. Moving the elements around should not be an expensive operation at all as it is a very common occurrence (again this depends on the complexity of your UI though).
I always get stuck with managing rotation on iOS application, there must be some kind of efficient way to do it but apparently I haven't heard of it yet. My interface is too complex to be parametrized in InterfaceBuilder so I tried doing all these different things:
Build two interfaces, one for portrait and one for landscape, but I found it awfully tiresome to devise some methods that enable one view controller to keep up with the other, so when the device is rotated the second view controller knows where to pick up the story.
Change my views' frames manually inside willRotateToInterfaceOrientation:, but in this scenario my whole interface turns into a bloody mess quite randomly (while sometimes it does the job alright...)
What do you think best practices are? Where might have I gone wrong? What did I miss? Thx!
I always go for the second option and it has never let me down. If you do it right, you will have always the expected result. What I think it's happening to your application (and you call it bloody mess quite randomly) its because your UIView's will probably still have some autoresize definitions on the Interface Builder. Besides removing all the autoresizes I also uncheck the "Autoresize subviews" checkmark from the parent UIViews.
Just playing devils advocate to JackyBoy's comment, I think it depends on the complexity of your view. In lots of cases I have found it simpler to just use a landscape UI. The benefit for me is the ease of visualization. You know (more or less) what you are going to get without as much trial and error and it's easy enough to pass whatever data is needed along (i find that easier then dealing with moving UI components around programmatically). That said, I don't know if there is really a best practice. It's a do what feels best to you kind of thing, I think. Though if I had to guess Apple's definition of what the best practice would be then it might be to use the two views.
Oh, I should also add that you can leverage the 'springs' and such for components in a nib that can sometimes be enough to handle the rotation as well
I'm playing around with the TV-out Adapter for the iphone. My goal is to have an external window display on my tv in order to play movies from my iphone.
the big problem I've got now, is that if the phones orientation changes (physically) the window that shows on the tv turns as well. which is of course unwanted behaviour..
So far i return NO from shouldAutoRotateToInterfaceOrientation. But it still turns and turns.
I'm very grateful for any help on that topic
cheers
sam..
Ah well the solution was rather simple.
I had to assign a RootViewController to the Window that I'm using. Said Rootviewcontroller then needs to implement a shouldAutoRotateToInterfaceOrientation Method (that of course returns NO).
I have different view controllers and i linked them using insertsubview
There are atleast three levels of subviews for every screen the users sees.
I havent tested it on device yet.
I want to know whether this causes any performance issues
Also, is using NavigationBarController pop and push views better than addsubview and remove from super view.
(I dont want the back functionality of NavigationBarController and want a custom header. That is why i didnt use NavigationBarController)
This is an interesting statement :
I haven't tested it on device yet.
My advice is simple :
Test it on a device.
Only you know what your app does - you can't possibly think we can answer your question with so little information! 3 doesn't seem a very big number but I don't know what each of those views is doing so maybe it's an issue, maybe not.
Recently I've been looking to create some way of showing a user that something is being loaded. I'm sure anyone with an iPhone has seen this is apps before but what is the best way of doing it?
I started using UIProgressHUD, however it was pointed out to me that you shouldn't really use private (undocumented) API's.
I then I moved onto this which is a custom version called MBProgressHUD, however in my experience with this is wouldn't show the loading part when trying to call it not from a button and I found it very buggy (It wasn't very hard to crash the example code given by just clicking away).
I then went on to find this by James Brannan from his book, however I'm not quite sure why he claims this is the "proper way" of doing it when I've seen many apps in the past with what looks like the UIProgressHUD.
Does anyone have any ideas?
EDIT: This is pretty good...
Thanks
There is no one "best" way. Another way to do this is to simply put a UIView atop your main view's subviews, mark its userInteraction property and grey it out when needed. You could even add a UIActivityIndicator as a subview of this "foreground" UIView, starting its animation when needed. When your loading has finished, hide/stop the activity indicator and clear the foreground view's color.
If you are talking about loading over a network, one good thing to start with is to enable the status bar network activity indicator:
[UIApplication sharedApplication].networkActivityIndicatorVisible = YES;
Note that you have to set it to NO when you are done! That should only be used to indicate network activity.
That's a bit subtle though, it's a great idea to have some kind of progress indicator IF you can tell exactly how long something is going to take - downloads where you know the size and count incoming bytes, or uploads where you also monitor bytes outgoing and know the total size.
If your call length is very small or the size is not really known (web service call is a great example) then some kind of overlay with a UIActivityIndicator can be very relaxing (you can also make a custom variant with a set of images added to a UIImage view to animate). The key is, that if possible it should not block the user from doing other things if possible.
Also if you have multiple things going on, you might want to add messages describing what state you are in (like, "adjusting image", "uploading image", etc).