Recently I tried something I had feared for a long time: Using code to create my views instead of using the traditional storyboard.
Backg...
For further actions, you may consider blocking this person and/or reporting abuse
Storyboards are cancer. No one should use them. Good article.
What else should we use?
if you're tired of giant storyboards, you can try using .xib instead. Alternatively you can make your views programatically.
I agree with what @maurandk said. Using Storyboards is indeed a pain in the ass for several reasons like merge conflicts and slow loading but switching entirely to code to create your views is like going to another extreme end of the spectrum. Instead, XIB's would have been a better solution. The interface is important as it allows new people joining your team easily visualize how the view looks. Also, copy pasting the code to the playground just to see what the view looks like is a bit of a tedious process. Don't get me wrong the article is great, for I didn't know you could do that with playground but that doesn't justify moving entirely to code.
Also i would like to point out that in case of overlapping views you can see all the views at a certain position by shift+right click
Just code. There is no need for storyboards in iOS. Do your self a favor and learn how to layout a view programmatically. It will save you time and nerves :)
If I understand correctly, if you want to revisit a view later, you have to copy it into playground again? Still sounds tedious.
Does this address one problem we've found with automated ui testing where views don't have useful ids? (xcode usually generates random ids for views which you can't control). Here I guess you could set your own.
In android, views are usually defined in xml in subcomponents as small as you like. You give each view you want to reference in code an id that you define. When writing a ui test, logically named ids are easy to reference.
Yes, you would have to copy-paste back and forth in most cases. I'm sure there's a workaround somewhere, although it's a small price to pay for the benefit that programatic views provide and not every solution is perfect. Both methods of creating views have their issues.
Addressing the automated UI-testing, I'm not sure on that. I'd assume you'd be able to set the IDs somehow.
I think the problem with providing proper id's to view can be solved by writing an extension over UIView and adding @IBInspectable property to UIView using associated type. Though it would work like a tag with string type instead of int. You can do that if it helps! :)
I encourage everyone to use storyboards first. It's not a fit-all solution, and sometimes you'll need to use a .xib or code, but storyboard should come first.
There's a bit of a learning curve - but heres the thing. If you build ALL your views & layouts in .xib or code... you're creating a maintainability disaster. First off, creating navigation in code is the biggest source of crashes in iOS. Secondly, (for example) when going through a branding change - I can change an entire app in an hour with a storyboard. Where, it could take a whole day to do it in code. And you're bound to miss something.
Good article Jordan - It's great to see young programmers in the community :) It's also great for people to know how these things work in code. Keep it up!
I definitely agree with this, trying storyboards before code is a good idea because then you have an opportunity to learn the ropes of the auto-layout system in an easier environment. Once you go from storyboards to code, it’s much easier than just going into code because then you generally understand how it all works.
Thanks for the Github link 😻
I had to wait 1 minute for Main.storyboard to open up on my Macbook Air. Great tutorial, one thing I hate is that translates thing we have to set to false, I always forget setting it :p
Tips for developers: DON'T USE Storyboard