In a non-trivial application, wrapping your head around interactions between components in your codebase can be difficult. For example, consider delegation via formal protocols, a pattern that is pervasive in iOS frameworks. The interaction protocols for objects connected through delegation often involve numerous and layered sequences of method calls going back and forth between an object and its delegate. Though the iOS API documentation is generally excellent, a visual trace of the messages that are being sent can be very instructive.
In this article, we will take a look at some simple utility code that may assist you in understanding such interactions during your own development. This utility code behaves is as simple  to use as NSLog, but with the addition that logged output will be shown with visual indentation that makes it easy to understand the message context in which the logging is taking place.

Result Preview

To start off with, let’s take a look at some sample usage and console output (timestamps have been omitted).

//--- Sample usage begin ---
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
TCM_TRACE_BEGIN();
static NSString *CellIdentifier = @"Cell";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
if (cell == nil) {
cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
TCM_TRACE(@"Created cell");
}
cell.textLabel.text = [NSString stringWithFormat:@"Row %d", indexPath.row];
// Configure the cell.
return cell;
TCM_TRACE_END();
}
//--- Sample usage ends ---
//--- Sample output begins ---
-[TCMTraceAppDelegate application:didFinishLaunchingWithOptions:]
-[RootViewController shouldAutorotateToInterfaceOrientation:]
-[RootViewController shouldAutorotateToInterfaceOrientation:]
-[RootViewController viewDidLoad]
-[RootViewController viewWillAppear:]
-[RootViewController numberOfSectionsInTableView:]
-[RootViewController shouldAutorotateToInterfaceOrientation:]
-[RootViewController viewDidAppear:]
-[RootViewController numberOfSectionsInTableView:]
-[RootViewController tableView:numberOfRowsInSection:]
-[RootViewController tableView:cellForRowAtIndexPath:]
Created cell
//--- Sample output ends ---

The output above shows the messages sent by UIKit to a couple delegate objects (TCMTraceAppDelegate and RootViewController) when launching an app with a UITableView. The methods that end up in the log are those that we explicitly want to trace. Hopefully, you’ll agree that the visual trace makes the sequence and layering of calls made to the delegates easier to digest.

Here is more complex sample output obtained when running a modified version of the Core Data application template provided in the iOS 4.3 SDK.

//--- Sample output begins ---
-[CoreDataTracingAppDelegate awakeFromNib]
 -[CoreDataTracingAppDelegate managedObjectContext]
  -[CoreDataTracingAppDelegate persistentStoreCoordinator]
   -[CoreDataTracingAppDelegate managedObjectModel]
    Created managed object model
   Created persistent store coordinator
  Created managed object context
-[CoreDataTracingAppDelegate application:didFinishLaunchingWithOptions:]
  -[RootViewController shouldAutorotateToInterfaceOrientation:]
  -[RootViewController shouldAutorotateToInterfaceOrientation:]
  -[RootViewController viewDidLoad]
-[RootViewController viewWillAppear:]
    -[RootViewController numberOfSectionsInTableView:]
      -[RootViewController fetchedResultsController]
-[RootViewController shouldAutorotateToInterfaceOrientation:]
-[RootViewController viewDidAppear:]
-[RootViewController numberOfSectionsInTableView:]
-[RootViewController tableView:numberOfRowsInSection:]
-[RootViewController tableView:cellForRowAtIndexPath:]
  Created a cell
  -[RootViewController configureCell:atIndexPath:]

... (a cell was added here)

-[RootViewController insertNewObject]
  -[RootViewController controllerWillChangeContent:]
  -[RootViewController controller:didChangeObject:atIndexPath:forChangeType:newIndexPath:]
    NSFetchedResultsChangeInsert
  -[RootViewController controllerDidChangeContent:]
    -[RootViewController numberOfSectionsInTableView:]
    -[RootViewController numberOfSectionsInTableView:]
    -[RootViewController tableView:numberOfRowsInSection:]
    -[RootViewController tableView:cellForRowAtIndexPath:]
      Created a cell
        -[RootViewController configureCell:atIndexPath:]

... (a cell was deleted here)

-[RootViewController tableView:commitEditingStyle:forRowAtIndexPath:]
    Deleted object
    -[RootViewController controllerWillChangeContent:]
    -[RootViewController controller:didChangeObject:atIndexPath:forChangeType:newIndexPath:]
      NSFetchedResultsChangeDelete
  -[RootViewController controllerDidChangeContent:]
    -[RootViewController numberOfSectionsInTableView:]
    -[RootViewController numberOfSectionsInTableView:]
    -[RootViewController tableView:numberOfRowsInSection:]
//--- Sample output ends ---

Implementation overview

The mechanics of the implementation are trivial for the most part. We maintain a “trace depth” that is incremented when a method call we would like to trace is encountered and decremented at the end of the method. While logging, the current trace depth is used to properly format the output.

