New Job Title: Author

I start a new job today; I’m writing a book. Beginning iOS Programming for the Wrox line from Wiley Publishing.

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.

An Email

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.

Map It

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.

Prove It

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.

Do It

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.

Game Center Sandbox – Troubleshooting Invites – Help Wanted!

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.

The Issues

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.

So…

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”.