Change view based on device - SwiftUI - ios

I have designed my app initially for the iPad and am now wanting to add functionality for an iPhone too. Is there a way to check what the device being used is, and then display a view accordingly?
Structured English:
IF current_device == iPhone THEN
DISPLAY iPhoneView
ELSE IF current_device == iPad THEN
DISPLAY iPadView
If possible I also want the iPad view to only be available horizontally and then the iPhone view to only be available vertically if possible.

What you are looking for are Size Classes.
To read current horizontal size class in SwiftUI view you can refer to the environment value of horizontalSizeClass
#Environment(\.horizontalSizeClass) var horizontalSizeClass
Then use it like this in your SwiftUI View:
var body: some View {
if horizontalSizeClass == .compact {
return CompactView() // view laid out for smaller screens, like an iPhone
} else {
return RegularView() // view laid out for wide screens, like an iPad
}
}
It is worth noting that not all iPhones are compact horizontally, and compact size class is present on iPad while in multitasking configuration. You will find all possible combinations here under the Device Size Classes and Multitasking Size Classes sections.
Some articles that may be helpful
How to create different layouts using size classes
Changing a view’s layout in response to size classes

Alternatively you could set an individual threshold based on the devices height (or width) using a variable like this:
#State var isLargeDevice: Bool = {
if UIScreen.main.bounds.height > 800 {
return true
} else {
return false
}
}()

Related

How to make SwiftUI responsive to different devices? (Swift)

I'm doing this tutorial and it requires me to place numbers(CGFloats) in for offset and padding, the problem is, this looks different on different devices. For example, on iPod touch, it goes off the screen.
My question is, how do I make these values change with the size of the screen? I know how to write a function to do this, so I guess I'm really asking: How do I retrieve the screen size data in order to use it?
CircleImage()
.offset(y: -130)
.padding(.bottom, -100)
You can use GeometryReader to get the size of the view that the item is in and then make calculations based on the size.
struct ContentView : View {
var body: some View {
GeometryReader { geometry in
Circle().offset(y: geometry.size.height / 4)
}
}
}
Note that this just retrieves the size of the current View and by default expands to fill available space.
Additional reading on GeometryReader: https://www.hackingwithswift.com/quick-start/swiftui/how-to-provide-relative-sizes-using-geometryreader

SwiftUI - Deal with regular/regular size classes on iPad

I need to make a different layout for iPad on landscape and portrait orientations, but size classes on iPad are always regular/regular. Recommended way to adapt interfaces by Apple is to use adaptive layout with size classes, but on iPad there is no difference between portrait and landscape mode.
Is there any way to present different layout on portrait and landscape orientation on iPad without detection device orientation?
As a example, on iPhone (compact/regular) will be shown as:
And on iPad, in landscape (regular/regular) will be shown as:
So, the goal is show the iPhone layout on iPad when is in portrait mode.
Thanks!
You can force apply horizontal size class depending on orientation. If I correctly understood your goal here is a demo of possible approach (tested with Xcode 12.1 / iOS 14.1):
struct DemoViewSizes: View {
#Environment(\.horizontalSizeClass) var horizontalSizeClass
#State private var orientation = UIDevice.current.orientation
var body: some View {
Text("root_view_here")
.onReceive(NotificationCenter.default.publisher(for: UIDevice.orientationDidChangeNotification)) { _ in
orientation = UIDevice.current.orientation
}
.environment(\.horizontalSizeClass, orientation == .portrait ? .compact : .regular)
}
}

How can I remove views using vary of traits?

I have a view controller with some nested views in portrait mode, but I need to know if its posible to generate a variation on landscape where I only have one image (deleting all my elements that I have in portrait view) or I need to create another view controller for this case.
you can change that in code using traitcollection
For your case
you can use below condition which presents landscape orientation
if traitCollection.verticalSizeClass == .compact {
labelName.isHidden = true // hide label
textfield.isHidden = true // hide text
imageName.isHidden = false // unhide image
}
Note: you have also traitcollection.horizontalSizeClass and it can be .compact or .regular according to which orientation of the device you want to edit and the type of device you are working on.
traitcollection options for different devices

Why does sizeThatFits() return a size that is too small?

