Categories
Nerd Fun Programming

Getting Xcode and GitHub to work together like besties

Updated for Xcode Version 7.3.1 

Thanks to Jake for pointing out that his blog post needed a little freshening up!

After watching the WWCD keynote I wanted to fool around in Cocoa and Objective-C again. It’s been a while and my Xcode skills were rusty. One task that always seems tricky is getting Xcode’s local git repository to work well with GitHub’s remote repositories. I clicked around, read some docs, did a little Googling, and experimented until I got it to work and in way that works every time.

There are many other blog and stackoverflow posts on this subject but most are either missing a critical step or making it out to be way more complicated than it really is. That’s the problem with Apple magic: Sometime’s they design away the details to a point that you really don’t know what is going on.

The best tutorial on Git, Xcode, and GitHub for the white belt hacker is here: http://www.raywenderlich.com/13771/how-to-use-git-source-control-with-xcode-in-ios-6

But the part on connecting your local Git repository created and managed by Xcode to your remote GitHub repository is a little brief and lacks detail that might trip you up. Here is all you need to do to get Xcode and GitHub to play nice…

  • Create your Xcode project with a local Git repository and write some code
  • Commit your changes locally (File > Source Control > Commit…)
  • Create your GitHub remote repository on GitHub but do not initialize it and do not add a readme.md file!
    • Note: You can give that remote repository any name you want, I gave it the same name as my local git repository because I’m lazy
  • Go to the Source Control menu and and choose the second item with the name of your repo. This item leads to a popup menu. Choose the last item of that popup menu which has the name of your repo and word “configure”
  • In the configure dialog choose the Remotes item
  • Click the + button and choose “Add Remote” to associate a remote repo
  • In the Add a Remote dialog box you have two fields to fill out
    • In the name field enter the name of the GitHub repository you just created
    • In the location filed paste the “HTTPS” URI from GitHub for your repo
    • It will look like this: https://github.com/you-account-name/your-repo-name.git
  • Now you have a connected local and remote repository 🙂
  • Go back to the Source Code menu and choose Push…
    • A dialog box pops up with a drop down menu
    • Choose the only option you can which will be something like your-repo-name/create
    • Click the push button
    • Enter your user name and password in the dialog box that appears

You Win!!

Remember to check “Push to remote” in the Commit dialog box so you check in your code both locally and remotely.

Extra Credit:

I use Two Factor Authentication and I had to turn it off to test this. That made me a little nervous and I immediately turned Two Factor back on.

However you can generate a Personal Access Token so that that you can push to GitHub from Xcode and keep Two Factor on!

  • Log into you GitHub Account and go to Settings > Personal Access Tokens
  • Click the Generate New Token button
  • Give the button a description such as “Xcode Repo-Name”
  • Check the least amount of scope needed to commit code remotely: “Repo”
  • Click the Generate Token button at the bottom.
  • Copy the token (which is a long string of numbers)
  • Back in Xcode go to Preferences > Accounts and choose your repo under the list of repositories.
    • The Address field will contain the HTTS URI you entered earlier
    • The Description is the name of your repo
    • Authentication should be set to User Name and Password
    • User Name should be your GitHub user name
    • In the Password field paste token

Boom! Now you can commit remotely with Two Factor Auth in full effect!

 

Categories
Cocos2d-iPhone Programming

ARC Memory Management in iOS 5 and Cocos2d-iPhone 2.0

My rewrite of Dungeonators is crawling along at a glacial pace. Mostly because I can only work a couple of hours a week on the project. But the iOS 5 way to manage memory with ARC (automated reference counting) is making the process far less painful than it was the first time I wrote my game. ARC uses annotations and some new key words to manage memory on your behalf. It works very well if you’re doing simple client-side game development and don’t have to worry about backward compatibility with iOS 4.

Here is an example of how ARC changes your life for the better…

In the old days you would declare out your ivars, declare your properties, then synthesize and map them together, and release them in a dealloc method. This little design pattern required 4 repetitive lines of code for every ivar (instance variable) and engendered flamewars about  coding style and where underscore should go (if you thought it was necessary to distinguish an ivar name from a property name).

Pre-ARC Entity.h

