iOS 7 status bar overlaps with the tool bar [duplicate] - objective-c

I just noticed the iOS 6/7 Delta property found under the UIView's structs layout.
What is this for and why is this missing from AutoLayout?

Note: I noticed this question a while ago, but I'm only posting my answer now because the NDA has been lifted
Why does it not appear for AutoLayout?
As you may have noticed, iOS 7 brings about a whole new look. The look of UI elements have changed, but also so have some of their sizes (or metrics in general). This can make interface design to accommodate both iOS 7 and it's predecessors a bit of a pain.
Apple's official line is to use AutoLayout to solve this; this should take a lot of the hassle out of laying out UI elements for you. Sometimes incorporating this is not easily done, especially if you must still support iOS 5 for business reasons, or your interfaces are managed in a way that makes implementing AutoLayout difficult. As such, Apple seems to have provided a way to make your job a bit easier if you fall into this niche category, and they've called this iOS 6/7 Deltas.
Ok then, what does it do?
Whilst the label in Interface Builder is a bit unclear as to what 'Delta' means in this context, the code contained in the .xib file that corresponds to this feature is a bit more clear:
<inset key="insetFor6xAndEarlier" minX="-50" minY="-100" maxX="-50" maxY="300"/>
The key name insetFor6xAndEarlier explicitly states what this does; you can provide alternative insets for UI elements when run on iOS 7's predecessors. For example, the above defines the following delta change:
x: 50
y: 100
width: -100
height: 200
Whilst the values stored in the .xib doesn't correspond to the quoted values directly, there is a correlation between them.
x: -minX
y: -minY
width: minX + maxX
height: minY + maxY
The images below shows this change visually. It's quite an extreme example, but it's to demonstrate its ability. I would only expect in practice to have delta changes of only a few pixels.
You may notice that the values are the inverse for the iOS 6 view; this is because the deltas are relative to the type of view you're working with. If you're editing for iOS 6, the deltas there are in order to transform the element correctly for iOS 7 (the reverse of the example above).
In order to view the different styles, you can change the way Interface Builder presents it based on the OS it would be running on. This is contained within the File Inspector->Interface Builder Document (1st tab on the right bar), as so:
Does this exist if I like to code my interface by hand?
Not directly, but you can easily achieve the same effect by having conditional checks on OS version within your code, and setting the correct position/size accordingly. The delta ability exists in Interface Builder because there would be no straightforward way to have conditional positioning without having code to do it, and the point of Interface Builder is to get a much code out of the way as possible for UI.
Overall...
Apple strongly recommend that you use AutoLayout, it makes your life easier in most cases. If you can't use it (for reasons mentioned above), deltas provide you with the flexibility to position your UI elements appropriately, based on the current OS's metrics, without the need to manually reposition them in code. A good example is to adjust for the lack of status bar, but there are plenty of other use cases.
Naturally, if you're only developing for iOS7 and above, you don't need to know this feature/won't discover it. Only if you need to have iOS6 devices running your application when built with the iOS7 SDK, without autolayout, do you need deltas.
At the time of writing (21st August), I can't find any documentation regarding this feature, nor any mentions in the WWDC material. I've had a play around, and after a bit of research, that is what I've discovered.

This actually refers to the Delta between layout position from iOS6 to iOS7.
In iOS7, some views can hide the status bar or have it transparent and, in effect, it is overlaid on top of your view. So if you put a UI element at (0.0, 0.0) on iOS6, it will appear below the status bar, but on iOS7 it would appear partially covered underneath the status bar. So in that case you would want a delta that matches the status bar height (20.0 points) so that the layout looks the same in iOS6 and iOS7.
I believe this isn't needed if you use autolayout, but of course, then you lose iPad1 support, which many of us aren't willing to concede at this point in time.

I know this is already been answered, just adding a small variant hoping it could also help those who don't use auto layout and still want to support iOS 6.1 and earlier versions.
Read this Apple's Transition Guide - Supporting earlier version
Choose 'View as' to 'iOS 7.0 and Later'
Base UI for iOS 7. For iOS 6 give suitable delta value. Use preview to see how this will render in iOS 7 and iOS 6 device.
Quick steps:
Select each immediate children of root view individually and add 20px to its 'Y' value.
Then, select all immediate children collectively and give delta Y as -20px. You can also do this in batch or individually.