Every method we wish to trace will begin with TCM_TRACE_BEGIN() and must end with TCM_TRACE_END(). These paired macro statements will emit the current method’s name and set up a new log context for code executed within that method. We also have a macro called TCM_TRACE(format, …) for any additional log messages we would like to be output.

Additionally, let’s add the requirement that incorrectly paired TCM_TRACE_BEGIN() and TCM_TRACE_END() statements will not run so as to avoid unnoticed incorrect results. Implementing the TCM_TRACE_END() is slightly tricky because a method may have multiple return paths. We will engineer the solution so that missing this will result in a build error.

Having objects with automatic lifetimes and destructor calls as in (Objective) C++ is one solution, but we will keep our solution pure Objective-C. Luckily, Objective-C’s exception handling mechanism gives us what we need. TCM_TRACE_BEGIN() will expand to a dangling @try block that increments the trace depth and emits the current method. Similarly, TCM_TRACE_END() will close the previous @try block followed by a @finally block that ensures that decrements the trace depth. This approach takes care of the most common usage errors that might occur when using the macros. Yes, this is an abuse of the exception handling mechanism, but it does work rather well and should never be present in production code anyway.

The implementation of the actual logger class and some other housekeeping details are not particularly interesting and won’t be discussed here. Check the end of the article for the source.

Notes

You’ll notice that the implementation presented above expects the logging to be performed on a single thread. Extending it to be usable from multiple threads is possible, but I have never found a need to, and the interleaved output from multiple threads that might result would not be quite as useful for visualizing message traces. Note also that this isn’t actually an actual execution trace. For that, accessing the NSThread stack symbols API or using a tool like Instruments would be a better option.

Remember that behavior that is not explicitly specified in API documentation is behavior that is fair game for change later. You should never rely on observed behavior to infer guaranteed behavior of official APIs. The goal here was to develop a quick and dirty way of getting logging functionality to assist with comprehension and debugging. I personally find the most utility in this functionality when learning new APIs and quickly verifying expected interactions between my own classes.

Files

The files containing the implementation are TCMTrace(.h|.m).

The sample was developed in Xcode 4.0.1.
Simple sample project

Core Datasample project

This excerpt is  the CoreGraphics and Core Animation chapters. Take a look. See what you think.

[Download Ch 16: Drawing with CoreGraphics (PDF)]

[Download Ch 17: Core Animation (PDF)]

Chapter 16: Drawing with CoreGraphics

Up until this point, any graphics we’ve drawn have been intrinsically handled by the controls we’ve used. For example, we’ve created plenty of buttons, but we’ve never had to draw them ourselves. Sometimes, however, we need to do custom drawing beyond what the controls offer out of the box. For example, let’s say that you want to build a view that has a rounded rectangle border. You could do this with images, but for maximum configurability, you could draw the lines and corners using CoreGraphics. That way, you could vary the radius of the corners, as well as the color and thickness of the lines, without having to do new images every time.

We have several options to do custom drawing, including CoreGraphics, OpenGL, and the XNA Toolkit. CoreGraphics is the simplest option, as it is designed only for 2D drawing. We will explore CoreGraphics in this chapter.

CoreGraphics is also known as the Quartz drawing system, as it inherits its design and functionality from the Quartz framework on the Mac OS.

Entire books have been written on Quartz, and while this chapter will give a solid foundation on how to use CoreGraphics in MonoTouch, as well as introduce you to its common features, it is by no means exhaustive. The Quartz API is massive. Covering it in detail goes far beyond the scope of this book. With that said, however, if you’re looking for a more thorough reference once you’re through this chapter, check out Apple’s Quartz 2D Programming Guide. It’s part of the documentation that ships with the Xcode SDK, and is an invaluable asset for advanced drawing tasks.

If you’re familiar with System.Drawing, you’ll no doubt find Quartz API similar, but it is exponentially more powerful. This chapter will get you well on your way with Quartz. By the end, you’ll have a good, solid grasp on all the important fundamentals, and be able to do most common drawing tasks.

You can find examples of all the code in this chapter in use in the Example_Drawing companion application.

Let’s first look at some fundamental concepts of CoreGraphics, and then we’ll dig into some code.

Painter’s Model

CoreGraphics uses what is known as the painter’s model. As you draw, each subsequent drawing operation is applied on top of the previous one.

Unlike layers in programs such as Photoshop, once you have drawn something, you can’t undraw it, or pull layers out. If you want to build an application like that, you either need to store a list of your draw operations and then re-draw each of the ones that you want to apply, or use multiple drawing surfaces, which we will explore in the “Drawing Context” section later in this chapter.

If you’ve used System.Drawing, or any other modern 2D drawing frameworks, this model will be very familiar to you. And in fact, many of the same techniques and tools apply.

Performance

