BEN:
Ludicrous speed! Speaking of ludicrous speed, I introduced my boys to Spaceballs, and they laughed at that scene. And then later on, my son made a comment he's like "Yeah, that's funny! But Ludacris doesn't really rap that fast."
CHUCK:
Oh, geez! Yeah, I would have cried. [Laughter]
CHUCK:
Hey everybody and welcome to Episode 5 of iPhreaks! This week on our panel we have, Ben Scheirman.
BEN:
Hello from Houston!
CHUCK:
Pete Hodgson.
PETE:
Buenos dias!
CHUCK:
Rod Schmidt.
ROD:
Hello from Salt Lake City!
CHUCK:
I'm Charles Max Wood from DevChat.tv. This week, we're going to be talking about "Xcode" and just tips and tricks.
BEN:
Xcode, everybody's favorite IDE, right?
CHUCK:
Yeah.
PETE:
We can call it the 'Stockholm Syndrome Episode'.
CHUCK:
[Laughs] Oh, maybe we should get into that first. I mean what are the issues with Xcode? [Pete chuckles]
BEN:
It looks great!
CHUCK:
It has a tab completion stuff in it.
BEN:
Yeah. I think when Xcode works well, I like it a lot. But unfortunately, it's a little bit finicky. It's gotten a whole lot better, but unfortunately, the pace in which it improves is not quite what I would prefer. One of the things that I used to struggle with a long time ago is syntax highlighting a code completion for libraries that you pull in, like the indexing of your code would get screwed up. You could tell that this was happening because the syntax highlighting would just stop coloring your methods, and so you'd be like "Oh! What's happening?" Eventually, they fixed those bugs. I sort of forgot about this issue and it recently cropped up again in one of my projects, and I have no idea what the issue is. It's usually self-combination of digging into the header search path to make sure that that is pointing to it's supposed to be, and some other things like that. But yeah, just when it works, it's pretty good; and when it breaks down, which happens a little bit too often, you tend to after resort to finding your drive data folder and deleting it, which happen so often in the past few years that people have resorted to either writing a script that will delete your drive data directory in one go. [Chuckles]
CHUCK:
[Laughs] That's awesome!
BEN:
And there's even an Xcode plugin that will put a little button in your toolbar to delete it. [Chuck laughs]
BEN:
So, having a button in your toolbar to delete and indexing folder is kind of a sign that Xcode, perhaps, should be a little bit more stable.
CHUCK:
Well, you would think that it would be, considering how many people out there write applications in it for iOS or Mac OS.
BEN:
And, Apple uses it themselves!
PETE:
I wonder how many people, like there's definitely a lot of people using it, I wonder how many people of Apple actually work on Xcode full-time. And you can kind of get the same script from going to the labs, but I don't think it's that many.
ROD:
Nah! I think all their teams are pretty small.
PETE:
Yeah, that's true I guess.
CHUCK:
So, it's Visual Studio for the Mac, is that what you're saying?
BEN:
I think Visual Studio gets a better app, but I actually like Visual Studio. The plugin system in Visual Studio is superior to Xcode. And so you cannot plugin so like ReSharper, or some of the other ones. I was a big ReSharper fan. And so when I came to Xcode, I was like "You know what? There are..." like these some of the refactoring tools that are built-in Xcode with, are horrible. They're so bad that like I'm surprised that anybody ever even goes to that menu and uses them. And every time I reach for that menu and say "You know what, I should do refactor method here", I regret it almost every time I do it because it just takes longer than it would take for me to copy and paste and write the new method. And also, like I was recently showing this to somebody, I did a refactor method, and it got the parameters wrong. I understood why it got the parameter's wrong, but there was nothing I could do about it. Like basically, it takes the context of what you've selected and says what variables do I need declared for what variables do I depend on at this selection scope, and so I need to pass those in. And what variables that I have inside of your 'use later' in this method scope, and those need to be return values. And occasionally, it gets a little bit confused, so I can understand that. But once I do this selection and refactor method, it takes me into a brand new window, which takes a while to show me a dif of what it's going to do. And then it also asked me phone enable snapshots. And of course I use git, so why would I ever want this feature? [Laughter]
BEN:
So I say, "No, I don't want snapshots ever", and so then it takes a second to record that setting. And then I clicked finish and then it takes a really long time like seconds to complete this operation, which should be lightning fast. And then for whatever reason, it scrolls my current focus to the bottom of the file so I have no idea where on the file I am anymore. That's just refactor method; it's like the easiest for refactoring on the planet. So when you're faced with Xcode and sort of having really really horrible refactorings and you look at something like ReSharper, which is basically built around refactorings, it sort of leaves a lot of room for improvement. And so yeah, I wish Xcode's plugin system was a little bit more robust so we could have things like that.
PETE:
Yeah. Or, the alternative is I wish that Xcode could be teased apart a little bit so that Interface Builder was a separate thing, and then you could use a different IDE, but still use Interface Builder.
CHUCK:
Didn't it used to be a separate thing?
PETE:
It did, right? Yeah.
ROD:
Yes. [Crosstalk]
CHUCK:
Because I remember, when I first started using it --
BEN:
I don't necessarily mind it being part of this app because you get the Ctrl+drag into the Assistant Editor; it's pretty handy if you're on a big monitor.
PETE:
It will give you the option there... Just because I've tried a few times to get into using AppCode rather than Xcode, and the thing that always happens with me is I'll be using AppCode and actually using refactoring tools and having a grand old time. And then, I need to modify a nib so I'll go and double-click on the AppCode and it'll pop-open an Xcode because that's the only way that you can do that. And then I'll like go back to where this in the file, and then like 5 minutes later, I'm like "Oh! I'm back in Xcode again by accident!" because I just kind of automatically just stop get an Xcode. [chuckles] And it just happens to me over and over again and I keep on like not breaking that habit; Xcode is a bad habit I want to break.
BEN:
I filed a bug with AppCode, I really liked it. However, it was a little bit too much friction for me to switch to.
PETE:
Yeah.
BEN:
But, I felt right at home with the ReSharper key bindings and like the possibilities. One of the things I think is really, like let's say I want to, say (I don't know), tableView.delegate = self, and then it says "Hey, do you want to make this class conform to the UITableViewDelegate protocol?" and you just hit Alt+enter, and it will do it for you. It doesn't take you anywhere away from where you are right now, it just makes the change. And then later on, I say something like (oh, I don't know), something in a different framework like AVAudioPlayer, and it's like "Hey, would you like to import this framework and include the header at the top?" and you're like "Yes, please", and it'll just do it for you. It's 2013; I don't understand why Xcode doesn't help us with these things.
PETE:
Right. I think that's the thing as well. I think for a lot of kind of people there who have been using Xcode for a while and haven't come in from a different technology or coming from a more dynamic language like Ruby or JavaScript, or whatever, I don't realize like how powerful an IDE can be when it has all of the information at hand. An Objective C is static enough, but it knows what you're trying to do; it can do a lot crazy or tend to stuff the people laugh from IntelliJ and have ReSharper a lot. So, I don't know, I think it's kind of a shame that AppCode hasn't take enough more than just being a little kind of curiosity. That's what it seems like to me; it's kind of not that many people are using it full-time.
BEN:
I filed a bug with them and asked if, at any point in time, would do they have plans to make it an Xcode plugin. The response was kind of, it will undirect, but it was like "AppCode is built on years and years of foundation and work done by IntelliJ and ReSharper that's written in Java", so likely not be an Xcode plugin. That said, the Xcode plugin system, from what I understand, is super basic. In order to do something, like for instance, I use XVim, which gives me Vim key bindings, and Xcode, which is okay, I like running with it (I'd rather run with it than without it), but it'll get some corks and it has to draw little command window at the bottom of your code surface, like Vim does. So when you hit like :w to write a file, it has to show you what you're typing. And, I looked at the source code to see how they actually did that, and it's really nasty. It dives into Xcode subviews and finds the one it's looking for, that is a code surface, and resizes it and applies its own View on top of it. That's probably going to break at some point, and somebody's connected going in, and fix it. As far as I know, there's no easy way to hook into the AST of Xcode of like the source that you're writing. So, I don't know how easy it would be to get your own refactoring tool like Xcode plugin.
PETE:
I think like I remember hearing some of the crazy stuff that people used to do with Visual Studio to get things like ReSharper to do its thing. And I think, Visual Studio as an example, has kind of really opened up since then. But initially, they were doing all sort of crazy hacks, and they still do. Like actually, I was just listening to a podcast about a guy that does a Vim plugin for Visual Studio, and he was kind of describing similar hacks that he has to do in order to get the command thing to show up his stuff --
BEN:
I wonder if just the Visual Studio's popularity is what made it possible for them to do ReSharper and other things on Visual Studio, I don't know. I'm really looking forward to richer plugin ecosystem for Xcode.
PETE:
Yeah.
CHUCK:
So, I kind of want to get in to some of the tips and tricks. We talked about some of the problems with Xcode, what are some of the things that you guys do that make it easier for you to deal with Xcode? Or, some of the things that you like, some of the common things you do with Xcode?
BEN:
Let's say I definitely learned the keyboard shortcuts because there's a whole lot of them, and they're pretty well thought out, so they build on each other. So for instance, _+0 will expand or collapse the left-hand Navigator. And if you add ALT to that, so _+ALT+0, it will do the right side. So basically, when you add ALT to any command, it generally works on the other editor, either the Assistant Editor or the Inspectors on the right-hand side. So you could do a whole lot of things just by using your keyboard; you can navigate around. Another one I like is, CTRL+6 will open up a little pop-up window that shows you all of the methods in your class you're working on, and you can just start typing to autocomplete those methods. If you want to go straight to a method, you can do that. And I guess it would be pretty boring to list out every keyboard shortcut I ever use, but I would just say, take the time and learn it. When you're faced with something that you know is possible with the keyboard shortcut but you don't know what it is, go research it and then do it a few times to sort of commit it to muscle memory. Eventually, those things take over and you're on autopilot.
PETE:
For me, my favorite one is _+SHIFT+O like to open quickly. So if you want to go to a different class, you just hit _+SHIFT+O and just start typing. So it's kind of like _+T in sublime, I guess. Is it _+SHIFT+O? Is that right?
ROD:
Yes.
PETE:
So what, this is doing keyboard shortcuts?
[Ben laughs]
PETE:
It's like muscle memory so much that I actually have to press the keys to find out what the keys are.
CHUCK:
Is there a good list of keyboard shortcuts out there that people can reference? Because I've just been Googling for the last minute or two, and the most recent one I can find is still from like March of 2011.
PETE:
I'm sure it's still up to date.
BEN:
Yeah, that's still up to date. Another thing you can do is, if you're looking -- like I'm in Xcode right now, and I click on the Navigate Menu -- and you see all of the keyboard shortcuts for these various menu items, and then if you hold Option while you're looking at the menu, it changes the menu items to reflect what would happen if you push Option and clicked on the same shortcut. So for instance, 'go back', like go back to the previous file you're on, is CTRL+_+Left Arrow. And if you add Option to that, so it's the 3 keys to the left of the spacebar, if you hold Option to that, it’d say "Go back in Assistant Editor". So if you have both editors open, the Standard Editor and the Assistant Editor, you can go back in either one of them depending on whether or not you hold Option. [Crosstalk]
BEN:
The only way I knew that you could do that is by looking in the menu and holding down Option to see the additional keyboard shortcuts.
PETE:
I never knew that if you're in the menu and you hit the modify key, it actually shows you a different set of things. TIL!
BEN:
Yup!
CHUCK:
Does that work in all of the different --
BEN:
I only use those in Xcode, but I wouldn't be surprised.
CHUCK:
Oh, wow!
BEN:
I know other things work in Mac like if you hold on Option and click on like your WiFi thing in the menu bar, you'll get like additional details about like what channel your WiFi network is on, and things like that. And I think you have this similar thing for volume; you can switch devices that way. There's a few different ways you can sort of get advanced info by just holding out the Option and clicking on things in your menu bar.
CHUCK:
I'm in Chrome and doing that and it's showing me different menu options when I hit Option and when I --
BEN:
That's really cool!
PETE:
I was going to ask the same thing. Now that I think about it that makes sense. Because I remember, back in my one OS X development thing, when you're creating the menu, you just kind of define all of the modifiers and what they do. And then, the framework takes care of actually building the menu and all that stuff. It makes sense that it would just hook up the last stuff of [inaudible] whatever, NSMenu bar, or whatever it's called.
BEN:
Another thing you can do is assign your own keyboard shortcuts in Xcode. So, if you hit _, in any Mac app, it will open up Preferences. And then you go over to the key bindings tab, and it will show you everything that's there and you can search. And then if there are things that don't have an entry, you can add your own keyboard shortcut to that, provided you can find a free one. One of the ones that I find that I need a lot is, if I'm looking at a storyboard or a nib on a laptop monitor, usually I'm running this full screen and I've got the Navigator open on the left and the Inspector Pane on the right, and the Designer surface. And there's an additional pane -- I don't know what you call this one, but it contains all of your Interface Builder objects, so your ViewControllers and all the Views, it's just a hierarchical view of the Visual Designer, and you can collapse that by clicking on this little button on the lower left-hand corner of the design surface. And that button is, you can assign a keyboard shortcut to collapsing that list, but it's not there by default. So, you just have to find something that is some contorted twist of fingers that will not conflict with another command.
CHUCK:
What do you use?
BEN:
I haven't figured out a good one for this one yet, but I've been thinking about it.
CHUCK:
Oh, okay. Interesting.
ROD:
I think that a lot of people don't know is, the key bindings are, a lot of them, are matched at Emacs code bindings. In fact, that goes out through the entire OS. So, if you're familiar with Emacs, CTRL+A , CTRL+E work; I use CTRL+D all the time. In remap your CAPSLOCK key to CTRL, it makes a lot easier to do those Emacs shortcuts.
CHUCK:
Yeah, that's what I've done, and I've seen the same thing. It also holds through for most shell prompts.
ROD:
Right.
CHUCK:
It's pretty interesting how pervasive the Emacs key commands are. And some of them, you'll find the CTRL whatever works, and in some cases, they've modify it to _ so it's _ something, will do something similar. So, it just depends on which program you're in and how far they've taken that.
So, are there any other tricks, any other things that make your life easier in Xcode?
BEN:
If you highlight some code, a lot of times, since the indentation in Xcode is a little bit more complicated than what it would be in other languages, because typically with a long method call, you will hit line breaks between each parameter and then line up the colons, if you just select any amount of code and hit CTRL+I, it will re-indent that selection --
CHUCK:
Including lining up the colons?
BEN:
Yup! And that works pretty darn well for blocks and long method calls or whatever. The only case where I really despise Xcode's indentation is on the collection literals, like a dictionary. Where, instead of typing like NSDictionary dictionaryWithObjectsAndKeys, you pass in @{ } and you define them similar to how you define a Ruby hash; so there @{ } and then you have key : value , key : value. The way it does the indentation for these things, it makes no sense at all.
PETE:
Yeah.
ROD:
Yeah.
PETE:
[Chuckles] I have no idea what they were thinking.
BEN:
[Laughs] And they actually need to file a radar on that. And that brings me to something that I think everybody should run on their machine, an app called "QuickRadar"; I think it's ¢99 in the Mac App Store. But basically, it allows you to quickly file a radar, which is a bug. This is the only way or your best way of getting some of these gripes or pain points to somebody who works on the team. If you talk to any of the developer evangelists, they'll tell you "Stop complaining on Twitter, file a radar first, and tell everybody about it so they can file their own radars if they agree". If hundred thousand people filed the same radar, then it can be pretty certain that Apple is going to pay attention to it, at least respond to it. If they may say, "Oh, this is by design. We're not going to fix this", or whatever, at least they're hearing the feedback. And if they hear it enough, then they might say "Hey, you know what? This would be easy to fix. Let's just go ahead and fix it". So filing a radar, unfortunately, requires you to get in the time machine and go back to like 1997 and use this really awful web interface. [Chuck laughs]
BEN:
I think it only works in Safari; sometimes I have issues in Chrome. Anyway, it's a pain. So what quick radar does is it gives you a little Mac app and it lets you fill in all the fields that you would normally fill on the website and has check boxes to send these to Twitter, APP.NET. Send it to Open Radar, which is a open source clone of Radar; it's public and allows people to post radars that they've filed so that other people can easily dube them. If you do that, you can just post issue once, it'll post it to all 4 places; I've done that Open Radar and Twitter. And then if anybody wants to dube it, they can in QuickRadar. So you file a duplicate type in the original radar number, and it will go fetch the details of that and fill it in for you. So that's a really good way of doing that. So, I'm going to file a radar on this indentation bug with collection literals.
CHUCK:
That's awesome.
ROD:
Another usual shortcut is CTRL+ _+Up will switch between your .h and .m file, I use that a lot.
CHUCK:
Hah!
PETE:
Yeah, those ones are the ones that you get so used to it that you kind of forget that people don't know about it.
BEN:
Yeah. Another common thing that you could use to get around some of the sort of simplistic code completion you give with Xcode is 'Snippets', and the Snippets are actually pretty good. If you have a block of code, let's say something like getting a documents directory, which once you've typed it a dozen times, you'll remember what it is, but nobody remembers or thinks for the first time "Oh, I'm going to type NSSearchPathForDirectoriesInDomains and pass in NSUserDomainMask and NSDocumentDirectory", I mean nobody remembers that. And so, I have a Snippet that I just typed docster, and it will paste in the two lines of code in order to get the documents directory. So once you've looked at the code and you've written it one time, you can just select that code and drag it over into the Code Snippet Library in the Inspector Pane, and then give it a name. I have a bunch of these things, like dispatching async with another dispatched async to get back on the main thread. I have one for marking a section. So when you do pragma mark in a file, you can give it a name something like UITableViewDelegate Methods. And then in that CTRL+6 method pop-up menu, you'll actually see those names along with the divided section, so it's a nice way to keep things tidy instead of your class. But typing #pragma mark - , you do this in basically every file you write. So I have a snippet :mark that does that for me, and it's just a quick expansion of that. I'm trying to think of other ones that I use...You can do substitution so like you can tab across tokens in the snippet. So if you need to fill out a few things, like for instance if you want to do like a snippet for a property, you could say prop TAB, and then have it fill in the modifier, the strong or weak, or whatever, and the type. So you could do basically whatever you want to make your workflow a little bit faster.
PETE:
Is that the same mechanism as the alloc and init thing, where you just type in alloc and hit TAB and it kind of gives you generic --
BEN:
Yeah, exactly the same thing. You can tell that you're hitting a snippet when -- well, alloc doesn't actually do it; that's not a built-in one. I'm trying to think of what are built-in one...let me go to one...So when you define one of these, there's one that coordinate a fetch with a predicate, and some of these don't have completion shortcuts, you just have to drag them from the Code Snippet Library over. But if you give one of these a snippet, so here's one that I've done stringWithFormat, and that one is SWF, and so I use that all the time. So then I type SWF, and Xcode shows me that completion, like the IntelliSense and the icon next to it looks like the code snippet curly braces. And so that's how you know you're about to expand a snippet.
CHUCK:
So, is expanding a snippet kind of like TextExpander for the rest of your Mac?
BEN:
Yeah, it's very much like that, except -- I'm sure TextExpander supports this, I mean I use it. But being able to define the tokens, so like when I do stringWithFormat, there's two things I need to fill in: the string itself and the parameters that I want to substitute in the string. So those are two tokens. And so I hit SWF+ENTER, and then it puts the focus on the string portion, and I just type my string and hit TAB to go to the next one, and they just start typing my parameters. So I'm not sure if TextExpander does that.
PETE:
Is there an easy way to import and export these things? If I remember correctly, you have to like copy and paste some magical files --
BEN:
[Chuckles] No, there's no easy way to do that. I looked at a way of sharing this between machines, because you can like install them easily, but as not easy to just like semi-link a folder.
PETE:
Yeah.
BEN:
So, there's probably room for some open source library out there for you to say "I want that snippet. Let me just type a command", kind of like a CocoaPod thing for your Xcode assistant manager.
PETE:
Assistant Manager?
BEN:
Yeah.
PETE:
I think it's the same with, you can kind of I guess one level-up from snippets, is like the File Templates. So when you hit like File New (or, I guess _+U, whatever) to make new file, you could actually make it. So set as like CocoaTouch, you want to make Objective C class, Objective C cache field, stuff you can customize those and [inaudible] once. So if you're using Kiwi for testing, you can add one for Kiwi, that kind of thing. But again, to actually do that, you have to kind of go splunking around in some crazy folder inside of your system in order to put that stuff together.
CHUCK:
Now, if you wanted to, could you build these snippets or file templates into a plugin?
BEN:
I don't think that plugins will work by installing other files, but I think that there's -- I mean we're like
a shell script away from downloading and reusing snippets; I don't think it's that hard of a problem to solve, I just don't think anybody's ever done it. I know that some people have posted their snippets online, but that ends being sort of a manual approach. The snippets that you define yourself should have a name, like the descriptive. But then when you install it, it copies it into a specific folder with like a unique identifier as the name, so there's some separation there.
PETE:
I was just Googling around and I saw that the inimitable Lukeredpath, who is like the most prodigious (well, is that the right word? I don't know), prolific open source guy I know in iOS and Ruby has a gem called "xcodesnippets".
BEN:
Oh, yes! I actually use this, I totally forgot about this. [Laughter]
BEN:
I will probably remember as soon as you stop recording, but there is a reason why this is only kind of half the battle. But it's super useful. So if you download a snippet, or if you want to backup your snippets and use them on other machine, this is a good tool to do it with.
PETE:
It'd be cool to integrate this with GitHub in the same way as, I guess CocoaPods and stuff does them, so you could just say like "snippetinstall[githubusername]/github".
CHUCK:
Oh, yeah, that would be cool.
BEN:
Yeah.
PETE:
Oh, he hasn't done it [inaudible] 2 years, or maybe I should send them a pull request.
BEN:
Sounds like you just volunteered. [Laughter]
PETE:
We can edit that out, right?
CHUCK:
[Laughs] Yeah, well, if you don't, maybe one of our listeners will.
PETE:
Yeah! That would be even more exciting! This is enough [inaudible] for some lucky listener to tip or tell us into the wonderful world of open source.
CHUCK:
Awesome! So, any other tips, tricks, ideas?
ROD:
There's one that trips up everyone; when you bring in a third-party library or something that doesn't support ARC, you need to go into your build faces or compile those and set the compile options for those files. At first glance, it seems like you have to go and select each one at a time and put in -f no-op C ARC, but you can actually select all of them at one time, and then hit enter. A little field will pop-up, and then you can type it in once and hit enter again, and it'll set it for all of them at once.
PETE:
Yes, another thing that's not really tips and tricks thing, but just a general kind of thing that's worth doing is spending a little bit of time and trying to grok like target, schemes, workspaces, projects, or like the bizarre (well, not bizarre) the rich domain model of Xcode. [Laughter]
BEN:
I will tell you, I turned around on that one.
PETE:
[Chuckles] Yeah. I still don't get it. I've spent more time than I think a lot of people trying to figure this stuff out because I have this open source tool that integrates with Xcode projects, so I've been trying to figure out why to do that in a painless way. It is very sophisticated in some ways. It's also a very confusing; there's a lot of words that all kind of sound like they're the same thing like project, target, scheme, workspace. All those things are conflict as well, that's another one. Basically, any kind of generic word that you can think of within there somewhere.
BEN:
There's a good [inaudible] session from last year, if you go take a look at the videos. I think it has like understanding Xcode targets, workspaces, and schemes, or something like that.
PETE:
Yeah. And once you do kind of get your head around it, it is pretty pathly; you can do some pretty clever stuff with it if you need to in terms of building different things for different versions of the OS, and stuff like that. That's also very useful to understand, that stuff, if you want to build from the command line. At some point, you're going to butt up against it probably.
BEN:
One thing I do a lot is, if you hold down Option and highlight over a symbol and click on it, it would tell you what header that's define in and give you description of that symbol; and that will work for anything that has documentation including like "F", it should to be request AFNetworking, for instance. But like all the built-in types, like NSMutableArray, it'll tell you a quick summary and give you a link to data file and the class reference documentation. And then if you hold down _ and click on it, it will take you straight to that header file. Sometimes, that's super useful because the headers contain valuable comments, like perhaps engineering comments, that aren't in the darks. So if you hit _+Option and click on a symbol, it will open up the header in the Assistant Editor, so it doesn't take you away from where you are, which is nice. And so then, your focus is still in the lefthand pane. And once you're done referring to that window, you can just hit _+Enter to close the Assistant Editor and go back to the Standard Editor. So I use that a lot to just refer to things without losing my place of where I was.
PETE:
And that's super handy. Sometimes even, if I just want to see like what the types are of a method,
I'll just open up the header just because it's sometimes quicker than actually opening up a doc then waiting for the docs.
BEN:
If you're using a CoreData, there's some interesting flag you can set. You need to go to the scheme editor, which is there's a little selected that has your app aim and what devices it's wearing on, and you can go to edit scheme from there. Shorter way to that is to hold Option and click on the Run button, but that is very non-intuitive; Option+Run will actually edit the active scheme. And then you go to Action and then on the Arguments Tab, there's a thing that says “Arguments Passed on Launch", and you can pass in -com.apple.CoreData.SQLDebug 1, and I will paste this in our window so we can add this to the show notes. What that will do is log all of the SQL statements that are sent by CoreData, because otherwise, you're not going to see these. And those can be super enlightening for you to realize that "Hey, nothing has been saved at all, and I had no idea".
CHUCK: [Laughs] Now, if I remember right, CoreData is just a wrap around SQLite?
BEN:
No, it's actually...it's all hand-wavy, there is no database. [Laughter]
CHUCK:
Here is no spoon.
BEN:
It's not an ORM, that's another way to put it. It's more of an object model manager --
ROD:
Object graph...
BEN:
Yeah, that's a good way to put it. It's an Object Graph Manager, and those graphs can be persisted to disc or wherever. Most of the time, on iOS in fact, everybody uses SQLite as the underlying store, but you don't have access to database C things like batch operations, or whatever; it's very much its own interface into persisted or managed objects. That said, it is pretty powerful; we could certainly should do a show on it.
CHUCK:
Yeah, definitely. We will put that in the list; probably cover it within the next few weeks.
PETE:
Do any of you guys use the tabs in Xcode?
BEN:
I hate the Xcode tab behavior. [Crosstalk]
BEN:
In every other editor, pretty much, like for instance Sublime or TextMate, you hit command+T and it, let's say you complete a file, and then you hit Enter and it opens up a new tab with that file. And if you close that tab, then it's gone; but then, you go back to the file you're at before. In Xcode, if you hit command+SHIFT+O to open quickly and open a file, it replaces the code that you're looking at with this new file; and to get back to it, you have to hit CTRL+command+Left Arrow. So if you hit command+T to open up a new tab, it opens up the same exact file on the new tab, which is just not super helpful... [Chuck laughs]
BEN:
And I think, the way that tabs are supposed to be using that code are not how most people think of tabs. So typically, you'll have a tab that is your active code that you're working on, and then you might have another tab for like Interface Builder. And so, you can do things like, let's say I have a tab, I can actually rename it. So if you double click on the file name in the tab, I can say "I want this to be my Designer tab", which is going to have my storyboard in it. And in the storyboard, I want to make sure that I have the Assistant (I keep calling it the Assistant Editor), the right-hand pane, what is that thing called? The Inspectors.
ROD:
Inspector.
BEN:
Alright. So I want to have the Inspectors open, I want to have the Navigator open, and I want to have my debug window at the bottom closed, and that is going to be my Designer tab; and so then, I can just always have that tab ready to go with that configuration. And when I go back to my code tab, perhaps, the Inspector Pane is already closed for me because I don't really need that in code; it's useless. And then I may have a third tab that is my debugging tab. And if you go into Xcode's Preferences and you go to the behaviors tab in Preferences, you can generate all kinds of rules for "Hey, when I start running, I want to switch over to the debug tab". My head doesn't really worked this way. I've seen multiple presentations where people demonstrate this behavior and I just...it's not something I use.
PETE:
It kind of reminds me of, I think in Eclipse, I had this thing called "Perspective", or something like that.
ROD:
Yeah.
PETE:
Basically, it's like different modes that you're in. So I'm in debug mode, I'm in...basically what you're saying, but it is not something that I think anyone would associate with tabs. I think the thing that froze me off is or that free me off is like "That's not a tab; that's a totally different mode that I'm working in. It just happens to be that I accessed it by hitting the little tab thing". Or, most of the time, actually if you're like a super power user, you just automatically go into it, like you're saying, like when you start debugging [inaudible], or when you start running.
CHUCK:
Alright, well, this has been really interesting for me. Because like I said, I'm not super familiar yet with Xcode, and so a lot of these things are things that I've not quite run into yet. So really quickly, do you have tips for folks who are just kind of getting started and getting familiar with Xcode? I mean you said learn all the shortcuts or as many as you can, things like that.
ROD:
I think there's a good Pragmatic Programmers' Video that they put out; a screencast that shows all the shortcuts and goes over them.
CHUCK:
Okay, I'll see if I can find the link to that. Any other ideas?
BEN:
I have one more tip that I use quite a bit. Oftentimes, you can click where the line numbers are; you can click there to set a breakpoint; and that when you run, the breakpoint will be hit. But sometimes, if you're running in something like a self or row in Expat method, which is going to be called perhaps like 20 times in order to render the screen, you may just want to see how many times does this code being hit without having to sort of stop there every time I hit run again, and stop there and hit run. A lot of times, I will click on it and I will right-click or two-finger tap on the breakpoint itself and say "Edit breakpoint". Once you're editing that breakpoint, you can add actions to it so you can have it savings or play a sound. And so I'll just say "Play a sound", and you pick one of the sounds, and then you check the box "Automatically continue after evaluating". So it means it won't actually stop on this breakpoint; it's just going to play a sound. One of the areas where I've used this before is, I wanted to know every time my CoreData manage object contexts saved. And so I set a breakpoint in the method where I call save, then I set all these settings to enable the sounds, and then run the application player around with it. And then every time I hear the 'ding', I know it's saving. So it's a really cool trick. You can do all kinds of things like that. One other things that we were debugging recently was a TableView bug, where the number of rows in section was not what we expected it to be, but it happened really quickly. And if I stopped on the breakpoint to inspect the problem, the problem went away because it was a race condition. And so I had the breakpoint say a number of rows; so in the number of rows in section method, I assign the number of rows that I'm about to return to a variable, set a breakpoint to say that variable, like using the Mac say command. So actually it would say "Six", "Seven", then I just run my application.
And then it would not stop at the breakpoint, it would just speak the results.
PETE:
That is one power feature of Xcode; I make fun of it a lot, but it is pretty amazing that you can do that. I don't think I've seen that in any other IDE, that you can have it talk to you about the variables in your [inaudible].
BEN:
Another tip I would suggest is on the Navigator Pane, on the left, there's a breakpoint inspector. It is the 6th-1, so command+6 will actually show it right away. So even if it's closed, you can hit command+6 and go straight to breakpoints. And at the bottom, there is a '+' to add a new breakpoint and you can add an exception breakpoint here, and I would just add this in all your projects, and then right-click on it, and say "Share breakpoint". And what that'll do is it'll add it to the Xcode project file instead of your user data file. Your user data file, you typically won't check in the source control because that contains like your tab structure and other ways that you work but your co-workers might work in different way, but you definitely want to share things like this all exception breakpoint. What this will do for you is -- oftentimes on a fresh project with the new developer running Objective C for the first time and they call a method that doesn't exist or they release an object and it crashes, a lot of times it would just crash in the main method and it won't give you any detail with what happened. If you have this exception breakpoint, it will halt the execution of the program at the spot of the error, so it goes straight to the line that cause the problem. And the only time I ever turn this off is if I'm working with -- sometimes AV Foundation will throw exceptions as part of its normal control flow, and CoreData has been known to do the same thing occasionally -- so sometimes I will disable the spike clicking under the blue tag arrow thing to disable it temporarily. But generally, I run with that all in every project.
CHUCK:
Cool. So you taught us about musical breakpoints, have you ever forgotten to turn that kind of thing off and have it talk to people?
BEN:
[Chuckles] I mean it'd fully happening when I'm debugging in Xcode...
CHUCK:
Oh, okay.
BEN:
So it's not something that comes from the iPhone; it comes from your Mac.
CHUCK:
Oh, I see. Oh, because this is in the breakpoint?
BEN:
Yeah.
CHUCK:
Okay.
BEN:
Since we're talking about these sort of debugging tools in the simulator, if you run an application, you go to the simulator, you've checked the menus out there, some debug menus, and some of them will simulate a memory warning, which is super important for you to test. Others will color offscreen rendered images, which going to impact the performance of your own drawing. And then Color Blended Layers is really important one to look for. Blended layers are, where you have a transparent object on top of another object like rounded corners or some way of having this happen where in order for the underlying OpenGL graphics hardware to render this thing on to the screen, it's got to create a texture, which is a rectangle, and it's got to fill in all the pixels in that rectangle. And if your button has rounded corners on, it's got to composite that with whatever's underneath it in order to do around their corners, and the process of compositing is really slow. On iPhone 5, this has become less of an issue, but in order to get 60 frames a second when you're scrolling, it's important to just squeeze out every bit of graphics performance you can. So, knowing when you're accidentally using transparency is a huge thing. And by turning on Colored Blended Layers in the simulator, it will color everything on the screen red or green, depending on if it's being composited or blended with the layer behind it. Some of those things are completely fixable by just turning on opaque fuse or redesigning a cell, or whatever, so that you can minimize that level of blending.
PETE:
The other one that's up there as well is the Misaligned Images of [inaudible] code. That's really helpful if it looks like stuff is blurry; that's when you're rendering across pixels. So, you're basically asking the iPhone to like render a box at like from 0-point, 2-points, to 5-points, 7-points, then it's going to do [inaudible] this thing or whatever the right word for that -- I guess it's going to be blending to render, and it just makes things look blurry, and then that will just highlight when you're doing that to help you figure out why things are blurry.
BEN:
It's a good way to drive your users completely nuts. [Chuck laughs]
PETE:
Or, drive your developer completely nuts if they don't know why it's happening.
BEN:
[chuckles] Yeah. [Chuck laughs]
PETE:
When I first doing iOS development, I swear that one of the guys that was testing my app was crazy because he was like "It looks really blurry!" I'm like "It's not blurry, it's pixels!" [chuckles] And he was right, and I was wrong.
BEN:
Yeah, you also have to be careful when you're setting like a frame of an elephant -- an elephant, what's wrong with me? [Laughter]
BEN:
When you're setting the frame of an element, you can set the frame or you can set the center point, and the size. If you set the center point to something, and that thing has uneven width or height, then the frame can end up being on a half-pixel boundary. And the only way that it can do that with physical pixels is to take a look at the colors on neither side of it, and then blend them for the edge that doesn't line up on a pixel boundary. And so we call those half-pixels, and that's what causes it to look blurry.
PETE:
So, I guess it's pretty not true on [inaudible] because retina has got two physical pixels width 1 point.
BEN:
Right. So sometimes, you definitely have to look at it on the retina and on non-retina device. And you can do the same in the simulator; it should look appropriate because they're scaled. So, a retina iPad does not fit on my MacBook Pro screen. But, it's good to test these things so you can actually take a look and see if it's lying up or not.
PETE:
Speaking of things not fitting on screens, this is kind of embarrassing a little bit, but I do all my development on an 11" MacBook Air, and pretty much nothing fits on that screen. When you're running stuff on the simulator, command 1, 2, and 3 will resize the simulator, scale up or down, so that's really really helpful when you need to see the whole thing scaled down, or when you want to see just a bit in real size in public or size; I think it's command 1 2 3.
CHUCK:
Yup. Alright, we need to get into the picks. I am sorry to cut this off, but I have to wrap this up in time to get lunch and then do another podcast. So, I'm going to make Rod go first this week.
ROD:
Alright! First off, I'm going to pick a project that I think was announced this week; it's called "Alcatraz". It is a Xcode package manager, so it helps you manage all the Xcode plugins that are out there and install them, and whatever. So, it looks pretty interesting. I don't have a chance to try it yet, but I've thought I would pick it since it goes in line with the show.
BEN:
Have you been reading my pick list?
ROD:
No. [Chuck laughs]
ROD:
That's why I got to go first. Good thing. [Ben chuckles]
ROD:
And then I saw "Oblivion" this weekend, and I really enjoyed it. So, that's my second pick.
CHUCK:
Yeah, it was good movie. Ben, what are your picks?
BEN:
I was going to pick Alcatraz, but Rod picked me to it. I just recorded a screencast on that today, so that should be coming out on Thursday. And I also saw this cool product, it's a "Belkin Thunderbolt Dock", and I think I'm going to pick this thing up. Basically, it allows you to plug in one cable into your MacBook, a Thunderbolt cable, and then on the other end, you can put audio cables, USB, you have two Thunderbolt on that side, so you can plug in basically all of your cables for using your Mac at a workstation. It's a little pricey of $300, but I really hate the cable dance that I do basically everyday from work and home.
CHUCK:
So it's basically a docking station that plugs in the Thunderbolt?
BEN:
Yes. And then my last pick will be -- I use this thing, you guys talked about remapping Caps Lock to CTRL, I actually remapped Caps Lock key to this super key combo, and I will link to this, it's a blog post by Brett Terpstra. It's sort of this weird amalgamation of hacks, but basically there's this F1 through F whatever keys, there's an F15 key that is sort of unused by everybody on a full-sized keyboard. And so --
CHUCK:
[Chuckles] I was going to say, have you seen my keyboard? [Chuckles]
BEN:
[Chuckles] So the F15 key is sort of unused, and what I have is PCKeyboardHack, changing Caps Lock key to F15. And there's also another thing outlined in there, where it will remap CTRL, Option, Command, and Shift as modifiers, all four of those. And then at that point in time, whilst you're holding all four of those down, the whole keyboard is your playground for keyboard shortcuts. And so, what you do is enable better touch tool, which is another app; and in better touch tool, there's all kinds of things you can do. Right now, I have it as an application launcher primarily. So Finder right now is Caps Lock-F anywhere I am in Mac, like I hit Caps Lock-F to open up Finder, M for my male client, B for my browser, X for Xcode, E for Editor, T for Terminal; and that saves me from doing the command tab dance like a thousand times a day. So, I really like that. And I also have Caps Lock; to show desktop. And so I really liked this combo, so I will link to that as well.
CHUCK:
That's very cool! I've got mine mapped to CTRL as well. Pete, what are your picks?
PETE:
My first pick is the time duration “2 minutes", which is how like took WWDC to sell out this time around. [Laughter]
PETE:
I was actually just Googling trying to find out an exact number, I don't know if --
ROD:
I think I saw 70-seconds, somewhere.
PETE:
In that case, I revise my pick.
CHUCK:
Are you going this year? Or, maybe you guys are going to WWDC?
BEN:
I'll be going. I was lucky enough to get a ticket.
PETE:
I'm not going. I took it as a sign that, I knew that it was going to be crazy selling out so quickly because they pre-announced it, and I took it as a sign I should spend some time out in the outdoor. So, I already planned a backpacking trip for that week. So, I'm going to skip the WWDC Craziness, but I live in San Francisco, so I'll do all of the unofficial WWDC Craziness.
ROD:
And I'm not going, either.
CHUCK:
Awesome. I hesitated, I guess, for about 70 seconds too long. [Laughter]
PETE:
That's why I'm picking that time duration, whatever it is, just because I think it's actually pretty cool that it seems like this year end, because it's sold out so quickly, there's been like an interesting kind of alt thing cropping up around it, so there's at least two alternative conferences. And I kind of like that; I like the idea of it being more than just Apple. That's because I'm a contrarian type person. So, "70-seconds". And then my other pick is a book called "Refactoring to Patterns"; I just bought this book because we were talking about refactoring early on. So this is a pretty deep, pretty weighty tome that describes how you can kind of take existing code and use refactoring to move that code towards various different patterns. It's kind of an advanced book, but it's really really good; if you're into patterns and you're into refactoring, then it's a good book. And then on a less way too serious note, my third pick is a Tumblr called "Reasons My Son is Crying", which has been doing around a little bit now, so probably everyone has already seen it. But as someone with a young child of about the age that he just [inaudible] many cries and stuff, I think this is pretty hilarious.
CHUCK:
Awesome.
BEN:
Can I have a last minute pick?
CHUCK:
Go ahead!
BEN:
[Chuckles] Since you were talking about Tumblr, I was reminded of "Text from Xcode", this was timely for this episode.
PETE:
Oh yeah, that's perfect!
BEN:
It is pretty awesome. So this latest one says, it's like a conversation on an iPhone between you and Xcode, and you say "Put a breakpoint on line 343", and Xcode says "No". It says "Seriously, put on 343" [Laughs] "No". Anyway, it's funnier than me reading it to you, but check out that. [Chuck laughs]
PETE:
Yeah, the first time someone showed me that, I spent like the next half hour going through and finding reading all the old ones as well.
CHUCK:
Alright, so my picks this week are, basically I have two picks. I got really burned out after my last contract; I've picked up a couple of contracts since then, and things are getting better. I love to code, and I just couldn't bring myself to sit down and actually write any code, which totally suck for me. But one thing that I found that really helped was just having a whiteboard in my office. I actually went and just wrote down all the stuff that I had to do, because part of my burnout was overwhelm, and just kind of got my head around all of the stuff that I'm doing and what I need to get done for it. Anyway, I feel much better about it now. So my first pick is a "Whiteboard"; and I'll actually put a link to the "Poor Man's Whiteboard" that I have set up in my office because I didn't go buy a $150 office whiteboard. I went to Home Depot and I bought this (I forget what they call it) shower board or something. Anyway, I'll put a link to all that in the show notes. The other pick that I have is "StarCraft II", and that's the other way that I overcame my burnout, which just by checking out of reality for an hour or so at a time. And so when I'm really just not feeling like doing anything, what I do is I set a task for myself. So, we have the Ruby Rogues Parley list, for example, for Ruby Rogues, and I was like "Well, if I get through all 70 emails that I'm behind on (which was about a week's worth of email), and reply to the ones I want to reply to and be involved in the list the way I want to, then I can play a level on StarCraft”. And so I did that; I put in an hour's worth of work on a feature for one of my clients and then I'd go and I'd play StarCraft. It made both the coding and everything else that I was doing more enjoyable. So, I'll put links to that in the show notes as well.
Anyway, we'll go ahead and wrap up the show. Thanks for coming guys!
BEN:
Thanks!
PETE:
Thanks!
CHUCK:
We'll catch you all next week!