Tweets
What can be done with an iPhone? Mobile app workshop, during NOW festival. Coordinated by @invasivecode +info: http://tinyurl.com/ylrzuoa1 hour ago
New entry on the blog: XCode Tools Navigation. Tips on the keyboard usage on XCode http://bit.ly/akSHIV.1 day ago
What can be done with an iPhone?
The base to work will take place at the Raval quarter: the attendants will develop and application in order to position the musical extracts of the video clip course by means of Google Maps, so they can create an emotional tour around the quarter that can be visualized on the screen.
Thursday the 25th, Friday the 26th, Saturday the 27th, at 11 am. Hall
ATENTION: EACH PARTICIPANT MUST CARRY THEIR OWN LAPTOP WITH VIDEO EDITION SOFTWARE TO THE WORKSHOP
XCode Tip: Tools Navigation
The mouse is a fantastic tool to work and explore what an application can do for us, but as long as we are coders, most of our time we have our hands on the keyboard. Moving to get the mouse to change context and back to the keyboard is something that we can avoid in a lot of situations.
I love the keyboard, and I usually spend some time improving my knowledge about the shortcuts on the tools I use, in order to be able to work faster. I did this exercise with XCode some time ago and here I expose some of the shortcuts I use the most.
The XCode Editor is a big topic so I will cover it in another post, here I’ll focus on the navigability among some of the tools offered by XCode.
Configuration
I have configured XCode to have editor and debugger in the same window frame, this can be done on the General tab on the XCode preferences pane.
On setting this option, a selector will appear on the top left to select between the debugger window and the project/edit view.
To the debugger and back
On build and go (⌘ + ⏎) the debugger will be opened hiding the debugger editor. Once you are done with it you can go back to the project using ⌘ + 0. This shortcut will open the project/editor and the editor will get the focus, so you can edit right away.
The same ⌘ + 0 will take you to the project pane so you can select a file using the arrows. Here, if the file you want to open is visible (not disclose) you can also type directly the name of the file to open it. I miss here some of the Textmate powerful features to open resources. Three tabs (⇥) here will take you to the editor again.
Once on the editor, it may happen that the window is split in two. At the top you have a window for the build and find results (and others). At the bottom you have the code editor. Using ⇧ + ⌘ + E you make the editor using as much space as possible. If you hit it again you will go back to the previous state.
In any moment on the project/editor window you can use ⇧ + ⌘ + Y to go back to the debugger. In the debugger ⇧ + ⌘ + R will set the focus on the Console so you can type commands.
So, as can be seen, with for shortcuts you can move to the debugger and back and also go to the console and the editor. Only this, saves me lots of mouse.
Files on the editor
On the editor you need to move around the different files. A typical action is open the counter part (h or m) file. You can do this using ⌘ + ⌥ + ↑.
At the top of the editor window you have to small combo menus. One for the opened files and another for the symbols on the currently edited file.
You can open these with the keyboard using ⌃ + 1 and ⌃ + 2. These two shortcuts may collide with your spaces configuration so I have changed the shortcut to ⌃ + ⌥ + 1 and ⌃ + ⌥ + 2.
Finally, think that you can also go to preferences and change the shortcuts to something more suitable to you.
Debugger console tip
One of the great things of the apple tools is that they have their origins on the old GNU tools. I’m talking about the compiler (GCC) and the debugger (GDB) among others.
Everyone is familiar with the graphical debugger that comes with XCode, but not everyone is aware about its origins and capabilities. In this post I will comment some debuggers features that I found very useful.
If you open the OSX terminal (Terminal.app) and type GDB, you will end up with the version of the debugger and more information about this tool, for example, that its copyright is from the Free Software Foundation. This debugger is the one driving the graphical debugger in XCode.
Configuring the XCode debugger is is a matter of taste but I like to have an environment for coding and another different when debugging, so never use the same editor for both. What ever you do, make appear the debugger console (⇧-⌘-R). I like to have it open always so I set the “On Start: Show Console and Debugger” in the debugger Preferences of XCode.
As a tip, you can use “⌘-0” and “⌘-⇧-Y” to switch between the debugger and editor environments.
So, the debugger graphical interface is used to set breakpoints, control the execution and watch the stack and variables content. As I said before, we also have the console, but not everyone knows what to do with it. If you set a breakpoint in your code, when the code hit that spot, it will stop and show the debugger prompt in the console with the text “(gdb)”. There you can interact with the debugger. For example you can ask to print object with the command po, which will invoke the description method for the object:
1 2 3 4 | (gdb) po indexPath 2 indexes [0, 0] Current language: auto; currently objective-c |
You can as well ask for printing the information about the object pointer with the order print as p;
1 2 3 | (gdb) p indexPath $1 = (NSIndexPath *) 0x461bab0 |
In that case you have the data type of the pointer and the address of the pointed object. Using the start * you can the see the information of the pointed object:
1 2 3 4 5 6 7 8 9 10 11 | (gdb) p *indexPath $2 = { = { isa = 0x1ab5ec }, members of NSIndexPath: _indexes = 0x461ce90, _hash = 2147483647, _length = 2, _reserved = 0x0 } |
Another nice feature is that you can control the execution right from the debugger command line (no need for the mouse), use c for continue, s for step into and n for next, all of the follow by return. In case you want to finish the current method use fin.
Talking about the stack, you can use the command bt to show the stack trace and the command up and down to move up and down the stack.
But if you do not like the console work I can give you a funny debugging trick. Right click on a breakpoint when you are in the editor and hit Edit. Add an action, select log on the combo and speak on the bottom right side (see picture). On the text file add %H. With this option XCode will “tell” you (with voice) every hit on the break point, nice!!!
If you want more information search for Debugging with GDB in the Apple documentation and you will be thrilled about all the options.