Another important thing to know about CoreGraphics is that, while it is highly optimized for the iPhone, it is not guaranteed to use hardware acceleration. The iPhone and iPad have a dedicated GPU to handle drawing operations, and some operations that you do in CoreGraphics might be accelerated (handled by the GPU), but you never know what will be accelerated and what won’t.

For most uses, this doesn’t matter, as the iPhone and iPad handle drawing operations quite well. However, for high-performance 2D or 3D drawing, like the kind you see in games, you should instead use OpenGL or the XNA Toolkit for MonoTouch (which also uses OpenGL under the hood). These toolkits have a number of other features that make them much more suitable for game development. Unfortunately, they’re also more complicated, which is why CoreGraphics is very useful.

Chapter 17: Core Animation

One of the iconic things about iOS is its cinematic user experience. GUI elements slide on and off screen, fade in, fade out, flip, curl, and bounce, the result of which is an interface that feels very smooth, dynamic, and organic.

Powering this cinematic experience is one of iOS’ foundation technologies, Core Animation. The Core Animation API provides you with a number of UIView-based animation features that allow you to easily animate changes in your interface so that your applications can provide the same cinematic experience that users have come to expect from iOS applications. View-based animation includes two types of animations: transition animations and same view animations. Transition animations are animations that occur when you’re changing between views. For instance, you might want to load another view and use a flip transition so that when it appears, the whole screen appears to flip with the new view on the side that rotates in. Same view animations are animations that occur on a single view, such as moving subviews around.

In addition to the view-based animation features, the core animation API exposes lower-level animation functions that operate on CALayer objects, rather than UIView objects, and provide a powerful 2D animation framework that you can use to create more complex animations, and even power games.

For most applications the view-based animation framework is the only part of Core Animation you’ll ever use. They provide a powerful way to give your interface that cinematic feel without much work. In fact, if you’ve been reading this book front-to-back, you’ve already been exposed to it. In this chapter, we’ll explore it a little deeper and take a look at how to work with it in more detail. Then, we’re going to dig into the lower-level core animation API to see how advanced animation can be accomplished in the iOS.

As with Chapter 16, this chapter covers most of everything you’ll ever need to use with animation; however, the Core Animation API is massive. If you’re doing advanced animation, you should check out the Core Animation Programming Guide in the Xcode developer documentation after you’ve read this chapter.

You can find all the examples used in this chapter in the Example_CoreAnimation sample code and application.

View-Based Animation Framework

There are two different approaches when working with the view-based animation framework: the new way and the old way. The new way (available since the iOS v4.0 release) is the way recommended by Apple, but both ways have their advantages. Let’s take a quick look at examples of both methods so that you have a clear understanding of them.

View Animations via the Animation Blocks

First, the old way is to call BeginAnimations, optionally configure the animation options, make your view changes, and then call CommitAnimations. See Listing 17–1.

UIView.BeginAnimations("ImageMove");

//code to make changes to the view (move controls, swap views, etc.)

UIView.CommitAnimations();

Using this method, iOS will automatically animate any changes that occur between the BeginAnimations and CommitAnimations calls.

Technically, Apple refers to this method of animation as Animation Blocks, but as we’re about to see, that’s really confusing, given that the new way is called Block-Based Animation. I’ll just refer to it as “the old way” to avoid confusion.

View Animations via Block-Based Animation

The new way is to make a call to the Animate method, specify the duration of the animation, optionally specify any of the animation options, and then pass a method (or code as a lambda) that makes the changes that should be animated. See Listing 17–2.

UIView.Animate(0.2, () => { /* code to animate */ });

In this case, to simplify things, I’ve used the C# lamdba syntax, but you could also pass an anonymous delegate, as shown in Listing 17–3.

</p>
<p style="padding-left: 30px;">UIView.Animate(0.2, delegate() { /* code to animate */ });</p>
<p style="padding-left: 30px;">

This approach is known as block-based animation. It’s called such because in objective-c, the analog to code that’s passed in to execute is called a block. If you take a look at the prototype for the Animate methods (there are several overrides), they all take NSAction objects for their blocks. MonoTouch automatically does the magic of converting an anonymous delegate into an NSAction for you, so it’s a very clean and seamless integration with the underlying Objective-C runtime.

Like it happens in every community, many developers have written loads of projects to help them with their next project. Some of these projects are Open Source with different licensing but almost all of them can be used in your next commercial app.

I will talk about two of these today, one which I feel is done in most of the apps and something else which should be present just to make the user experience better over time.

JSONKit