I'm learning swift with cs193p and I have a problem with UITextView.sizeThatFits(...). It should return a recommended size for popover view to display an [int] array as a text. As you can see in Paul Hegarty's example (https://youtu.be/gjl2gc70YHM?t=1h43m17s), he gets perfectly-fit popover window without scrollbar. I'm using almost the same code that was in this lecture, but instead i've got this:
the text string equals [100], but the sizeThatFits() method is returning a size that is too small to display it nicely, even though there is plenty of free space.
It is getting a bit better after I've added some text, but still not precise and with the scrollbar:
Here is the part of the code where the size is being set:
override var preferredContentSize: CGSize {
get {
if textView != nil && presentingViewController != nil {
// I've added these outputs so I can see the exact numbers to try to understand how this works
print("presentingViewController!.view.bounds.size = \(presentingViewController!.view.bounds.size)")
print("sizeThatFits = \(textView.sizeThatFits(presentingViewController!.view.bounds.size))")
return textView.sizeThatFits(presentingViewController!.view.bounds.size)
} else { return super.preferredContentSize }
}
set { super.preferredContentSize = newValue }
}
What should I do so this will work in the same way as in the lecture?
It looks like there are 16 pt margins between the label and its parent view. You need to take that into account when returning the preferred size of the popover.
You should try both of the following:
Add 32 to the width that's returned from preferredContentSize
In Interface Builder, clear the layout constraints on your UILabel, then re-add top, bottom, leading, and trailing constraints and make sure that "Constrain to Margins" option is not enabled.
Finally, instead of overriding preferredContentSize, you can simply set the preferredContentSize when your view is ready to display, and you can ask Auto Layout to choose the best size:
override func viewDidLayoutSubviews() {
self.preferredContentSize = self.view.systemLayoutSizeFitting(UILayoutFittingCompressedSize)
}
If your layout is configured correctly, systemLayoutSizeFitting(UILayoutFittingCompressedSize) will return the smallest possible size for your view, taking into account all of the margins and sub-views.

layoutIfNeeded sequence acts differently on iPad versus iPhone; how to fix?

Fire up Xcode and for clarity build only to say 9.3, universal app. So, compare 9.3 iPads with 9.3 iPhones. Build to both simulator and devices - issue exhibits on both.
The app rotates in all four directions.
Have a typical situation where you do something like this...
#IBOutlet weak var doorHeightPerScreen: NSLayoutConstraint!
var heightFraction:CGFloat = 0.6
{
didSet
{
if ( heightFraction > maxHeight ) { heightFraction = maxHeight }
if ( heightFraction < minHeight ) { heightFraction = minHeight }
let h = view.bounds.size.height
spaceshipHeightPerScreen.constant = h * heightFraction
self.view.layoutIfNeeded() // holy! read on....
}
}
Notice the layoutIfNeeded() after the change to the constraint.
Continuing the typical example, you will have something like
override func viewDidLayoutSubviews()
{
super.viewDidLayoutSubviews()
heightFraction = (heightFraction)
// use "autolayout power" for perfection every pass.
// now that basic height/position is set,
save/load reactive positions...
position detail stuff...
}
Check it out ... I was doing this all day and only happened to use iPhones.
Interestingly you do not need the layoutIfNeeded call:
#IBOutlet weak var doorHeightPerScreen: NSLayoutConstraint!
var heightFraction:CGFloat = 0.6
{
didSet
{
if ( heightFraction > maxHeight ) { heightFraction = maxHeight }
if ( heightFraction < minHeight ) { heightFraction = minHeight }
let h = view.bounds.size.height
spaceshipHeightPerScreen.constant = h * heightFraction
}
}
Works fine.
However at the end of the day I put it on some iPads and .... everything broke!
Whenever you rotate landscape/portrait, problems.
After a head scratch, I realized that incredibly you do need the layoutIfNeeded call, on iPad. That's on the identical OS.
Indeed the behavior exhibits regardless of OS version. And it exhibits for ALL iPhones / ALL iPads.
#IBOutlet weak var doorHeightPerScreen: NSLayoutConstraint!
var heightFraction:CGFloat = 0.6
{
didSet
{
if ( heightFraction > maxHeight ) { heightFraction = maxHeight }
if ( heightFraction < minHeight ) { heightFraction = minHeight }
let h = view.bounds.size.height
spaceshipHeightPerScreen.constant = h * heightFraction
self.view.layoutIfNeeded() //MUST HAVE, IN IPAD CASE!!!!!!
}
}
To me it is incredibly troubling that they would work differently.
What I'm wondering is, is there perhaps a setting somewhere to make them work the same? Could it be my fault somehow?
Are there any other know differences between the two - or indeed is it "known" that there are a few bugs like this?
I can't think of anything odd or unusual I did anywhere, except the whole app has override func supportedInterfaceOrientations() -> UIInterfaceOrientationMask { return .All } in the first view as is normal if you want to turn the device upside down; I doubt it's related. Other than that it's a very "clean" fresh app.
It gave me a glitch-in-the-matrix feeling - it was terrifying.
What could cause this?
Per RobM's question, the SimulatedMetrics settings (Attributes tab) on the initial ViewController are...
General scheme of the app: the first scene "General" is full-screen, the size of the device. There's a container to "Live" which is the same size (using "Trailing" etc/ constraints as zero all round). In Live, there's a container view "Quad" which indeed is also fully sized to "Live," so it's also fullscreen. Quad:UIViewController exhibits the issue I describe. Quad contains various objects (images, custom controls etc) which sit around on the view. When the app launches, all is fine.
On rotation of the device (or similar): just after the change to the constraint (I don't know if that's relevant): the layoutIfNeeded call IS needed for iPads (all iPads), but is NOT needed for iPhones (all iPhones). The behavior is identical in the simulator and on devices.
Another example
I found another astounding example of this.
In a UICollectionView, custom cells (just simple static sized cells). If you happen to change a constraint (imagine say resizing an icon or product shot within the cell).
On iPad you do have to be sure to readjust in layoutIfNeeded or it will not work on the first appearance of the cell.
Whereas on iPhone it definitely behaves differently: it will "do that for you", before the first appearance of the cell, if you happen to omit it.
I tested that on every iPad and every iPhone. (Also, the unusual behavior exhibits exactly on devices or simulators: simulator makes no difference.)
I'm not able to reproduce what you're seeing; it would be nice to see a complete example. In my mockup I configured a view controller with a view having a single subview, with a constraint to control the subview height. I altered the subview height constraint in viewDidLayout based on the view size. The behavior was identical for both iPhone and iPad, and worked sans calling layoutIfNeeded on any view.
That said, I think you're changing subview constraints once the view has completed its layout - yes? I think the better way to do that would be to layout your subviews ahead of that, via viewWillTransitionToSize:withTransitionCoordinator:.
func viewWillTransitionToSize(_ size: CGSize,
withTransitionCoordinator coordinator: UIViewControllerTransitionCoordinator)
This way auto layout for the view hierarchy can complete in a single pass. This method is only called when the view is changing size, so it won't be called when the view is first loaded; you'll have to set up your initial constraints somewhere else - since they're dependent on view size perhaps you can use viewWillAppear.
Alternatively, (and possibly more correctly), subclass your view controller's view and override updateConstraints. This is the most appropriate place for changing your constraint constants.
Finally, in your property setter, you shouldn't ever call view.layoutIfNeeded(). If anything, you can set view.setNeedsLayout() so that layout happens in the next runloop iteration, and picks up ALL changes that may need to be represented.
The default simulated metrics size is “inferred”, which (if the scene isn't the target of a segue or relationship) gives you a 600x600 view, which doesn't correspond to the screen size of any iOS device. You changed the simulated metrics size at some point to “iPhone 5.5-inch”, probably to match the size of your main test device.
When a view is loaded from a storyboard (or xib), it's loaded at the size it had in the storyboard. It may then be resized by its container (either the UIWindow if it's the root view of the app, or by its superview if it's the root view of a contained view controller).
In your case, it sounds like your main test device's screen has the same size as the root view in your storyboard, so the test device doesn't have to run as much layout as you might expect.
When you use a test device whose screen size differs from your root view's size in the storyboard, the test device has to do more layout.
I didn't try to reproduce your problem, so I'm not claiming that this is a full explanation of what you're seeing. There may well be an iOS bug involved. Nevertheless, this should explain why your app behaves differently on different devices. I believe this is also why Apple chose the default inferred size of 600x600: since no device screen is that size, all devices will have to do the same amount of layout.

Resources