AutoLayout requires at least iOS 6.0. If you want to support iOS 5.0 you couldn't use AutoLayout.
And those deltas are used to help you adjust the view position on different iOS version(mainly iOS 7 and iOS version lower than 7).
I use those value to help me like this picture.

To see iOS 6/7 Delta in action, I will demo with a SegmentedControl that appears properly on both iOS 6 and iOS 7 devices.
First, select your .Xib or ViewController in Storyboard. Uncheck Use Autolayout and select "View as iOS 7 and later"
In the Interface Builder canvas, place your SegmentedControl so that its origin.y is 20. In iOS 6/7 Delta, choose -20 for DeltaY
This will make your the SegmentedControl laid below the Status Bar in both iOS 6 and iOS 7 devices
Another useful quotes from Developer’s Guide to the iOS 7 Status Bar
Deltas can be set individually for each view and work as you would
expect. If your storyboard or nib is set to view as iOS 6, then
setting the deltas will cause that view to be shifted and/or resized
by the set delta amount when run in iOS 7. Alternately, if your
storyboard or nib is set to view in iOS 7, then the deltas will be
applied when run in iOS 6

If you are using AutoLayout, then Delta is not available.
Try this (tested in iPhone 4s running iOS6):
- (void) viewWillLayoutSubviews {
//iOS 6 workaround offset
if ([[[UIDevice currentDevice] systemVersion] floatValue] < 7) {
self.view.clipsToBounds = YES;
CGRect screenRect = [[UIScreen mainScreen] bounds];
CGFloat screenHeight = 0.0;
screenHeight = screenRect.size.width;
CGRect screenFrame = CGRectMake(0, -20, self.view.frame.size.width,self.view.frame.size.height+10);
self.view.frame = screenFrame;
}
}

Related

Objects not show when change iPhone size storyboard to universal in Xcode 7 iOS Objective C

I have iPhone app and storyboard is done.
and every view in story board has iPhone size.
Now i tried to set any any size for views but it has problem.
when change size to iPad (any any) , all of objects in views will disappear and then running app , not showing anything in iPad view.
I don't wanna using another storyboard.
Target Device is Universal and i am using Objective C.
Thank you
Help me.
Update:
Resolve the issue with cells not appearing on iPad, needed to add the UICollectionViewDelegateFlowLayout methods for iPad.
Original:
If you get the size classes to regular width and height (iPad size classes), then set the constraints for your objects, I assume they are a width and height of 0, that's why you can't see them.
I think it's better to build constraints for (any, any) and then create specifically for iPhone or iPad if necessary, if you are creating a universal app.
Let if know if you encounter problems, hope this helps, good luck.

Size Class Design for Iphone and Ipad

I have to support both Landscape and Potrait for Iphone and Landscape for Ipad respectively, Under Size classes is it a necessary that i have to start with AnyAny first for basic layout and then proceed with compactwidth & RegularHeight for support Potrait orientation for Iphone
It doesn't really matter as for each size class you can set installed (as if, active constraint that will be fulfilled) constraints and which will be uninstalled ( disabled ). Just make sure that you don't have overlapping constraints and you are good to go. For more reference there is a great article: http://www.raywenderlich.com/50319/beginning-auto-layout-tutorial-in-ios-7-part-2
Also they have a book about iOS 8 and there you can find even more information.

Behavior changes for updateViewConstraints in iOS 8

I notice some small graphical glitches while testing one of my app under iOS 8: some UIViews elements are not in the right place, others have not the right size.
In a first step, I use storyboard, Auto-Layout and constraints. Then I programmatically tune constraints to perfectly suits devices' screen size, using updateViewConstraints.
Perfect on iOS 7 but with some glitches on iOS8 as on following picture:
./Users/dominiquevial/Documents/Informatique/Dev/Novae Marathon/_log/captures/iOS8 - iPhone 6/pause.png
After investigation I found the problem: updateViewConstraints is not called. I don't understand why, maybe due to some optimizations...
Correcting this problem is easy :
use viewWillLayoutSubviews in place of updateViewConstraints
or add call to setNeedsUpdateConstraints in viewWillAppear
Which way is the best one ?
Depends if the user can cause the views to enter an invalid state after the view appears, if so the first option. If this is not possible the second.
The less work your app has to do the better.

How can Xcode 6 adaptive UIs be backwards-compatible with iOS 7 and iOS 6?

