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.
When I was approached to write a book for the beginner’s series from Wrox, I decided I wanted to take a different approach then any of the other beginning iOS books I had bought. I’ve written software in many languages and never found a beginners book that suited me. Instead I learned by creating something I could use. I decided to take that approach for the book.
“Beginning iOS Development – Building and Deploying iOS Applications” is now written, through edits and off to production. I believe it will be available in late January or early February.
The app the book builds is called Bands. It’s a simple app that would never win an Apple Design Award but instead walks readers through first step things like wiring up an IBAction to a button to advanced topics like using NSURLSession and completion handler blocks against the iTunes Search API.
The chapter I’m most proud of is Chapter 2 “Introduction to Objective-C.” The book is aimed at devs who have written Java or C#. This chapter teaches Objective-C by comparing things like classes, methods and properties to similar code written in Java and C#. It also covers Manual Reference Counting, Automatic Reference Counting and Model-View-Controller. It’s the chapter (and honestly the book) I wish I had in 2008 when I started writing iOS apps.
Its been exhausting. The worthwhile experiences often are.
I hope readers learn as much reading this book as I learned writing it.
If you select “forgot password” from a service and they send you your old password in an email.
In my previous post I laid out the issues I was having with the Game Center Sandbox sending and accepting game invitations.
In the comments you’ll see a link to an Apple Developer Forum thread with a handful of others who have been experiencing the same issue. I also had Game Center experts review the sample code with the only explanation being a bug with the Sandbox.
As of August 30th all seems to be working again. I’ve confirmed with my own code.
For a company that prides its self on things that “just work”, this is unacceptable. I’ve had to delay my app development 6 weeks for a service that I have no control over. Any other service provider would have been forced to at least publicly acknowledge the issue. Others would have been run out of business by developers moving to other solutions.
Perhaps this puts into perspective how Apple feels about the viability of Game Center.
Writing a book has been on my to-do list since college when I decided to minor in English to help balance my Engineering degree. I wasn’t expecting the opportunity until later in my career, but you know what they say about when opportunity knocks.
The truth though is that I’ve been working on the book for almost two months.
Back in late June I got an email from Mary James, an acquisition editor with Wiley wondering if I was interested in co-authoring a project based beginners book for iOS. My co-author, John May, had many more years experience then myself and had written five books previously. It seemed like the perfect opportunity so I took it.
I’m fairly certain my first email to John included the phrase “deer in headlights”. I had absolutely no idea what I was doing nor did I know how a book goes from idea to final print. John was a great mentor, but unfortunately that only lasted a couple of weeks. He got one of those offers you can’t refuse and had to drop working on the book.
I’m not one to give up an opportunity even if I have no idea what I’m doing, so I decided I would figure it out and do it myself.
Who. What. When. Why. How.
The first part is writing the book proposal. The best way to think of a book proposal is market research. Publishers want to know who’s going to buy it, what makes it unique, when you can deliver and why you should be the one to write it. How is up to the publisher.
Publishers already know most of those answers. What they really want is for you to do the research yourself so you know how to differentiate yourself from the crowd then show them how you’re going to do it. Personally I loved doing this research.
The next major part of the proposal is your complete Table of Contents. Obviously they know it will change as the book comes together, but it forces you as the author to basically write the book with just chapter titles and sub headers. You’ll also need to give estimated page counts as well as when you can deliver on each chapter. Essentially it becomes the roadmap to the final product for the publisher. It also helps you the author organize your thoughts so you can quickly execute should the proposal get approved.
The last part, at least for first time authors with Wrox, is submitting a writing sample using the tools the publisher uses. Just like the Table of Contents, this benefits both the publisher and you the author. The publisher wants to see that you can write but also that you can produce within their parameters. You as the author get to learn the tools and figure out if you’re comfortable using them.
It’s a bit of a gauntlet, but with purpose. If you do well the publisher approves the proposal and you’re on your way.
That’s where I am. My proposal, Table of Contents and sample chapter on implementing Local Search in MapKit were approved last week.
Today I start writing.
I’ve been working on integrating Game Center into my game for a few months now. The Game Kit framework is fairly straightforward. The hardest part I originally found was engineering my code to be server/client friendly. This was before the dev center went down. Since then, invitations in the Game Center Sandbox have become a nightmare.
To figure out what’s going on, I created a small sample app to demonstrate the issues I’m seeing.
If you’re a Game Center expert I’d love to get your opinion. Are the following issues with my code or are they issues with the Game Center Sandbox?
If you’re looking to learn Game Center you might find this little sample app helpful with getting started since it shows how to authenticate, get game center friends, send and accept invitations to a match as well as sending simple data to players.
The Sample App – You can get the code here (*) (**)
The app is very simple. It authenticates the local user, gets the users Game Center friends and shows them in a table, then sends invites when the user taps a friends name. Once the match is established and everyone is connected, the players send a simple string of data to each other. All of the interaction is logged to the screen so you can see what’s happening in the code.
Issue: Invites sent from one device never show on the other.
Game Center allows you to either invite specific friends to a match or use auto-match, which looks for other players waiting to join a match. I’ve opted not to use auto-match, instead inviting one specific friend at a time. Both use a GKMatchRequest, but I supply a playerID when creating the match.
The first player gets invited using findMatchForRequest:withCompletionHandler: (which I’ll refer to as findMatch). If the invitation is processed correctly, the app will get a GKMatch in the completion handler.
Subsequent players get invited using addPlayersToMatch:matchRequest:completionHandler: (which I will refer to as addPlayer).
In the past I’d occasionally see that invites from one device would never show on another. This issue seems to have been around for quite a while with a couple troubleshooting steps to make them show up again.
First, make sure you have Game Center notifications turned on the invitee device. The push notification for the invite will never show up if they’re turned off.
Second, use the Game Center app to log out of Game Center, then launch the Sample App and let it handle re-authenticating you. In the past I would need to do this every half hour or so while testing to get invitation push notifications working again.
These steps no longer work for me.
Instead, what I’ve found with the sample app is that repeatedly adding the player to the existing match will eventually get the invite through to the other device. Usually the findMatch call fails to get the invite through but the first addPlayer does work. Additional players often need two or more calls to addPlayer to get other invites out.
This should all work the first time. I can’t figure out why I need to repeatedly add the same player to a match to get the invite to show on the other device.
Issue: inviteeResponseHandler doesn’t get called
Before calling either findMatch or addPlayer, the GKMatchRequest’s inviteeResponseHandler is set. Once the invitee either accepts or declines the invite, the handler gets fired so the inviter knows the fate of the invite. When the invitee accepts the invite, its able to get the match.
This use to fire every time I accepted or denied an invitation. Now it’s very hit or miss.
When it doesn’t fire, the invitee’s match delegate will eventually get a match:player:didChangeState: call saying the inviter has left the match. The inviter never gets any notifications. It’s interesting that the invitee sees this when its never called for the inviter connecting to the match.
I’ve found that if I continue to re-invite the friend repeatedly it will eventually fire the correct callbacks and get all the players connected to the match.
When this process does finally complete, the devices are able to send data back and forth with no issue for the duration of the match.
Does anyone know if this is an issue with the Sandbox or is it my code? Does Apple review apps against the Sandbox or against the production servers?
If it’s my code I can fix it. If it’s the sandbox, how to I successfully test my app before submitting it for review?
(*) You’ll need to set the Bundle ID and Code Signing to one you’ve setup with iTunes Connect in order to test.
(**) GameCenterManager class is based on Kyle Richter book “Beginning iOS Game Center and Game Kit”.