4 ms·

I've had to resolve merge conflicts with pbxproj files and xib files, and while it's not pretty, it's not a good enough reason to eschew interface builder. Ther

by gdubs 14y ago

I've had to resolve merge conflicts with pbxproj files and xib files, and while it's not pretty, it's not a good enough reason to eschew interface builder. There's a reason that toolset is still around since the NeXTStep days: it's powerful. It gets a lot of giggles from people who are less experienced with Cocoa / iOS, and think that programmatically defined UI is for 'real' coders. In my experience, the amount of time you save wiring-up an app with interface builder is significant. With the editor assistant screen open, you can even drag UI element outlets directly to your code, and it will automatically insert your property declarations (and same with method actions). The idea that I'm going to grok someone else's UI code at a glance -- the same way I would looking at a visual document -- is absurd. Does interface builder fit every situation? Absolutely not. But for the vast majority of apps, you'll get your rapid prototype finished more quickly if you use the tools, and then you can tweak from there.

koko775 14y ago
I stopped having merge conflicts with pbxproj files - ever - once I started making use of this tool in my projects: https://github.com/WebKit/webkit/blob/master/Tools/Scripts/sort-Xcode-project-file https://github.com/WebKit/webkit/blob/master/Tools/Scripts/s... It can be run while Xcode is open; it'll just reset the tree view. It basically alphabetizes everything, so there is one canonical ordering to items that you add to the project.
- deleted 14y ago
  [deleted]
gilgoomesh 14y ago
I second this. When you have a consistent, established framework for managing a part of your program that provides an easy to read, visual overview of that part of your program for new developers (or old developers who haven't touched the code in a while) and which can avoid thousands of lines of meticulous declarative code, you should have a better reason for avoiding it than pompously declaring that it's tricky to maintain computer generated XML in your version control system. For version control and XIBs... you should keep them as decomposed as possible (XIB files support soft links to sub-controllers allowing parents and children to be in separate files) and once fully decomposed, you shouldn't need to merge XIBs -- just treat them as monolithic. If you find yourself needing to merge then you've most likely failed to decompose your XIB enough or you've got too many people performing overlapping roles. If you need programmatic view adjustment, you can implement -layoutSubviews (iOS) or -resizeWithOldSuperviewSize: (Mac) you can handle programmatic reflow or other code-based tweaks if absolutely required Additionally, since a XIB file is a cached, serialization format, every view instantiated from the XIB after the first one loads faster than constructing the view in code.

by gdubs 14y ago

koko775 14y ago

I stopped having merge conflicts with pbxproj files - ever - once I started making use of this tool in my projects: https://github.com/WebKit/webkit/blob/master/Tools/Scripts/sort-Xcode-project-file https://github.com/WebKit/webkit/blob/master/Tools/Scripts/s... It can be run while Xcode is open; it'll just reset the tree view. It basically alphabetizes everything, so there is one canonical ordering to items that you add to the project.

deleted 14y ago
[deleted]

gilgoomesh 14y ago

I second this. When you have a consistent, established framework for managing a part of your program that provides an easy to read, visual overview of that part of your program for new developers (or old developers who haven't touched the code in a while) and which can avoid thousands of lines of meticulous declarative code, you should have a better reason for avoiding it than pompously declaring that it's tricky to maintain computer generated XML in your version control system. For version control and XIBs... you should keep them as decomposed as possible (XIB files support soft links to sub-controllers allowing parents and children to be in separate files) and once fully decomposed, you shouldn't need to merge XIBs -- just treat them as monolithic. If you find yourself needing to merge then you've most likely failed to decompose your XIB enough or you've got too many people performing overlapping roles. If you need programmatic view adjustment, you can implement -layoutSubviews (iOS) or -resizeWithOldSuperviewSize: (Mac) you can handle programmatic reflow or other code-based tweaks if absolutely required Additionally, since a XIB file is a cached, serialization format, every view instantiated from the XIB after the first one loads faster than constructing the view in code.