#import "cocos2d.h"
@interface Entity : CCSprite {
BOOL isActive_;
NSString * name_;
}
@property (nonatomic) BOOL isActive;
@property (nonatomic, copy) NSString * name;
@end

Pre-ARC Entity.m

#import "Entity.h"
@implementation Entity
@synthesize isActive = isActive_;
@synthesize name = name_;
- (id) init {
  self = [super init];
  if (self) {
    isActive_ = YES;
    name_ = @"Fang";
  }
  return self;
}
- (void) dealloc {
  [name_ release];
  name_ = nil;
  [super dealloc];
}

In this new modern era of automated reference counting I just declare properties, I don’t worry about accessing the ivars directly, and I don’t write my own dealloc. It’s a lot less code in a complex game where characters and objects have dozens of properties.

Post-ARC Entity.h

#import "cocos2d.h"
@interface Entity : CCSprite
@property (nonatomic) BOOL isActive;
@property (nonatomic, strong) NSString * name;
@end

Post-ARC Entity.m

#import "Entity.h"
@implementation Entity
@synthesize isActive;
@synthesize name;
- (id) init {
  self = [super init];
  if (self) {
    isActive = YES;
    name = @"Fang";
  }
  return self;
}

To get Cocos2d-iPhone to work with ARC was really easy: I just replace the NSAutoreleasePool object in main.m with the new ARC friendly @autoreleasepool annotation. (I might not have had to do this but it’s supposedly more efficient.)

int main(int argc, char *argv[]) {
//    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
//    int retVal = UIApplicationMain(argc, argv, nil, @"AppDelegate");
//    [pool release];
//    return retVal;
  int retVal;
  @autoreleasepool {
    retVal = UIApplicationMain(argc, argv, nil, @"AppDelegate");
  }
  return retVal;
}

The downside, as I stated above, is that your app will only run on iPhones, iPads, and iPods running iOS 5 and you need to use Cocos2d-iPhone 2.0. But I think that’s a fair tradeoff. Backward compatibility is a killer of the artistic soul and should be avoided where possible. To Err is human, but to upgrade is divine 🙂

Check out Ray Wenderlich’s excellent ARC tutorial for all the gritty details!

Categories
Cocos2d-iPhone

Invalid Code Signing Entitlements

Finally after 11 months I submitted my iPhone game, Dungeonators, to iTunes Connect for inclusion in the Apple App Store. I’m planning on giving it away so the “warcraft meets angry birds” funs is accessible to everyone! I hope it passes Apple’s review process 🙂

It took several attempts for me to get to “waiting for review status”. Here are the step I went through in hope that if you, in the near future, need to submit an app for the first time, you can succeed on your first attempt.

At this point set a cold beer within easy reach…

  1. Most of the info from Apple and the books on iPhone development is based on the old Xcode 3-based application submission process. Google Xcode 4 iTunes connect for the most recent tips. I’m not even going to include a link because the info goes stale fast. Just google it.
  2. Set your app’s pricing and metadata in iTunes connect. You’ll need a 512 x 512 icon too.
  3. Follow all the directions about distribution certificates and distribution provisioning profiles. Like a double-linked list your distro cert should point to your provisioning prof and vice versa.
  4. First create the distro cert via keychain access app on your map. Make sure there is key associated with your distro cert after you install it in your key chain.
  5. Second create your distro provisioning prof and install it in Xcode 4. Make sure your target’s code signing entitlements point to your distro provisioning profile for the release build.
  6. Clean and Archive your app with the Product menu in Xcode 4. The Archive scheme should be set to your release configuration.
  7. In the Organizer window validate and submit your app. You’ll need your iTunes Connect password.
  8. If you get the dreaded “invalid coding signing entitlements” don’t panic. It could mean a lot of different things. But if your iOS app is simple then it’s most likely  the iCloud entitlement. (Google it for more info.)
  9. Go to App IDs in the provisioning portal. Scroll to the bottom. Click configure on the row that represents your app’s ID. Uncheck Enable for iCloud. Click Done. Create a new distro provisioning prof and reinstall it into Xcode 4. Go to iTunes Connect and reject your binary. Go back to Xcode’s Organizer window and do Validate and Submit again.
  10. If you get an invalid binary. Drink a beer and try again! (do while beer != empty)
