I've read around that Apple is hinting to developers at a larger-screen iPhone by pushing developers to use Storyboard and auto-layout. I understand why auto-layout would be useful, to organise items according to screen size, but what do Storyboards have to do with anything?
I may be missing an obvious advantage (in relation to larger screens), so any help would be much appreciated. :)
A. You say that there are some notice from Apple about the larger screen of the iPhone6: This is impossible because Apple doesn't release any information until the date of Keynotes and WWDC.
B. You can or not use Storyboard, and you can or not use AutoLayout: the 2 things are separate because you can also use AutoLayout in nib or programmatically.
C. What developers don't know, is that Storyboard are just a market move. I spoken directly with a my friend engineer in Apple about this and the information is real. The reason is also obvious. Is not the topic to speak about this but you can search on google and you will find a lot of information about the advantages to don't use storyboard.
Yes, storyboard are easy, but are not developer friendly if you think to work in a serious project with a big team. In a team you can use GIT, you can use shared repositories, you can export a part of code with the interface...in all this thing, Storyboard are BAD!
So i encourage developers to DON'T USE storyboard and use at max NIB file, or write the UI directly by code.
There currently doesn't appear to be any advantage to using storyboards versus XIBs or programmatic layout as far as multiple screen sizes are concerned. Auto-layout is definitely advantageous as it allows you to define your interface elements in relation to each other (and the screen), as opposed to using fixed numerical values for location and size. This would allow the UI to then easily adapt to varying screen sizes and aspect ratios.
The only potential reason storyboards could become useful for multiple screen sizes in the future is if Apple adds functionality to them to allow you to define entirely separate views based on device/screen size. So for example, they might make it easy to show a view with an extra sidebar on a larger screen, but show a separate view without the sidebar on a smaller screen (they might make it possible to configure this easily in a storyboard, versus writing a bunch of code to detect the screen size and load the appropriate view programmatically). As of now, though, no such functionality exists, but that could be a potential source of the rumors regarding storyboards being useful for multiple screen sizes.
Related
For a very large ios project with the huge amount of features and complex user interface, would like to have the suggestions for following -
Will it be more easy and convenient if we use different storyboards
for iPhone and iPad Screen sizes as developers used to do a couple of years back when UIStackView was not there?
What are the best practices to achieve the complex UI using storyboards, Auto Layout and also have a maintainable code? Please share your experiences.
Will it be more easy and convenient if we use different storyboards for iPhone and iPad Screen sizes as developers used to do a couple of years back when UIStackView was not there?
Using different types of storyboard / xib will increases your bundle size. So it is not a good idea. Before xcode-7, developers do not have any good choice instead of this. Now you can use auto-layout, it can easily maintain your whole screen.
If your design is something like master-detail (like device setting) then you can use different VC's.
What are the best practices to achieve the complex UI using storyboards, Auto Layout and also have a maintainable code? Please share your experiences.
You can auto-layout, size classes, even vary of traits is more helpful to maintain the designs.
I think it's better to use only storyboard for iPhone and iPad , where you can create constraints in proportional to screen size , and tweak constants with add variations plus using size classes for handling screen variations with adaptive layout
I would advise to use Adaptive Layout with Size Classes and Auto Layout.
On quite a large universal projet, it saved me a lot of time, especially, as you pointed out, since UIStackView!
https://www.raywenderlich.com/162311/adaptive-layout-tutorial-ios-11-getting-started
Using sub storyboards is also a great relief on very large projects.
Having two sets of storyboards is quite painful as you have to duplicate many things. I only use a specific storyboard, when the UI on both platforms is really really different.
I'm working on an app dealing with too many Nib or Xib files. One main xib is calling other xibs as subviews. I want to manipulate called xib height programmatically according to data size. Till now I only know how to handle a generic view.
where you are
after taking a quick look on the xib file you have shared, especially its hierarchy and its settings, I can say surely that xib file is not prepared to support any dynamic sizes at all.
that simple xib file has about 200 other views, and individually all views has the very default autoresize-mask setting; that is the
UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleBottomMargin
which means (briefly) all views are glued to the top-left corner of its superview and will not change neither their location nor size if its superview does so; as we know that is your problem exactly.
take a look on this screenshot, it is quite talkative (the purple rectangle shows the common default settings of all views here):
NOTE: it seems no one really cared about building up the view layer properly for supporting the essential different sized screens, which has been crucial part of iOS development since we have got iPhone5; by now it has become much more crucial as we have iPhone6 and 6+ devices as well.
where you should head to
you are encouraged to use either autoresize-mask or auto-layout for setting up your view, but teaching you about these tools and techniques from scratch is far beyond this answer's purpose, but I can recommend you to take a look on the advanced auto-layout (which is supported since iOS6) to support dynamic screen sizes in your view layer. later, if you feel necessary you can also adopt supporting size-classes.
the Auto Layout Guide from Apple can teach you the magic about that, and thousand brilliant tutorials are available on the web from developers.
the Multiple Size Classes documentation is also available on Apple's site, and if you need, the related tutorials are also around everywhere on the web.
NOTE: it is hard to give you direct instructions for how you should change your xib file at this point as the final rules, which will be applied for supporting dynamic sizes, depend on your (client's) policy of how you'd like update an individual view's size, what you'd like to see or show on the screen, etc...; therefore unlimited number of variations of possible settings are available which could satisfy your requirement of supporting dynamic sizes.
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 ;)
I have a feeling about iOS development on which I would like to get feedback.
Storyboard / Interface Builder are, at first glance, awesome tools. The truth is that aside quick prototypes and really simple user interface I always feel blocked using them. This question offers probably a good example: how can I use one storyboard for 4" and 3.5" iphone screens with autolayout (ios6 + ios7)?
I am considering to code all my views. Mostly because it will let me implement some logic, like equal spacing of elements. Something that is, AFAIK, impossible to do in a cross device fashion through the GUI tools.
My questions are: Does Storyboard / IB support advanced view layout? How do you usually code your view if you do so: extending UIView / tweaking the controller?
EDIT: the accepted answer link is nice. Interested readers could also look at Apple's Auto Layout Guide relevant example: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/AutoLayoutbyExample/AutoLayoutbyExample.html#//apple_ref/doc/uid/TP40010853-CH5-SW7
http://www.raywenderlich.com/83276/beginning-adaptive-layout-tutorial
Ray gives a decent starting guide on how easy it is to create a single adaptive view now, which has caused me to switch from being completely programmatic.
Previous to iOS 8 it was much harder to build complex layouts using Interface Builder. You were essentially limited to stretching or pinning to edges. Now you can build layouts that adapt to size classes and change their layouts or constraints based on the width and height of your device.
That being said, even in really difficult scenarios that IB can't handle, I still end up building chunks of views in XIBs and then laying out those chunks manually.
TLDR; Interface Builder is going to be helpful 99.9% of the time as long as you know how to use all its features.
I'm working on building a universal iOS configuration application for the iPhone/iPad. But the layouts ('views') for the iPad are considerably different from that of the iPhone. Considering that only the appearance of the application ('views') change w.r.t the device, what is the most efficient design approach i could follow?
Things I've already looked at
I've looked at one strategy where different View controllers are loaded depending on the device in use. But this might be an overkill considering that the 'controls' are the same across devices and only the appearance of the application changes.
The use of functions to resize the view frames to layout views as needed automatically. This does not help me much because there is a need to not only change the size of the views but load different views altogether depending on the device.
To keep the viewController unchanged but configure the views inside the viewController differently. Right now this seems like the best way to do it, but the application is kinda heavy and it might become very messy in the long run. Or is there a very efficient way to do this?
Is there a design strategy for this?
Or is there any way i can accomplish this efficiently while optimizing effort?
The standard approach is to have different XIB files for iPhone and iPad, which the platform will select automatically if you name them right, e.g. myview~iPhone.xib and myview~iPad.xib.
You are concerned about inefficiency: I wouldn't worry about the file size as compiled XIB is quite compact.
In my apps I mostly use this approach, with some fragments of code to add or remove buttons for each platform. Simple views can just be set up to resize automatically using the standard struts-and-glue techniques.