By now, you must have heard about the SAP Cloud Platform SDK for iOS, the result of the joint effort between Apple and SAP to bring together enterprise processes and native iOS features.
And starting August 29th, 2017, you can also join the online openSAP course, where you learn how to build your first mobile app with SAP Cloud Platform SDK for iOS.
To develop native iOS applications, you will use Apple’s Xcode, an IDE allowing you to design, code, build, run, debug and unit test your applications.
This blog will give a couple of tips which should make working with Xcode a bit more pleasant.
NB: The screenshots in this blog are from the Xcode project created by following the How-To tutorial “Build a geofencing app”
At first sight, Xcode looks pretty straightforward. There’s a navigator pane at the left, code area in the middle, inspector pane at the right, and a debugger with console output at the bottom.
You can toggle between different navigators or inspectors, but it seems there’s not much to customise here.
Enter tabs. By selecting File > New > Tab — or alternatively, press ⌘-T – you add a new tab, which allows you to customise content and allow for rapid switching between different files, the storyboard, or the debugger.
I personally create a new tab with the
Main.storyboard open at all times, and no navigator pane nor debugger panel:
And to be able to somehow read the long lines of console output, I create another tab with just the debugger console in fullscreen.
Doubleclicking the tab title lets you change the title to something meaningful, in this case, ‘Console‘:
This way, I can swiftly (pun intended) switch between my code, my storyboard and the console output spewed out by the running app.
You may have noticed that if you run an app and it hits a breakpoint, the file shown in the editor switches to where the breakpoint is triggered. Afterwards you need to navigate back to the file and/ or location you were working on. With Xcode, you can define a so-called behaviour, which lets you define what should happen in a certain event.
If you go to Xcode > Behaviors > Edit Behaviors… you see a list of predefined events. Locate the Running > Pauses event, this is the event triggered upon reaching a breakpoint.
Set it to Show a tab named Debugger, showing the Debug navigator panel with Variables and Console view:
The next time your running code reaches a breakpoint it will add a new tab with the debugger panel, and an editor pane where the breakpoint is reached:
And instead of switching back to the Project navigator in the left pane, opening the file and finding the location inside the file you were working on, you simply switch back to the first tab.
This alone increased my productivity in Xcode a lot!
There are many ways you can define behaviours, and you can even create new events. Possibilities are almost endless.
The debugger is quite powerful too. On the left it shows the variables view, and on the right it displays the console.
One of the neat things of the variables view is it allows for a Quick View of a selected variable by pressing the spacebar. And this isn’t limited to simple text or numbers: for instance, previewing an instance of
MKPinAnnotationView shows how it’s rendered, in this case with the custom Fiori color instead of the default red:
And previewing an instance of
CLLocationCoordinate2D gives you a map with the exact location for that coordinate:
This is one of the things that makes the debugger really stand out, making your life as a developer much easier!
The console is an equally powerful thing. It’s an LLDB debugger, part of the LLVM project. Apart from logging output of your application, there’s a whole set of commands that let you evaluate expressions (similar to the Chrome debugger console).
For instance, the command
prints the coordinates for that annotation:
But you could issue a command to set multiple breakpoints across different files at once, set watchpoints, modify variables at runtime, etc.
One very neat thing is you can issue a command which lets you output variable contents every time your code enters a certain method. This way, during development you don’t need to litter your code with debug statements, you simply output these temporarily.
For that, right-click the breakpoint and select Edit Breakpoint, and add an action to print the output:
Now, anytime the breakpoint is hit, it will output the current coordinates.
If you’re serious about coding with Xcode, I would definitely recommend familiarizing yourself with the gazillions of options the LLDB console has to offer!
If you have any great tips yourself, please share them in the comments section. Happy coding!