We are developing an iOS app using Swift.
We have a tableView where each TableCell is expandable.
It currently looks like this. (Ignore the abbreviation of the time label, this is not intended)
When executed on a tablet the labels from the expanded sub cell should be moved to the parent cell, depending on how much space is available.
It would not be a problem if we have to make a separate scene for tablets and phones.
It would be beautiful, if we could change the display of those scenes directly in the interface builder, depending on which device is selected on the bottom bar.
What is the best (cleanest) way to achieve that?
Thanks in advance.
What you need sounds like the "vary for traits" option in Xcode 8, it allows you to have different configurations of the same view depending on the device(actually based on Width and Height settings) but it narrow down to device as you use it, if you click the vary for traits button in Xcode you will see the various options for W and H and you can see in real time how the devices changes depending on your selection. Just be a little bit careful about one thing, when you introduce a new setting you use the vary for traits button but after that you access it from the right hand side picker as normal.
You will see in Xcode 8 that some attributes have a small + sign next to them, that is where you will find your different traits after you have introduced them, it takes some getting used to but is very powerful once you get your head around it. It is also the recommended way to make adaptive applications in iOS
Related
I've been struggling with this issue for a while and hours of research and experimentation didn't produce any acceptable results.
I have a login screen that contains a lot of UI elements. The view looks great on iphone 7 and 6 variations but when I test it on SE or 4S the constraints fail to position the elements so they fit nicely on their tiny screen. Simply there is not enough room. I read that I must support all screen sizes but at this point I am not sure how can I get all the ui elements to fit in the smaller screens.
I watched hours of youtube videos and tried all possible ways including a vertical stack view but no matter what I try, it either looks good on 7 and 6 but terrible on SE/4S or vice versa (good on SE/4S but way too much white space on 7/6).
At this point I am not sure what else I can do. I know it is not possible to design a UI just for a specific screen size and vary for traits is not what I need because I only intend to support vertical orientation.
Any help or suggestion will be greatly appreciated.
As you have said in your own comment, you can restrict the device sizes indirectly by restricting the iOS version. However that is not a good solution: If you are creating the app for commercial reasons that will unnecessarily restrict your market (there are a lot of 4S users out there); If you are learning app development, now is a good time to work out how to manage GUI layout problems properly (there will always be a wide range of display sizes to cope with).
There are several tools available to assist:
Auto Layout
As others have said in comments, Auto Layout can help a lot. Don't just use it to position things though, but also to resize them to make best use of the available space.
Understanding Auto Layout (Apple)
Size Classes
Size Classes allow you to use different constraints and turn on or off controls depending on the general size and orientation of your user's device. For example, where space is restricted you could hide individual controls and instead display a single control to take the user to them elsewhere (another view or a popover for example).
Size-Class-Specific Layout (Apple)
Scroll Views
You can make part or all of your GUI a scroll view that on larger devices will show all the controls whilst on smaller devices initially show just the top ones but still give your users access to the others (don't forget to flash the scroll bars when the view first appears to show them that there is more to see though).
Separate Storyboards
Although you have not mentioned iPad support, you can also specify completely separate storyboards to help layout universal apps.
See this SO answer and it's linked reference for details.
I'm taking a few first steps in Xamarin for iOS and having a very hard time figuring out how to create a view that is resolution independent.
I have a single textbox in the view, aligned so that its edges meet the edge of a iPhone 6S. When I change the View to a Iphone 4S the edges of the textbox are outside of the view.
I have tried to drag the constrains to the edges, pretty much clicked every button and tried to find some example of how to make it so the view resizes to fit the viewport but I cannot make it work. Ive also fiddled with the different modes of the View (Aspect Fit, Scale to Fill, etc) but that makes no difference.
I would love to se a simple example of how to create a resolution independent or multi-resolution form or view that is displayed similarily no matter the screen resolution on the iPhone.
Having gone through very much the same pain as you, my recommendation is two-fold:
Have a look at the Cirrious FluentLayouts package, which you can
get from NuGet.
A tremendous help in simplifying various issues with auto-layout, especially if you decide (like I did) to just give up on the GUI layout tools and go with a full programmatic approach.
It will allow constructs like:
this.AddConstraints
(
_navBar.AtTopOf(this, UIApplication.SharedApplication.StatusBarFrame.Height),
_navBar.AtLeftOf(this),
_navBar.WithSameWidth(this),
_navBar.Height().EqualTo(Hamburger.HamburgerHeight),
_scrollView.Below(_navBar),
_scrollView.AtLeftOf(this),
_scrollView.WithSameWidth(this),
_scrollView.Bottom().EqualTo().TopOf(_pageControl),
_pageControl.Above(_toolBar),
_pageControl.AtLeftOf(this),
_pageControl.WithSameWidth(this),
_pageControl.Height().EqualTo(pageControlHeight),
_toolBar.Above(_button),
_toolBar.AtLeftOf(this),
_toolBar.WithSameWidth(this),
_toolBar.Height().EqualTo(toolHeight),
_button.AtRightOf(this),
_button.AtBottomOf(this),
_button.Height().EqualTo(buttonHeight)
);
Be aware that since... iOS 8 I believe? ... you now need to use a
LaunchScreen.xib to have your app correctly pick up device
resolution which will then be used by auto-layout.
This was the one area I still needed to use the graphical layout tool for - just once, happy to say.
New to iOS developing here. Basically I am creating a soundboard app. I have the app essentially working (aka buttons returning sounds).
However my app only looks proper on the iPhone 6. I just have one ViewController in my main storyboard. When I run the simulator for the 4S/5/6+ or iPads, my buttons are pretty much everywhere.
I tried playing with size classes/autolayout through Apple's documentation, but couldn't get it working properly. What's the best (easiest ;) ) route I can follow to have it basically looking the same on ALL devices?
PS: I have one background placed too, I don't mind if it looks different on all devices since it's pretty minimalistic, but if someone can shed some light here too, that would be great.
Thanks!
You have a few options:
1) Continue your plan spending time getting friendly with Auto Layout and Size Classes. This might be difficult at first, but it will really pay off later. You should use the Assistant Editor's Preview mode to let you see iPhone 4, 5 and 6 side-by-side as you work so you can make sure your layouts look great everywhere.
2) Use a component like UIStackView where layouts are automatically adjusted to fit various devices. If your soundboard is as simple as a grid of buttons, you can do that in just a few minutes using a stack view.
3) Use a component like UITableView or UICollectionView where content is designed to scroll. Using this method you design only one sound button of your app (i.e., enough to play one sound) then have iOS replicate that across all the sounds you want. When your interface is presented on a device of a different size iOS will just make the content scroll.
Very roughly, option 1 makes you do all the work; option 2 makes your layout shrink down until it fits the available space; and option 3 makes your layout stay the same size no matter what, but you should expect it to scroll on some devices.
There is no right solution; it's entirely down how you want your app to work.
I need help to decide which way to go to reduce code pain.
Upon downloading a certain form from the web in html/text format, I will decide which parts of the form to display on the iPhone for the user to see and/or interact with.
There may be Labels, TextFields, CheckBoxs, RadioButtons and Pickers to name a few. Some pages can be “transformed” into one iPhone scene but others may need scrolling (run time decision).
Since a group of those pages relate to one kind of activity, I like to use one scene/storyboard and to make views/containers show up and/or disappear as needed for the current page.
My options:
TableViews with either Static Cell or Prototype cell (model to supply the correct view/container).
StackViews for ease of laying out.
Hybrid of both above, stackView inside each cell for easy layout and row/cellView deleting.
Plain vanilla views with in a container inside a scrollView (feeling some pain about this one)
Collection view (maybe an overkill).
What would you do?
Thanks
If your deployment target is iOS 9.0 then i would suggest to go for option 3. If deployement target is below 9.0 then stackViews is not an option for you so in that case go for option 1. That will give you scalability like if your fields get increased after sometimes so that change would be accommodate easily with TableViews and in this case approach 4 will definitely be painful.
For an iOS app i am currently working on, I need to manage the controls displayed on the screen based on the type of device the app is running on.
I will try to explain with a theoretical example (the actual numbers used below are not important, what interests me is best method to achieve the desired result).
Example:
In the case of the app in the screenshots, the button that overlaps the UIImageView should not be displayed at all OR displayed in another place on the screen.
So far I've worked with autolayout , but , from what i could figure, there's no way to say to xcode something like: hey, for a class size "Compact Width / Compact Height" , I want you to hide these buttons...but show them for "Regular Width / Compact Height" .
I also did some googling and saw some people talk about using different storyboards based on the device; I am also thinking, I could add/remove buttons dynamically based on the device type , but I think it's not so pleasant to have to add all of the constraints by hand (programatically that is).
So to resume, I would appreciate a suggestion of a 'best' way to do this , best meaning a combination of 'not so hard' + ' not so long'. Also, some code example (or links) would be highly appreciated.
Thank you all in advance !
I think it all depends how sophisticated it gets what you are doing overall. When you look at developer's code for large app projects very little is actually done in interface builder since the apps are so dynamic it's just too much work in IB.
Using multiple storyboards 'sounds' like a good idea, but often isn't. If you want to update/change one, in most cases you then have to change the other ones as well.
What I think is handy:
Use one storyboard (or multiple but for different parts of you app and not parallel ones) and then put in very 'special' cases multiple ViewControllers of the same class for the different size into the single storyboard. That way you won't forget about updating the second (and third) because they are all right there.
I would only use multiple 'parallel' storyboards for apps that support iPhone and iPad and it makes sense to really split them up..
Also:
I would as fas as possible still use just one representation and derive the other 'versions' from that in code. If you build a structured user interface you can then reuse (or just inherit) the code that 'hides' parts of the first viewController in the next. That way your code AND your IB files won't get cluttered.
Also think about internationalisation (if that is part of your future plans), since multiple IB documents and multiple instances of the same viewController layout really don't help for that ;)