I just watched the WWDC video #216, "Building Adaptive UI with UIKit."
At about 45:10 Tony Ricciardi talks about changes to IB in Xcode 6 to support the new changes.
He says "You can deploy these documents backwards to older versions of iOS".
(where "These documents" presumably means XIBs and storyboards that have specific settings for different size classes.)
I'm not making this up. Go watch the WWDC video.
How is that possible? Trait collections and size classes are only defined in iOS 8. How can runtime behavior that's dependent on UI constructs that are new to iOS 8 work in previous iOS versions?
If it is possible it would be wonderful. You could build apps that will run on iOS 6, 7, and 8, and take advantage of the new flexible UI layout abilities that Apple has added to Xcode 6. I've created adaptive UI logic myself in code, and it's quite a bit of work.
Changes made to the UI with Size Classes in Interface Builder DO appear correctly on iOS 7 devices and the Preview in Xcode. For example, I changed some Auto Layout constraints and font sizes for Regular height Regular width and those changed constraints are visible in the iPad Simulator running iOS 7.0.
All size class optimizations are made available to iOS 7, except size classes that have a Compact Height. This has been confirmed by Apple and is now stated directly in the documentation:
For apps supporting versions of iOS earlier than iOS 8, most size classes are backward compatible.
Size classes are backward compatible when:
- The app is built using Xcode version 6 or later
- The deployment target of the app is earlier than iOS 8
- Size classes are specified in a storyboard or xib
- The value of the height component is not compact
Because iOS 7 doesn't respect a couple of size classes, if you use them you'll run into issues. For example:
When you have Compact w Any h defined and then Compact w Compact h defined, on iOS 7 it will respect the Compact w Any h but on iOS 8 it renders the Compact w Compact h appearance.
So, if you would like to utilize those two size classes and maintain compatibility with iOS 7, I would do any optimizations you desire for iPhone in landscape in Any w Any h or Compact w Any h, then perform your other optimizations for different size classes as necessary, and that way you won't need to use any size class with compact height and will avoid running into issues.
When deploying your app to iOS 7, Xcode will compile your storyboard in two different ways:
For iPhone, your storyboard gets compiled as "Compact-Regular" (Compact width, regular height), and this gets packaged as your "~iphone" nib.
For iPad, your storyboard gets compiled as "Regular-Regular" and gets packaged as your "~ipad" nib.
So if you're looking to deploy to both iOS 7 and iOS 8, you should focus your design on the Compact-Any and Regular-Any size classes. That will give you the best experience in terms of matching the UI across deployment targets. You are, of course, welcome to modify the layout for other size classes, but unless those modifications would get applied to the Compact-Regular or Regular-Regular size classes, then you would not see those modifications on iOS 7.
Note: This answer was relevant to a beta version of Xcode 6 and is no longer applicable to the shipping version. See answers by Joey and Dave DeLong on this page for proper information.
(original answer retained below):
While Storyboards/XIBs configured to use size classes will run on iOS 7, the OS does not currently respect those size classes and appears to use the default 'Any/Any' size class.
I agree that the particular slide you are referring to seems to promise such compatibility, but it doesn't appear to be the case currently (Xcode 6 beta 2).
To test, I created a project (iOS 8 SDK, deployment target of 7.1) with a single button that is centered vertically and horizontally in the Any/Any size class, but aligned to the top left corner in the Compact/Compact size class (e.g. iPhone in landscape). Xcode's Preview Assistant shows that the button changes its position in iOS 8, but not iOS 7. I confirmed this behavior on an iOS 7 device as well.
As some of the answers and comments were discussing the nature of backwards-compatibility, I thought I would share an excerpt direct from the Apple Documentation:
~~~~~
Deploying an App With Size Classes on Earlier iOS Versions
For apps supporting versions of iOS earlier than iOS 8, most size classes are backward compatible.
Size classes are backward compatible when:
The app is built using Xcode version 6 or later
The deployment target of the app is earlier than iOS 8
Size classes are specified in a storyboard or xib
The value of the height component is not compact
~~~~~
That last bullet point is targeted at this discussion, where Apple confirms that as long as "compact height" is not used, it should maintain backwards-compatibility.
Hope this helps someone!
While dealing with the similar issue I found another answer that I haven't seen here yet. Looks like Size Classes in XIB files are not working at all. If I create cell prototype in the storyboard file it works in iOS7 as explained in other answers, however when the same prototype cell is moved into separate XIB file - size classes are ignored in iOS7.
Here is link to the sample project demonstrating this behavior: https://dl.dropboxusercontent.com/u/6402890/testSizeClasses.zip
In the prototype cell I have four constraints from each edge of the grey view. Each of the is configured in a same way: Any/Any - 10, Regular/Regular - 20
It works fine in iOS8 simulator for both XIB and Storyboard, and in iOS7 only cells defined in Storyboard gets updated constraints on iPad:
If it saves anyone time, I believe that the way Xcode 6 provides quasi-backwards compatibility for size classes is via the historical ~ipad and ~iphone suffixed storyboards, and nothing more. This makes sense since size classes are a more abstracted way of how we previously defined an iPad storyboard, and an iPhone storyboard.
Therefore:
If your goal is to use size classes to support device family specific layouts (iPad vs. iPhone), then you are in luck: size classes are a nicer interface to the previously supported method.
If your goal is to use size classes to support altered layouts for different models within the same device family - ie. iPhone 5/6/6+ inc. landscape, then you are out of luck. Using these would require a minimum iOS 8 deployment target.
#lducool - In interface builder, in the Identity inspector, change 'Builds For' to iOS7.1 and later.
Unfortunately the answers from Dave and Joey do not work for me.
I am not allowed to comment in this thread, so please forgive me if this is the wrong place.
I have made up a specific question for that:
Example for iPhone portrait landscape adaptive UI which is backwards-compatible with iOS 7
From what I learned so far, I believe now that, like in my example, is is not possible to have 2 separate, different constraints for one ui element in portrait and landscape mode with iPhone iOS7 based on size classes.
Would be glad if I am mistaken, though.

