Re:5 key learnings after 8 years of iOS development
by makecheck on Tuesday April 18, 2017 @10:52AM
(#14139271)
The advantages of Storyboards or other parts of Interface Builder could have been had without the disadvantages; they just weren’t designed properly.
For instance, there is no particular reason they couldn’t have a “view equivalent code” or “convert to code” or similar button allowing someone to start in a visual layout environment but still see what they end up with (optionally choosing to maintain only the code).
Similarly, Apple continues to be terrible about unnecessarily modifying files and creating revision-control nightmares, and this is just poor design. They could have created Storyboards in a way that works with teams and code repositories.
Re:5 key learnings after 8 years of iOS development
by kennydude on Tuesday April 18, 2017 @01:58PM
(#14141185)
I prefer the way Android does things for layouts. You write XML (yeah it's XML, but it works) and Android Studio will generate a preview on the other side of the screen.
Re:5 key learnings after 8 years of iOS development
by antonholmquist on Tuesday April 18, 2017 @07:47AM
(#14138036)
Interesting to hear your view on Storyboards. I know what many developers agree with you althought I have never really understood why :) Good that it works for you. And thanks for sharing your thoughts on the article!
- Storyboards are incredibly, incredibly helpful. I work on complex UI with well structured layout constraints, sometimes with dozens of constraints per view controller. That's a lot of boilerplate code that you'd need without a storyboard. Also, you can see the layout in real time as you create it. No need for a run and check workflow to get layout parameters exactly right.
- While I agree about not using external frameworks for the most part, there are some that I've found incredibly helpful. Recently I used one along the lines of 'TOCropController' from memory. Looked great, no changes needed - saved heaps of time.
- I'm a big fan of Core Data, but I've also worked on projects that it hasn't been a good fit for. I once helped move a project to a straight SQL database (reason was mostly performance related).
- While I mostly agree with going native, there are always exceptions to the rule. The native experience is always best, no doubts there. But sometimes cross platform can save a ton of time, and doesn't detract from the goal of the software.