A few months ago, Andrew and I were working on a project that required some validation of model objects and form data. After looking around a bit, we quickly came to the conclusion that there aren’t any widely accepted best practices for data validation in Cocoa. If you’re using Core Data, you can declare some validators for strings and numbers in your data model. If you’re not, you have to roll your own validation system, perhaps using Key-Value Validation (KVV), a part of Foundation that many experienced Cocoa developers have never even heard of.
7 posts in Tools
I’ll admit it, I was an Interface Builder hater. In the past everything I did was in code: Auto Layout, custom views, custom cells, everything. The frustrations of Xcode 4’s implicit constraint generation made using Auto Layout difficult. Going to code was far simpler.
At Two Toasters, we’ve been building iOS interfaces in code for years. Every so often, someone will suggest that we try using Interface Builder and storyboards, but we’ve traditionally found the experience to be frustrating and unproductive. The tools seemed immature and cumbersome, and with all of our experience building UIs by hand, it never really seemed like a worthy undertaking.
Over the last year though, things have begun to change. There were signs at WWDC 2013 that Apple was putting serious effort into improving storyboards and Interface Builder. A few weeks ago, Apple introduced Adaptive Layout and Size Classes in the iOS 8 SDK, and Xcode 6 features many improvements that aim squarely to address the complaints that people have had about Interface Builder. Apple clearly believes Interface Builder and storyboards are a viable tool for building UIs more productively and efficiently.
Testing networking code is hard. The web service you’re connecting to can fail in myriad ways, from basic networking errors to malformed responses. All but the simplest APIs return a wide variety of data that your app has to handle correctly. Sometimes APIs can be so complex that it’s hard to verify that you’re calling things in the right order, much less sending appropriate parameters and handling responses correctly.
You’ve just finished your latest application. Congrats! Even though you’re only releasing it in English, you’ve used
NSLocalizedString to internationalize your user-facing strings. With strings that require dynamic quantities—“5 items” vs. “1 item”—you handled both the singular and plural cases. You shipped the app and moved on to your next project.
Suddenly your app is a hit… in Russia? You get a lot of feedback that your users want a Russian translation. Easy! You’ll just ship a Russian version of your strings file. Then you realize the problem: in English you can get away with that quick one/not-one check when pluralizing nouns; those are the only two plural categories in the language. Other languages aren’t so simple. Your Russian users have four different rules for pluralizing their nouns. Arabic speakers have six! Thankfully, there are a few tools to help you pluralize nouns for all of them.
Quick Look was introduced back in OS X 10.5 Leopard as a system-wide quick preview feature for documents and images. When Apple announced Xcode 5 at WWDC 2013, one of the new tools introduced was Quick Look for debugging. With this you could preview images, colors, and other common types while stepping through your application. All you have to do is hover over a supported variable and click on the Quick Look icon or hit the space bar when the variable is selected in the Variables View.