21–30 of 105 posts
RegexKitLite - Powerful regular expression support
Use NSRegularExpression instead. It's built into the OS (in Foundation) as of iOS 4, which is below the minimum target you have (if you support the iPhone 5).
Every nib you use is a boatload of code you don't have to maintain. Use nibs. Can they solve every problem? Goodness no. But they're a great way to get the basics of your views laid out. They give you an easy way to preview the behavior of your view when layout changes.
And they're very forgiving when you change your mind. Changing text alignment? One click. Want to change the balance or padding of some elements? Nudge them around with a real time preview until you're happy. Mess with different color combinations in your UI to your heart's contentment.
Doing all your view layout in code gets damn tedious when you have to compile and run each time to check your results.
Every now and then some crackpot will come along and tell you never to use nibs. Ignore them. Use nibs when they make sense for your workflow. End sermon.
Otherwise you can just use git submodules. I would recommend against it. They become a real pain down the road. I wish I had something to suggest as a replacement. We're still trying to figure that one out ourselves. We just know we won't use submodules again. For now, we're manually managing disjoint repositories.
It has been super easy compared to git submodules.
Thanks - as it happens I'm about 3 months in to learning Objective-c and iOS development. This is super helpful, as many of the tutorials online are dated. Right now I'm working through the Ray Wenderlich stuff which is really good, at least as far as I can tell. w/r/t using the visual XIB/Storyboard interface vs. coding the views, I've found early on that while the nibs and storyboards make it easy to prototype and…
Earlier quoted context omitted.
Agreed. If iOS actually had a sane declarative language like Android's xml layouts then I'd do everything in code but since layouts coded in Obj-C are excruciatingly painful to read and edit you're better off with a WYSIWYG tool, even if (IMO) WYSIWYG is fundamentally the wrong approach for UI development. I actually consider this a big liability for Apple going forward. The explosion of "phablets" and other form fac…
Cocoa Auto Layouts are what you're looking for: https://developer.apple.com/library/mac/#documentation/UserE...
The thing I have missed the most with Objective C is the lack of a code tidy/formatting tool. All Xcode can do is alter the indent on each line which isn't useful. Regular indent etc do not support the language. There is an uncrustify tool in various SO answers but it is a good example of how not to do things (eg by default it does nothing - there are no presets, it is very flaky). I wish Google provided tidy tools w…
Have you tried JetBrains's AppCode? http://www.jetbrains.com/objc/ (I haven't but their RoR-tailored IDE RubyMine is the only IDE I've enjoyed using after it for less than a week.)
Earlier quoted context omitted.
100% agree. IB makes for faster development time, easier maintenance, and it's way better for auto layout if you're targeting iOS 6.0
I think there's a case to be made though, that using IB when starting out doesn't make you fully understand how UIViews work. So starting out I'd probably recommend you make your own views programmatically to know what you're hooking into. That said once you get that base level of understanding, nibs and storyboards are huge time savers, and are the way to go.
The thing I have missed the most with Objective C is the lack of a code tidy/formatting tool. All Xcode can do is alter the indent on each line which isn't useful. Regular indent etc do not support the language. There is an uncrustify tool in various SO answers but it is a good example of how not to do things (eg by default it does nothing - there are no presets, it is very flaky). I wish Google provided tidy tools w…
I am totally satisfied with Uncrustify, and this is my Uncrustify's config for Objective C, in case you find it useful (Allman style): https://gist.github.com/940977
Otherwise you can just use git submodules. I would recommend against it. They become a real pain down the road. I wish I had something to suggest as a replacement. We're still trying to figure that one out ourselves. We just know we won't use submodules again. For now, we're manually managing disjoint repositories.
The replacement is definitely the article's first suggestion: Cocoapods. Cocoapods is awesome and is rapidly being adopted by major repositories like AFNetworking, Kiwi, TTTAttributedLabel, MagicalRecord, and more: http://www.cocoacontrols.com/cocoapods It has been super easy compared to git submodules.