Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Qualiture
Active Contributor

Introduction


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.


Developers can download the SDK, follow a significant number of follow-through tutorials as well as specific How-To tutorials on integrating SAP Leonardo Machine Learning or Geofencing capabilities.


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.


Most SAP developers may not be familiar with Apple's Xcode development environment, but the look and feel is quite similar to other IDE's. However, if you're a Java or Javascript developer, you may be used to IDE's which are highly customisable, and Xcode may seem severely lacking in that area.


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"


 

Tabs


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.


Wrong 🙂


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.


 

Behaviours


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.


 

Debugger


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



po annotation.coordinate

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!

3 Comments
Labels in this area