Is there any way to limit the amount of curling of that kind of presentation? I know that system automatically curls depending on content inside view of the viewcontroller that we present modally in taht way.
But thta's not working for me in my iPad app. I have only a little table at the bottom right corner of the view but the page curls more than a half.
I double checked all properties and autoresizing masks without find a solution.
Any suggestion?
I am having the same problem. Same source code for iPhone and iPad, but the iPad version is curling the page too much, leaving a lot of free space. Then I tried to only put a label on the bottom of the iPhone version and the same thing happens.
Explanation: Apparently UIModalTransitionStylePartialCurl always curls half the page, at minimum. The only reason in iPhone does not leave free space but it does in iPad is because, as the screen is much smaller, in iPhone usually your controls take not a lot less than half the page, which does not happen in iPad.
The only workaround I have found is re-designing the iPad layout so that your UI controls take more space, or just "living with it".
Related
Since Apple is requiring a storyboard launch screen in a few months I went ahead and tried to add one. Adding one is simple and it works just fine but it screws up the layout after loading the app. No longer does a larger screen automatically adjust the resolution, instead I'm left with an SE layout on an 8 Plus screen placed in the top-left corner with the background image repeating (like wallpaper from a 90s website). I'm not using constraints, but I'm not even sure if that's the issue. If so I have a feeling I have a lot of work ahead of me (keep in mind I've never had a need for constraints). A side thought though is, from what I understand, Apple wants all apps to look correctly on all devices... makes perfect sense. But my apps have always appeared correctly no matter the device. So it's ironic that adding the launch screen is breaking my apps' appearances. Is it the constraints? Is there an alternative solution? Or is there hopefully something simple in the launch screen that needs to be changed? Thank you!
I need clarification on how the container view in Swift 4 is supposed to work. I was under the impression (maybe falsely so), that if I set up all my labels, buttons, etc. inside of a container, set that container to zero for the left and upper constraints, centered it vertically and horizontally in the main view, and then pinned all of the fields within that container, then everything would be proportionally increased or decreased, depending on the screen size.
I designed my screens on a storyboard, using an iPhone 6 sized screen.
The App should be viewed only in Portrait mode, so I needn't worry about dealing with Landscape modes. I am finding out that the text fields within the container are keeping their sized fonts; when going to a larger screen (8 Plus), I am getting a large border on the bottom and right.
When going to a smaller screen (SE), most of the verbiage gets truncated. Have I misunderstood how this is supposed to work, or am I not doing it correctly?
I am almost ready to submit my first App to the Apple Store, but want to make sure that it will handle all possible sized screens. The 2 IOS courses I've been referring to are pretty vague on exactly how auto layout works. Also, I am getting over 24 warning messages that all of my fixed width constraints may cause clipping. (15 yard penalty?).
Hopefully, someone out there will have the patience to explain what I thought should be an easy thing to do. Here are screenshots of my initial view controller using each of the 3 sizes:
Originally Designed Screen, set to iPhone 6
Screen set to iPhone 8 Plus
Screen set to iPhone SE
Many thanks in advance for helping us out,
Jones
Stack views are meant to do exactly what you are trying to do. Here is a version of your app that uses stack views to create the example below. There is also a link to the GitHub page with the code - feel free to use it, tear it apart, whatever. Good luck!
https://github.com/squarehippo/Baseball2.git
I've got this application mainly displaying photographs.
The app was originally written for iOS 3.1 and upgraded to 4 before beeing published. It was not touched ever since. Now that the owner of the API appied some changes which ain't as compatible as they thought, I am forced to update the app. So I'll have to go for iPhone 5 and 6 and 6+ and iOS 7 and 8 updates in one go.
I observe this behaviour in the simulator of iphone 4, 5 and 6+ dimensions.
Portrait looks fine.
Landscape left looks fine too.
Landscape right is screwed up. Apparently it looks as if the whole screen were shifted to the left.
This is strange because I am not aware of anything that I would do different for landscape right or left. All I am doing is differnicating between any portrait and any landscape orientation.
It worked fine in the old version. But frankly I cannot reproduce this any more because I don't have access to the old xcode and sdk versions. But the app is in store for years and works fine on modern devices and modern OS versions.
A bit more background info, just in case it is of importance:
The app is based on a UITabBar, but it is not visible in this view.
The image is scrollable. It is placed on one view three times of the size of the screen with preceeding and succeeding image views place to the left and right respectively. This view with the three images is placed within a scroll view of the size of the screen or window respectively. This concept still works file, it is just shifted.
When I check the view item's frames in debugger or with NSLog, they all seem to be right, starting at (0.0/0.0) or respectively.
The view on the bottom with the four buttons that navigate to related functions and their view controllers, is re-alligned programmatically on each rotation, as well as the overlays with the textual information. All works as it should but it's shifted in this one orientation.
Well, all views are layouted programmatically on each rotation.
There are no constraints defined.
iOS6/7 deltas are all set to 0.
The app "wants fullscreen". By tapping on the image all UI items disappear and re-appear on the next tab. (Just by setting the .hidden attribute. Except for the navigation bar. Thats managed using setNavigationBarHidden:animated: with YES on animated) Works fine, even in the shifted view.
I am running out of ideas.
While I put all the details together for the question, eventually one idea came to my rescue.
The issue is related to hiding the tab bar. I could not use the regular way of hiding the tab bar because then it would not re-appear when navigating down to the functions that are associated with the buttons on the bottom overlay view.
Therefore I did some sort of hack. I did not hide it regularily but moved the tab bar out of the screen.
AND: This was the only thing that I did differently for landscape right and landscape left. I just searched for the constant names and found it.
Apparently, manipulating the tab bar view had a flaw in older iOS versions. (Or in older SDK versions, I am still working on that important detail)
To overcome the flaw the tab bar view was modified this way for landscape right:
[self.tabBarController.view setFrame:CGRectMake(0-kTabBarHeight,0,width+kTabBarHeight,height)];
This does not seem to make sense but did help me out a lot on similar issues years ago when the app was written.
Now, I changed this to:
[self.tabBarController.view setFrame:CGRectMake(0,0,width+kTabBarHeight,height)];
which is the same for landscape left too.
For the time beeing I separate between iOS versions >= 8.0 and smaller. But I'll double check that with older devices and may get back to this answer later.
I leave the question posted because I found the original "hack" here on SO too, so that I guess that others will have the same issues when updating to ios 8 or SDK 8 respectively.
Thanks for listening.
I am working on an app and have come into some graphical problems when designing my app.
First off, my app is only support by iPhone. My current storyboard is using the iPhone 5 as the screen size, so everything screws up when I try to run in iPhone 4 and 4S. Is there a way to make multiple storyboards for each different screen size? Or do you all have another solution?
Thanks!
- Brad
There is a way to make different storyboards for separate screen sizes, but another way to do it is like this:
Whenever you add objects to your views, be sure to have them aligned to something (using constraints). If all items are relative to other items, then most likely the layout will be fine on all devices. Also, if you find that your controls start overlapping, then perhaps you ran out of room. In that case simply add a scroll view to your layout, and then put the controls on top of it. Then, it won't scroll on the larger screens because all controls are shown, but on smaller devices it will allow you to scroll down to see the rest of the objects.
Good luck.
There is a small button in the lower right hand corner that lets you toggle between 3.5" and 4" screen sizes so you can see how it will look on different devices. By using Auto Layout introduced in iOS 6 you can make sure to set up your constraints so that your UI looks good on both older and newer iPhones.
I have encountered a very strange problem and I was wondering, if anyone could help me out here since I'm totally lost.
Context:
I am developing an app with a relatively simple hierarchy. Just a few view controller but quite a lot of high-res images. They are presented in a UIScrollView with some text etc. While testing it in portrait mode the scrollview didn't scroll smoothly at all. It seemed like the framerate droped to about 4-5 fps. First I thought it was because of the high-res images.
But then I turned the iPad to landscape mode and everything ran smoothly. Since the I have a separate xib-file for portrait and landscape, I thought there has to be a problem in the portrait-xib. It turned out, there wasn't. Both had the same VC-class and where therefore using the same code and both xibs are almost identical except for the sizes and positions of the views.
To narrow the problem down, I used Instrument's TimeProfiler to see whats causing the problem. As it turned out, TimeProfiler showed some calls to [NSISEngine optimize] (triggered by NSLayoutConstraint).
In portrait mode were more calls and those calls took much longer. Further down the tree I saw that in portrait mode [NSISEngine optimize] called [NSISEngine fixupIntegralizationViolations] and in landscape it didn't.
I even removed all the viewcontroller's from the app except for the rootVC and one other which is presented by the rootVC. The presented vc just contains some images, buttons and some animations. It has only one xib for both orientations and is (as all others too) layed out with autolayout.
The layout works as it should in both orientations and there are no ambiguities (as far as i can tell. at least po [[UIWindow keyWindow] _autolayoutTrace] doesn't show any).
I've attached a screenshot of the TimeProfile of the presentation process of the vc. One for portrait and one for landscape. As you can see, in landscape the calls to [NSISEngine optimize] take only a millisecond while in portrait they take over 3000ms.
Is there anyone who can tell me why that is? Or maybe has any idea what I can do to find out what the problem is?
Any help would be greatly appreciated!
Thx
Link to a larger version of the image: link
I ran into the same issue with a moderately complex view where it performed well on non-Retina iPads or a Retina iPad in portrait mode. In landscape mode on a Retina device it took 10x longer to display a popover or push another view on the view stack. I ended up replacing the XIB file with a hand coded loadView in the view controller. That appears to have eliminated the problem. Interface builder has a tendency to create excessive constraints, so getting that under control is key to good auto layout performance.
I have also opened a support ticket on this problem.
Update:
I found the cause in my situation. It was the following set of constraints:
NSArray *constraints = [NSLayoutConstraint
constraintsWithVisualFormat : #"|[sunLabel][monLabel(==sunLabel)][tueLabel(==sunLabel)][wedLabel(==sunLabel)][thuLabel(==sunLabel)][friLabel(==sunLabel)][satLabel(==sunLabel)]|"
options : 0
metrics : nil
views : labelViewsDictionary];
It specifies that 7 labels within a parent view all share the same size and all extend the width of the parent view. I believe that the excessive relational nature of the layout was giving auto layout fits, particularly because the parent view width was not evenly divisible by 7.
To resolve it, I created an array of constraints that specify the width of each label and applied those constraints. When the device rotates the width of the parent changes so I go back and adjust the constant on the constraints to be 1/7th of the parent view width. This now performs well, the process of loading a popover now takes less than 300ms rather than 2000ms.
I filed a tech support request regarding this issue and finally got the answer, that it's most likely a bug. Bug report is filed. Hopefully they'll fix it soon. If there's any news I'll update this answer.
I had same problem yesterday in an Ipad iOS6.1 device. Instrumenting the app found that the method fixupIntegralizationViolations was taking around 300 ms every time was called (around 20 times, which is a lot) making the app absolutely useless.
My problem was very similar to the one Jack Cox comments, but I solved it differently. My constraint was:
#"H:|[allButton][inStoreButton(==allButton)][onlineButton(==allButton)][sortButton(50)]|"
The issue is that the parentView here is the full iPad landscape width, so the math of this contraint was giving each button this width: (1024-50)/3 = 324.6666667.
This is usually not a problem in autolayout since it takes care of big float numbers and round them correctly, but it seems that in iPad iOS6 Landscape rounding this numbers triggers a bug that blocks the UI. To go around it all I had to do is change the sortButton with to have 52, so each button width now is: (1024-52)/3 = 324. That's all. Now the method fixupIntegralizationViolations takes around 1ms every time is called.
The interesting thing is that using 52 gives it a not decimal width in Landscape, but it does give a decimal number in portrait : (768-52)/3 = 238.666667. However, portrait seems to not have any bug and autolayout rounds the numbers correctly.