JSONKit is a very high performance Objective-C JSON Library written by John Engelhart (https://github.com/johnezang/JSONKit).

For those who do not know what this is, Javascript Object Notation, or JSON is a lightweight, text-based, serialization format for structured data that is used by many web services and API’s.

I know that there are a lot of other Open Source JSON Libraries present but when you compare JSONKit with others, you really feel the performance difference.

*Image Courtesy: John EngelHart

It is also very easy to integrate inside your app, as it is not a bunch of files. Just add the interface and an implementation file and add an import and we are good to go.

As far as the methods are concerned, they are easy to understand and also adds a few methods to NSString, NSData, NSArray and NSDictionary.

There are a few tips to speed up the process parse the JSON available on the github page. It mostly depends on how you are fetching your JSON.

With speed, there always are a few things to keep in mind. Same is the case with JSONKit.

JSONKit is not designed to be used with Mac OSX Garbage Collection. It is extremely unlikely that it would ever be supported.

The JSON to be parsed must be encoded as Unicode.

Now, lets have a look at another project called QuincyKit.

QuincyKit

QuincyKit is a live management tool for your crash reports for Mac OSX and iOS. It has a 4 member core team which is leading the development of the project on the client as well as the server end (I’ll come to this later). The team includes Thomas Dohmke (@ashtom), Kent Sutherland (@ksuther), Stanley Rost (@soryu2) and Andreas Linde (@therealkerni).

The iOS client of the project uses PLCrashReporter by Plausible Labs (http://plausiblelabs.com) without which this would not have been possible.

QuincyKit is not a 3^rd party service which allows you to manage all your crash reports. It is absolutely free and all you need is a webserver with PHP5 and MySQL to run the server component.

The server component gives you the following

• Collect crash reports from multiple apps
• Automatic grouping of crash reports based on similarity for easier management and review
• Graphical stats are provided which help you understand what all devices and OS versions are affected.

The Client SDK (iOS and Mac OS X) allows you to

• Automatically detect a previous crash on the next launch of the app
• Collect User Feedback (Only Mac OS X)
• Provide the user feedback about the status of a crash (iOS Only)

This SDK is AppStore ready and can be used in beta and release versions of your app very easily. As on the Mac it uses the system generated crash reports, and for iOS, the ones by PLCrashReporter, it is very reliable.

The Github Wiki provides the details of how to integrate it into your app along with project setup and a demo app for both the iOS and Mac OS X

Both these projects serve very different aspects of your application lifecycle. You might chose to include the in your next app, and if you do, just drop in a line to the original authors about your app

Welcome to The Cocoa Magazine. I started this magazine (I hesitate to call it that, since there will NEVER be a print component) because there was a clear lack of any such source for developers to get the best information available. Sure there’s google, and it does ok, but my hope is that over time, the content here at the Cocoa Magazine is so much better than anywhere else, you’ll come here to search.

This magazine will be a mix of technical, business, design articles, and whatever else we think will have value to cocoa developers. The plan is to grow and become what the community needs.

What’s in store for the future?

To start, this magazine will live as a website, hopefully one that plays well on an iPad (thanks to Onswipe), but a website nonetheless. The upside is that it’ll be entirely free and open, just drop in, search for content, read the articles each month (we’ll likely release stuff in between monthly releases as well, but that’s later), and more. As we get going though, the next steps involve getting an iPad app created, and figuring out a model that provides a little financial support for everyone involved (I wonder if AOL is still buying). The idea for the iPad app will be straightforward content. Nothing fancy like Wired and the like, just great content, searchable, archivable, and mobile.

Wait, what’s that about money?

Lots of good things are free, but great things cost money. We’re starting Cocoa Magazine good, but we’ll be great as soon as possible. When we do, we’ll be looking at a model similar to ars.technica’s premier subscription. That’s at least a few releases out, and only when we’re sure it’s gonna be worth it for you.

Join us.

We’re still looking for contributors so if you think you’ve got something to share, drop us an email at Thecocoamag AT 360conferences DOT com and we’ll get you in our google group and get you on the schedule. This is gonna be a fun ride, we’re gonna make something awesome!

Greg Cerveny is currently working with Occipital in Boulder CO as a consultant and sat down to talk about all things Occipital, here’s the first 2 things they talked about.

1. Occipital is an Engineering Company
“Most people think it (360 Panorama) is using the gyroscope, but it’s really computer vision that’s tracking motion. It’s actually more accurate than using the gyroscope.”
This is how Jeff Powers explains the 360 Panorama app.  When he first tells me this, we are sitting in ergonomic ultraviolet office chairs in a meeting room cornered by two walls of glass.  Every available writing surface, including the two glass walls, are filled with notes and equations.
It is immediately obvious that Occipital is not a casual app company.

2. Any Bar Code Scanner Timeline
Late February, 2009
Development on a bar code scanner and price comparison app that would later become Red Laser begins.

Early May, 2009
The application is released with server side processing.  Photos can only be taken of a bar code taken at 12″ away.
Jeff Powers: “Unless you were a true expert at using it, it would be faster to read the bar code number, and type it in to your phone.”
Vikas Reddy: “We made the decision that the server based approach was not going to work, and we had to do it real time.”

Late June, 2009
Red Laser releases real time scanning of some barcodes, others still processed remotely.
Apple begins rejecting subsequent updates.
JP: “There was no access to the camera and what we were doing was off limits.  Policy was fluctuating, and ultimately, we were told that it wasn’t permitted.  But we kept developing even though it was very uncertain if it would ever be allowed at all.”

September, 2009
Apple approved a version with real time scanning for all formats of bar codes. Growth occurs exponentially.   No advertising and very little press outreach.
JP: “It was actually a fantastic case study we didn’t intend.   We had the control group, v1.0, with all the same features as v2.0, but not real time scanning.  The commerce part of it, the price checking part of it, all the exact same.  So, if your hypothesis is, any bar code scanner launched at the same time would do the same, that would be invalidated that v1.0 got almost no usage, and v2.0 took off exponentially.  The only thing that changed was the actual computer vision of the barcode scanning.”

Not Explicitly Listed
6 months of iteration on computer vision based bar code algorithm

But, wait.  It looks like a last-minute change request from the beta testers just showed up in your inbox.  You take a look and quickly realize that your beta team members know what they’re talking about and if you want commercial success, you really need to add this feature.  You pop open Xcode and start going through your source code only to realize that you now face a difficult choice.  You can either spend weeks and months refactoring your design or you can quickly hack something in but it will ruin your design, and has a high likelihood of breaking in some of the edge cases.  Internally, your pragmatic brain must now wrestle with your code-purity soul.

Most experienced developers have found themselves in this situation at some point in their career.  Fortunately if you’re an iOS developer the UIGestureRecognizer class just might be able to get you out of the pickle you’re stuck in.  UIGestureRecognizers allow you to easily extend touch handling to UIView objects regardless of whether they were created to do so or not.  Applications written for iOS 3.2 and later can take advantage of them by either adding a pre-defined recognizer or implementing their own.

Using UIGestureRecognizers is incredibly simple.  The UIView class implements an addGestureRecognizer/removeGestureRecognizer function pair for inserting recognizers into their touch handling hierarchy.  The quickest way to get up and running is to simply use one of the built-in gesture recognizers.  The six built-in types are:

1. UITapGestureRecognizer
2. UIPinchGestureRecognizer
3. UIPanGestureRecognizer
4. UISwipeGestureRecognizer
5. UIRotationGestureRecognizer
6. UILongPressGestureRecognizer

While you certainly can come up with other types of gestures to build, these six provide a large repertoire to start with.  It should be noted that multiple gesture recognizers could be added to an object.  What this means is that if you have a UIView object, you can easily add both rotate, swipe and press recognizers (or any other combination you can think of.)  This is the true power of gesture recognizers because they can be added cumulatively using the observer pattern without impacting existing object hierarchies.

Figure 1 shows a minimalist implementation of how you might add one to a view.  Please note that memory reference counting code has been removed to simplify the examples.  If you need to keep a pointer to the recognizer, you will need to make sure that you properly retain and release the pointer yourself or it will autorelease when removed from the view.

UIGestureRecognizer* recognizer = [[UITapGestureRecognizer alloc]
      initWithTarget:self action:@selector(tapReceived:)];
[self.view addGestureRecognizer:recognizer];

By choosing to implement gesture recognizers in the UIView base class, Apple chose to give developers greatest flexibility in what types of objects you can add these to.  You could just as easily add a rotate or swipe gesture to a UIButton as to a UIImageView, or a UITableView.  As you can see from the code in Figure 1, you simply pass a selector for whatever class function you choose to implement.  In this example, the calling class implements a tapReceived function that takes a UIGestureRecognizer as a parameter.  When tapReceived is called, the calling class receives the recognizer that it can then interrogate to determine what it should do in response.  Figure 2 shows an example of how you might implement the callback for handling a swipe gesture.

-(void)swipeReceived:(UISwipeGestureRecognizer *)gesture
{
CGPoint offset = self.view.center;
if (gesture.direction == UISwipeGestureRecognizerDirectionLeft)
{
offset.x -= 50.0;
[self.view setCenter:offset];
}
else if (gesture.direction == UISwipeGestureRecognizerDirectionRight)
{
offset.x += 50.0;
[self.view setCenter:offset];
}
}

As if this amount of flexibility wasn’t enough, Apple also provides one more mechanism for squeezing in “bad-code-bailout” functionality.  It does this in the form of the UIGestureRecognizerDelegate.  The three delegate functions shouldReceiveTouch, gestureRecognizerShouldBegin and shouldRecognizeSimultaneouslyWithGestureRecognizer will get called on your delegate object when a gesture is beginning.  They give you the opportunity to basically allow and disallow gestures based on whatever logic you might implement.  Obvious uses would be to disallow them based on application state or because other gestures are already in play.  To be clear, you can use gesture recognizers without setting the delegate property of the recognizer despite plenty of sample code to the contrary.  Furthermore, if you do chose to use the delegate functionality, all of the protocol functions are declared as optional.

If given all of the above flexibility still isn’t enough for you, you can always implement your own gesture recognizer.  If you go down that road, make sure to include UIGestureRecognizerSubclass.h, which will redeclare the UIGestureRecognizer state property as read/write as well as declare the eight functions that a derived class must implement.  The primary duty when implementing your own recognizer is to properly update the state property.  I will save implementing your own subclass as an activity for the reader, but suffice it to say the exercise is fairly straightforward.

As you can see, UIGestureRecognizers are incredibly handy for extending built-in UIKit classes as well as any proprietary classes you might have.  I personally have found them to be invaluable for the end of the project crunches where your pragmatic side needs to kick into gear.  Despite them being available since OS 3.2, not a lot of developers are aware of how powerful they can be.  For their part, Apple provides sample projects and documentation on their developer website, but to be honest, the class is so simple to use, you can find everything you need in the header files for the various classes.  I am repeatedly surprised at how many developers are unaware of the existence of these classes.  Hopefully if you fall into that category, this brief introduction to the UIGestureRecognizer class will give you another tool for your belt for those times when you need to get your project across the finish line.

Why make a tip calculator?  First, it’s one of the easiest exercises you can do, so it is a great way to get started with iPhone development.

Secondly, if you’re as slow at math as I am, it’s actually really handy sometimes and you may find yourself using it!  :]
So let’s get started, and get tipping!

Source Code Available here

Hello, iPhone!
To develop on the iPhone, you need a Mac.  Pretty much any Mac will do, whether a Mac laptop or what I used to get started – a Mac mini.
Once you have your Mac, you need to download and install Xcode 4, the program you’ll use to build your apps.  You can Download Xcode 4 from Apple’s site – it’s free if you’re a member of the iOS or Mac developer program, or you can buy it separately for a small fee if you’d like.
Once you have Xcode 4 installed, run it and go to File\New\New Project.  Choose iOS\Application\View-based Application, and click Next.

Tap for Larger

On the next page, enter TipCalculator for the Product Name.  For the Company Identifier put a unique string (such as one of your domain names, if you own one).  Make sure Device Family is set to iPhone, and click Next.

tap for larger

Finally, choose a folder to save your project in, and click Create.
Let’s see what you have so far!  In the toolbar at the top of Xcode, click Scheme and set it to your iPhone Simulator, as shown below:

Tap for larger

Then click the Run button in the upper left of the toolbar, and you should see your app run in the Xcode simulator!

Tap for larger

So far so good, except this is kinda boring!  Let’s make things a little more interesting by making the screen say “Hello, iPhone!”
In Xcode, you’ll see the files in your project listed off to the left.  Select TipCalculatorViewController, and it will bring up a visual editor for the main screen in your app:

Tap for larger

This visual editor is “Interface Builder” by the way, so I’ll refer to it by that from now on.
We want to add a label to this screen that reads “Hello, iPhone!”  But to do this, you need to bring up the window that shows you all the views and controls you can add to the screen.
To bring up this window, in the toolbar to the upper right, there is a segmented control with three buttons that reads View.  Click the button on the far right so it is shaded, and a window will slide in.
The window on the side is split into two parts – a top part and a bottom part.  On the bottom part, it also has a toolbar, that lets you look through various libraries of things to add.  Make sure the third tab item is selected, for the Object library.
Here’s a screenshot to show you the buttons you need to select:

Tap for larger

Now, from the library look for the item that reads “Label”, and drag it into the top middle of your view.  Double click the label and change the text to “Hello, iPhone!”

Tap for larger

Before we try this out, let’s make this text bigger, and a different color.  Make sure your label is selected, then in the top part of the sidebar to the right, select the fourth tab.
This will bring up attributes you can change on the label, such as the alignment, number of lines, etc.
You’ll seen an entry there for Font.  Click the button that looks like a T to the right of the font entry to bring up a visual editor, and set it to 36 points.
You’ll notice that after setting it, the label seems to stay the same size, but that’s just because you haven’t increased the size of the label itself yet, and by default it shrinks to the area you give to it.
So also increase the size of the label by dragging the blue dots at the edges until the text doesn’t grow anymore, and your screen should now look like this:

Tap for larger

One last step – let’s change the font color.  To do this simply click the black box next to Text Color to bring up the color editor, and pick your favorite color:

Tap for larger

And that’s it!  Click the Run button to run your project, and you should now have an App that says “Hello, iPhone!”

Tap for larger

Tip Calculator Layout
All the stuff you just did was to get you familiar with the basics of running iPhone apps and adding controls.
But that isn’t the way we want our Tip Calculator to actually look like, so let’s get the UI designed the way we’d like!
First, double-click the “Hello, iPhone!” label, and change the text to “Tip Calculator.”
Then, drag another label to the screen to the lower left of the “Tip Calculator” label, and change the text to “Bill Amount:”.

Tap for larger

Next, drag a Text Field from the library to the right of the label.  The Text Field is the control you use when you want the user to be able to enter numbers or letters.
Resize the Text Field a bit so it fits all the way to the edge of the screen as well.

Tap for larger

Now, repeat this process to add another label reading “Tip Percent:” and a text field to its right.
Also, drag a Round Rect button to the lower right, and double-click it to change the text to “Calculate!”
Finally, add a label right below the button that reads “Your tip should be: XXXX” and extend the size to fit the entire width of the screen.
At this point your layout should look as follows:

Tap for larger

Click the Run button to run your app in the Simulator, and you should see your layout appear.  Try tapping one of the text fields, and you’ll notice that the keyboard comes up, but there’s a problem: it defaults to letters!

tap for larger

The keyboard style is another example of something you can change in the attribute editor for a control.
So go select the two text fields (you can draw a border around them to select both), and change the keyboard to Numbers and Punctuation:

Tap for larger

Run your project again and tap on a text field, and now it’s easier to enter in a test tip amount!

Tap for larger

Of course, tapping the Calculate button does absolutely nothing, which is kind of disappointing!  So let’s take care of this next.

Views and View Controller: Overview
All of the things you’ve been adding to the Tip Calculator so far (labels, text fields, and a button) are called views.
If you think about it, somehow you’re going to need to write some code that has access to these views.
You’ll need to get the value of what the user put in for the bill amount and tip percentage, run a calculation on it, and put the result in the lable to the bottom.  You’ll also need to know when the button is clicked.
In iPhone development, the class that manages the views for a particular “screen” in your app is called a View Controller.  You may be familiar with this concept already if you’ve used the Model-View-Controller architecture in other languages.
Your project already has a TipCalculatorViewController class set up for you, in TipCalculatorViewController.h and TipCalculatorViewController.m.
So somehow, you need to find a way to hook up the views you’ve made in Interface Builder to this class!

Views and View Controllers: Hooking Up
To hook up the view controller to the views, we want to make an instance variable and property for each of the views we need to access in code, and a method that will be called when the button is tapped, as shown below:

Tap for larger

Luckily, this is incredibly easy in Xcode 4!
In the toolbar at the top of Xcode where it reads Editor make sure the second tab is selected to bring up the Assistant Editor.
Also, go to View\Assistant Layout\Assistant Editors on Bottom so it shows up below Interface Builder (I find it easier to work with that way).

Tap for larger

Make sure that the Assistant Editor is set up to Automatic in its toolbar, and that the TipCalculatorViewController is showing up in the editor.
Then, select the bill amount text field in Interface Builder, hold down control, and drag a line from it to right below the @interface block in the Assistant Editor:

tap for larger

A popup will appear.  Enter billAmountTextField for the name, and click Connect.
Once you’ve done this, you’ll see that it automatically creates an instance variable and property for you for billAmountTextField:

Tap for larger

If you control-click on the Text Field in Interface Builder, you’ll see that it has also associated the text field to the File’s Owner (which is TipCalculatorViewController).  This is the step that hooks up the code to the view, all done for you!

Tap for larger

Now repeat this process for the Tip Percentage text field (naming it tipPercentTextField) and the label at the very bottom (name it resultLabel).
Now we need to do something slightly different – hook up the calculate button to call a method in our view controller.  Luckily this is also quite easy with Xcode 4!
Drag a line from the Calculate button down to the assistant editor after the @interface as you did for the others, but this time change the Connection type from Outlet to Action.  For name, enter calcTapped, and click Connect.
This time, you’ll see that it’s created a method called calcTapped for you (that is empty right now).  Also if you control-click on the button in Interface Builder, you’ll see that it’s hooked up the Touch Up Inside event to this method for you.
Almost done!  In the Files & Groups tree to the left, select  TipCalculatorViewController.m to bring up the editor.  Scroll down to calcTapped, and replace the contents with the following:

- (IBAction)calcTapped:(id)sender {

NSString *billAmountString = [billAmountTextField text];

float billAmountFloat = [billAmountString floatValue];

NSString *tipPercentString = [tipPercentTextField text];

float tipPercentFloat = [tipPercentString floatValue];

float tipAmount = billAmountFloat * tipPercentFloat;

NSString *result = [NSString stringWithFormat:@"Your tip should be: %0.2f",

tipAmount];
    [resultLabel setText:result];
}
<span style="font-family: Georgia, 'Times New Roman', '<span class=;">Bitstream</span> Charter', Times, serif; font-size: 13px; line-height: 19px; white-space: normal;">

The first thing this does is get the text the user entered for each field.  The UITextFields have a text property you can use to get this.

It needs to convert each of these values to floats so we can do the calculation.  Luckily NSString has a helper method called floatValue that will convert strings to floats.
Finally, it performs the calculation and sets the label to the result.
Click the Run button to run your project, and you should now have a functional Tip Calculator!

Tap for larger

Where To Go From Here?
Here is the sample project with all of the code from the above tutorial.
Contgratulations, you now have your very own iPhone app made from scratch, and pretty useful too!
But why not make it even better?  You could add another field where the user can enter the tax rate, so you’re not over-tipping!  Or you could try to pull the tip calculation code into a helper class (your Model) to keep the code a bit cleaner.

If you’re interested in learning more, check out the How To Make A Simple iPhone App Tutorial available on my iPhone Tutorial blog.  It shows you how to make an app about scary bugs, using some neat components in iPhone programming such as table views and image pickers!
I hope you enjoyed this tutorial, and best of luck in your iOS adventures!
This is a post by Ray Wenderlich, an indie iPhone developer passionate about making apps and teaching others the techniques to make them.  You can find more tutorials by Ray on his iPhone Tutorial blog.

Productivity is something I’ve thought a lot about because it’s something I’ve struggled with, I think a lot of other people have too. As developers we have a lot of tasks and reference materials to keep track of whether we’re working at a company, developing our own projects, or consulting for someone else. For most people it’s hard to not lose anything without a water-tight system to capture and manage it all.

In this article I want to talk about capturing tasks and related materials. If you know GTD, some of it’s going to sound familiar. In GTD one of the core ideas is that you need to capture every item that goes through your head in a trusted place where you know that you can come back to it later and process it effectively. For developers finding a system that’s simple and seamless enough to not interfere is essential.

Methods of Capture

I combine high and low tech tools for capture, and default to whichever works for the context I’m in. As long as I trust the tool and know that I come back to it, the specific method of capture is really pretty secondary.

On The Mac

On my Mac I’ll usually just type into a text file or directly into my task management software. Most of these apps have some concept of an inbox and that gives me a trusted and known place I can come back to for later processing. Pick any tool that makes you comfortable here. If you’re interested in processing your tasks later in a GTD centric way, OmniFocus is a great choice that I’ve had a lot of success with.

A habit that I’ve recently started is having a folder called “Inbox” on my Mac for storing files that I’m not sure what to do with yet. I process this at least once a day to keep it from getting stale. Mine is kept in the root directory of my Dropbox folder and is kept as a
stack on my dock. I’ve also set screenshots I take to go here which you can do from Terminal with this line: defaults write com.apple.screencapture location /Full/Path/To/Folder. Getting transient files off of my Desktop and processing them regularly has turned out to be a great habit for keeping track of these files.

On The Go

When I’m away from my computer and need to capture a task or thought quickly, I normally default to OmniFocus on my iPhone. The thing that’s important when picking a mobile tool is that if you’re going to sync with a desktop app you trust syncing will be automatic and painless enough that your information will be there you need it. OmniFocus has worked really well for that because the syncing is mostly automatic – my tasks have always just been everywhere I needed them. You should consider the level of pain you’re willing to endure here versus what tool you like the best offers. Entering tasks on the iPhone usually works best for me when I’m away and have a quick idea, or remember something I need to do want to jot it down. I don’t try to organize tasks using the iPhone at all and mostly just use it for capture.

If I need to store a slightly more detailed note, or I’m working with someone, a notebook is my solution. I don’t like to type a long set of notes into the iPhone if I can avoid it. Also when dealing with someone else jotting something into a notebook looks like you’re paying attention, pulling out an iPhone and typing feverishly into it makes you look like an asshole. When picking a notebook, find one sturdy and small enough to survive in your back pocket. Carrying it with you at all times is a great habit, and I definitely feel like I capture more errant ideas just by having it. Field Notes have treated me well, both for size and durability. I’ll also use the notebook for sketching into which is a task that neither a computer nor iPhone is particularly well suited for.

Wrapping Up

Capture is one of the most integral parts of any task management system. Without capturing everything you can’t even really be sure what you need to accomplish, let alone start doing it. In future articles I’d like to continue by discussing how to effectively process tasks and manage a reference system. I hope that reading this has given you some ideas for how you can be more effective at getting things out of your head and into a system, next month we’ll talk about processing and turning them into tasks.

There’s not much to see here yet, in fact there until May 27th there won’t be. That’s when the first “issue” of this goes live. We’ve got some great articles lined up and are working on a few more.

Finding content in this magazine will be easy. Each ‘issue’ will be tagged with the issue number and month and year. They’ll also be tagged with keywords so when you want to search on Xcode, you’ll only find articles dealing with code, and the IDE.

The idea is that this magazine becomes a useful resource for finding awesome and worthwhile content well down the road.

All are welcome to contribute, just email (thecocoamag AT 360conferences DOT com)us to get started.