Archive for January 2014
I answered my first Stack Overflow question today. I’ve learned so much there over the years and decided its time I start giving back.
My answer is actually a follow-up to Tom Harrington’s after I saw his tweet…
If your only hammer is Core Data, GET SOME MORE HAMMERS. http://t.co/W4743W9Wkn
— Tom Harrington (@atomicbird) January 12, 2014
The question was how to store a single entity, in this case a password, using Core Data. Tom’s answer was to not use Core Data at all because its bad design. I completely agree with this. My followup answer was to use Keychain, which is the correct approach.
Passwords are very special data which demand special attention. Storing a password as clear-text in any type of database or storage scheme is a security flaw. If the platform you’re developing for has a well tested and secure way to store a password, use it. For iOS that means using Keychain.
Keychain can be difficult and intimidating to new iOS developers. I believe that’s why some decide to forgo it and instead use things like Core Data or NSUserDefaults. That’s where Buzz Andersen’s STKeychain comes in. Its open source, free to use without restrictions and most importantly tested and used by many iOS apps. Its solid code that makes interfacing with Keychain really simple.
I’ve also used Keychain to do two factor authentication with digital certificates. The code from my 360|iDev session is probably a bit outdated but the concepts are the same.
One other consideration about using Keychain is if you ever need to get your app certified for enterprise security. In my experience building enterprise iOS apps, password security is always asked about. Knowing how Keychain works and passing along Apple documentation answers those questions throughly.
I started a new Xcode project this week to kick the tires of the new unit testing framework built into Xcode 5. I’ve long been an advocate of unit testing. Its great to see it being tightly integrated into Xcode and continuous integration. My impression so far has been very positive. Most of the hoops you needed to jump through in the past are now gone reducing the excuses to not unit test.
If you’re on the fence about unit testing, here’s a few thoughts to consider…
Unit testing forces you to rethink how you design your code. I compare it to building a brick wall. Instead of focusing on the entire wall, you concentrate on just a single brick. The brick needs to be crafted well and tested to make sure it won’t fail and bring down the wall. Unit testing forces you to break down complex problems into manageable, understandable and testable pieces.
You’re Not Coding Alone
Most likely you’re working on a project with other developers (if you’re working by yourself you should consider your past self as another developer). Unit tests show other developers how you intended your code to be used. If someone needs to modify code you wrote, your tests will tell them if they are keeping with your intent.
Unit tests are also very handy when coding against web services. Your tests will alert you to changes in the request or response allowing you to adjust your code appropriately.
Unit testing also involves creating a mock environment for the tests to run against. The mock environment can help you reproduce real world bug reports. Its much easier to tweak a few parameters in a mock environment then to try and recreate a real world situation.
It may seem like you’re writing double the code. That’s because you are, but its well worth the effort.
Here are some unit testing resources from Apple:
Unit Test. You’ll thank yourself later.