See, that was easy!
Categories
Cocos2d-iPhone Programming

Hey It’s Easier Than You Think (Xcode 4 and Subversion)

I love how the new Xcode 4 shows you code changes side-by-side with it’s version editor view. But I had a little problem. I’m a subversion fan. Yes, I know, totally not cool. I keep this flaw a secret and I don’t force my preference on my co-workers nor do I tweet about it. I’m sure with years of therapy and the love and support of my family I’ll get over it.

But in the meantime I’m working on an iPhone game and I have a free subversion repository from my ISP. I want to continue to use this fee repository even though Apple gently nudges you to GIT with Xcode 4.

I’m stubborn. I tried GIT and it’s not doing anything for me. My change control needs are small. The functionality that makes GIT great is way more than I need: I’m not working on a large team with a complex build system that has to commit changes with the finesse of a tightrope walker.

Today I went back to subversion and my free repository when I had to update my iPhone to the release candidate 3 of the Cocos2d framework (which is host on Github BTW). Back when Xcode 4 was release I just could get Subversion and Xcode to play nice. But being stubborn, I tried again and to my surprise succeeded.

I don’t think Apple changed much. I think I was just impatient and misinformed. There is a lot of silliness about how to set up Xcode 4 to work with a Subversion repository on the Internets. What worked for me is the functionality that Xcode gives you out-of-the-box (without using the terminal). It was point-and-click but just not automated.

If you’re interested here is how you get a hosted subversion repository to work with Xcode 4. Have fun and don’t sweat the snickers from your more version control evolved friends 🙂

  1. Create a new Subversion repository that you can access via your protocol of choice (mine is the open Internet and HTTP because that’s what Dreamhost provides). Leave this repository empty–we’ll use Xcode 4 to set up all the directories. Just remember your URL and password.
  2. Open Xcode 4 and go the Repository tab in the Organizer Window.  Click the tiny little plus sign in the lower left corner to add a connection to a Repository. Enter in the URL and password and wait for the little circle to turn green. Xcode 4 should automagically detect the type of repository. Be patient. This process takes a bit of time and there is absolutely no feedback: Apple forgot to spin the beach ball here.
  3. When you get the green circle click on the root directory icon on the left under the name of the repository and create 3 directories using the New Directory button on the bottom: trunk, branches, tags. Be patient again and wait for the directories to show up in the center pane of the Organizer window.
  4. Click on the name repository on the left and enter the names of our your 3 directories in the 3 fields provided. (See the genius of naming them trunk, branches, tags?) If your spelling is good you’ll get 3 more green circles.
  5. Click on the Trunk directory on the left and then click on the Import button on the bottom. Select the folder that contains the project you want to put under source code control. Now go away. Get a drink and watch an episode of South Park. You have to be patient because not only is there no beach ball, spinner, or progress bar, there is no green circle!
  6. When you come back you should see your imported directory listed on the main pane. If you click the arrow to the left of it you’ll find your Xcode 4 project file and a subdirectory of files. Remember to be patient. Your poor overworked laptop has to ask the Subversion server for all this info and it takes way longer than 200 milliseconds to get back to you.
  7. Make sure your original Xcode project is closed and hidden away for safe keeping. Click on the imported project in the main pane of the Organizer window and click on the Checkout button on the bottom. Select a location on your hard disk to store your working copy of the project that won’t conflict with the original project. It should be OK to overwrite the original but I’m just paranoid. (Years of experience will do that to you.)
  8. Get a cup of coffee and troll Reddit for some laughs. When you come back Xcode should ask you in a dialog box if you want to open the project that you just checked out. Say yes and run it just to be sure it’s all there. (Paranoia again, sorry.)
  9. Now make a change to your and look for the little M to the right of the file name in the Project Navigator pane to show up. Be patient. If it’s not showing go back the the Organizer Window, back to your Project folder (by selecting its name on the left), and click the Commit button. The little M should now and forever show up next to your modified files in the Project Navigator.

I’m still having a little problem committing from the context menu in the Project Navigator but I can commit just fine from the Organizer Window. Maybe that’s just how Subversion works with Xcode or more maybe I have to be even more patient. I’ll let you know!