Window Size for Mac application

I am new to Mac application development using Cocoa. I am confused as to what should be the window/view size. Like in an iOS app we have proper dimensions for small iPod as well as latest iPods. But how to set the size in a Cocoa App.
Also I want to set the deployment target to OS X 10.6, which does not support AutoLayout.
So what would be a good way to resize the windows which should fit every desktop?
There are a couple of things you need to consider when sizing windows for a display under OS X.
First, there's the size of the display area. You could use
NSRect frame = [[NSScreen mainScreen] frame];
but that's a bit simplistic because the user may be displaying the Dock, and there's almost always the menu bar displayed as well. So a better way of determining the maximum display area for the Desktop would be:
NSRect frame = [[NSScreen mainScreen] visibleFrame];
which respects the menu bar and Dock.
As others have pointed out, this rectangle is seldom the most ideal size for a window. Understand too that this rectangle is only a starting point, because your user may have multiple displays, and they contribute to the total area in which a window may be displayed. But when displaying a new window, you always start within this rectangle. Look to NSScreen's documentation to determine this; the methods above will provide a springboard to your understanding.
I don't know how you plan to create and use your window, but for all but the most simple applications, you'll probably use a subclass of NSWindowController with it. If so, it will be your window's delegate. And so there's an important window delegate method that you'll need to implement in it, and it's this:
- (NSRect)windowWillUseStandardFrame:(NSWindow *)window defaultFrame:(NSRect)newFrame
This is where you determine the 'standard' location and size of your window's frame. It's called by the window when the window is zoomed 'out' to what is called the "standard state" (versus the size the user makes it, the "user state"). In other words, it's the rectangle that best suits the content of your window, yet keeps in mind the rectangle describing the 'safe' area in which you can display it. Unfortunately, I can't tell you exactly how to code it, because it depends entirely on what you're displaying inside your window.
You can see, then, that the definition of 'proper' is something entirely different from that in iOS. Best wishes to you in your endeavors.
Don't think too much like programming for an iOS device. On OS X the user can display multiple windows on the screen next by each other. He may want to do that depending on the task your app has.
You're going to have to design your window so that all objects fit inside. Based on that, you can set a minimum size as well as a maximum size. Consider the smallest screen resolutions are around 1200 x 700 and thus your minimum size shouldn't exceed that.
Before autolayout there existed a "springs & struts" way to define how objects resize or position with a resizing window frame.
I recommend you start laying out your app on aper or with a graphics tool and then see how much space is necessary. If more space than minimum resolution is necessary, you will have to start using scroll views, split views or similar to make the interface working in different window sizes.
A lot of useful information can be taken from OS X HIG.