Update note: This tutorial was updated for iOS 8 and Swift by Nick Lockwood. Original post by Tutorial Team member Jake Gunderson.

Core Image is a powerful framework that lets you easily apply filters to images. You can get all kinds of effects, such as modifying the vibrance, hue, or exposure. It can use either the CPU or GPU to process the image data and is very fast — fast enough to do real-time processing of video frames!

Core Image filters can also be chained together to apply multiple effects to an image or video frame at once. The multiple filters are combined into a single filter that is applied to the image. This makes it very efficient compared to processing the image through each filter, one at a time.

In this tutorial, you will get hands-on experience playing around with Core Image. You’ll apply a few different filters, and you’ll see how easy it is to apply cool effects to images in real time!

Getting Started

Before you get started, let’s discuss some of the most important classes in the Core Image framework:

• CIContext. All of the processing of a core image is done in a CIContext. This is somewhat similar to a Core Graphics or OpenGL context.
• CIImage. This class hold the image data. It can be created from a UIImage, from an image file, or from pixel data.
• CIFilter. The CIFilter class has a dictionary that defines the attributes of the particular filter that it represents. Examples of filters are vibrance, color inversion, cropping, and many more.

You’ll be using each of these classes in this project.

CoreImageFun

Open up Xcode and create a new project with the iOS \ Application \ Single View Application template. Enter CoreImageFun for the Product Name, select iPhone for the Devices option, and make sure that Language is set to Swift.

Download the resources for this tutorial, and add the included image.png to your project.

Next, open Main.storyboard, and drag an image view in as a subview of the existing view. In the Attributes Inspector, set the image view’s content mode to Aspect Fit, so it won’t distort images.

Next, ensure the Document Outline (the hierarchy left of the canvas in Interface Builder) is visible – you can enable it from the menu at Editor \ Show Document Outline.

Control-drag from the image view to its superview three times to add three constraints:

1. Add a constraint Top Space to Layout Guide, using the Size Inspector to set the constraint’s constant to zero if necessary.
2. Add a constraint to Center Horizontally in Container (also setting its constant to zero).
3. Add an Equal Width constraint.

Finally, to constrain the image view’s height, control drag from the image view to itself, and add an Aspect Ratio constraint, using the Size Inspector to set its multiplier 8:5 for the ratio of width to height and a constant factor of zero. Finally, navigate to Editor \ Resolve Auto Layout Issues \ All Views in View Controller \ Update Frames, so Interface Builder updates the layout based on these new constraints.

Next, open the Assistant Editor and make sure it’s displaying ViewController.swift. Control-drag from the UIImageView to just after the opening brace of the ViewController class. Name the outlet imageView, and click Connect.

Build and run the project just to make sure everything is good so far – you should just see an empty screen. The initial setup is complete – now onto Core Image!

Basic Image Filtering

You’re going to get started by simply running your image through a CIFilter and displaying it on the screen. Every time you want to apply a CIFilter to an image you need to do four things:

1. Create a CIImage object. CIImage has several initialization methods, including: CIImage(contentsOfURL:), CIImage(data:), CIImage(CGImage:), CIImage(bitmapData:bytesPerRow:size:format:colorSpace:), and several others. You’ll most likely be working with CIImage(contentsOfURL:) most of the time.
2. Create a CIContext. A CIContext can be CPU or GPU based. A CIContext is relatively expensive to initialize so you reuse it rather than create it over and over. You will always need one when outputting the CIImage object.
3. Create a CIFilter. When you create the filter, you configure a number of properties on it that depend on the filter you’re using.
4. Get the filter output. The filter gives you an output image as a CIImage – you can convert this to a UIImage using the CIContext, as you’ll see below.

Let’s see how this works. Add the following code to ViewController.swift inside viewDidLoad():

// 1
let fileURL = NSBundle.mainBundle().URLForResource("image", withExtension: "png")
 
// 2
let beginImage = CIImage(contentsOfURL: fileURL)
 
// 3
let filter = CIFilter(name: "CISepiaTone")
filter.setValue(beginImage, forKey: kCIInputImageKey)
filter.setValue(0.5, forKey: kCIInputIntensityKey)
 
// 4
let newImage = UIImage(CIImage: outputImage)
self.imageView.image = newImage

Let’s go over this section by section:

1. This line creates an NSURL object that holds the path to your image file.
2. Next you create your CIImage with the CIImage(contentsOfURL:) constructor.
3. Next you’ll create your CIFilter object. The CIFilter constructor takes the name of the filter, and a dictionary that specifies the keys and values for that filter. Each filter will have its own unique keys and set of valid values. The CISepiaTone filter takes only two values, the KCIInputImageKey (a CIImage) and the kCIInputIntensityKey, a float value between 0 and 1. Here you give that value 0.5. Most of the filters have default values that will be used if no values are supplied. One exception is the CIImage, this must be provided as there is no default.
4. Getting a CIImage back out of a filter is as easy as using the outputImage property. Once you have an output CIImage, you will need to convert it into a UIImage. The UIImage(CIImage:) constructor creates a UIImage from a CIImage. Once you’ve converted it to a UIImage, you just display it in the image view you added earlier.

Build and run the project, and you’ll see your image filtered by the sepia tone filter.

Congratulations, you have successfully used CIImage and CIFilters!

Putting It Into Context

Before you move forward, there’s an optimization that you should know about.

I mentioned earlier that you need a CIContext in order to apply a CIFilter, yet there’s no mention of this object in the above example. It turns out that the the UIImage(CIImage:) constructor does all the work for you. It creates a CIContext and uses it to perform the work of filtering the image. This makes using the Core Image API very easy.

There is one major drawback – it creates a new CIContext every time it’s used. CIContext instances are meant to be reusable to increase performance. If you want to use a slider to update the filter value, as you’ll be doing in this tutorial, creating a new CIContext each time you change the filter would be way too slow.

Let’s do this properly. Delete step 4 from the code you added to viewDidLoad(), and replace it with the following:

// 1
let context = CIContext(options:nil)
 
// 2
let cgimg = context.createCGImage(outputImage, fromRect: outputImage.extent())
 
// 3
let newImage = UIImage(CGImage: cgimg)
self.imageView.image = newImage

Again, let’s go over this section by section.

1. Here you set up the CIContext object and use it to draw a CGImage. The CIContext(options:) constructor takes an NSDictionary that specifies options such as the color format, or whether the context should run on the CPU or GPU. For this app, the default values are fine and so you pass in nil for that argument.
2. Calling createCGImage(outputImage:fromRect:) on the context with the supplied CIImage will return a new CGImage instance.
3. Next, you use the UIImage(CGImage:) constructor to create a UIImage from the newly created CGImage instead of directly from the CIImage as before. Note that there is no need to explicitly release the CGImage after we are finished with it, as there would have been in Objective-C. In Swift, ARC can automatically release Core Foundation objects.

Build and run, and make sure it works just as before.

In this example, handling the CIContext creation yourself doesn’t make much difference. But in the next section, you’ll see why this is important for performance, as you implement the ability to modify the filter dynamically!

Changing Filter Values

This is great, but it’s just the beginning of what you can do with Core Image filters. Lets add a slider and set it up so you can adjust the filter settings in real time.

Open Main.storyboard, and drag in a slider, and drop it in below the image view, centered horizontally. With the view selected, navigate to Editor \ Resolve Auto Layout Issues \ Selected Views \ Reset to Suggested Constraints, increasing the width constraint if desired.

Make sure the Assistant Editor is visible and displaying ViewController.swift, then control-drag from the slider down below the previously added @IBOutlet, set the name to amountSlider, and click Connect.

While you’re at it let’s connect the slider to an action method as well. Again control-drag from the slider, this time to just above the closing } of the ViewController class. Set the Connection to Action, the name to amountSliderValueChanged, make sure that the Event is set to Value Changed, and click Connect.

Every time the slider changes, you need to redo the image filter with a different value. However, you don’t want to redo the whole process, that would be very inefficient and would take too long. You’ll need to change a few things in your class so that you hold on to some of the objects you create in your viewDidLoad method.

The biggest thing you want to do is reuse the CIContext whenever you need to use it. If you recreate it each time, your program will run very slowly. The other things you can hold onto are the CIFilter and the CIImage that holds your original image. You’ll need a new CIImage for every output, but the image you start with will stay constant.

You need to add some instance variables to accomplish this task. Add the following three properties to your ViewController class:

var context: CIContext!
var filter: CIFilter!
var beginImage: CIImage!

Note that you have declared these values as implicitly-unwrapped optionals using the ! syntax, because you aren’t going to initialize them until viewDidLoad. You could have used ? instead, but you know that the way the code is designed will prevent the optionals from being nil by the time you use them. The implicitly-unwrapped syntax makes it much easier to read, without all the exclamation marks everywhere.

Change the code in viewDidLoad so it uses these properties instead of declaring new local variables, as follows:

beginImage = CIImage(contentsOfURL: fileURL)
 
filter = CIFilter(name: "CISepiaTone")
filter.setValue(beginImage, forKey: kCIInputImageKey)
filter.setValue(0.5, forKey: kCIInputIntensityKey)
 
let outputImage = filter.outputImage
 
context = CIContext(options:nil)
let cgimg = context.createCGImage(outputImage, fromRect: outputImage.extent())

Now you’ll implement the changeValue method. What you’ll be doing in this method is altering the value of the inputIntensity key in your CIFilter dictionary.

Once you’ve altered this value you’ll need to repeat a few steps:

• Get the output CIImage from the CIFilter.
• Convert the CIImage to a CGImage.
• Convert the CGImage to a UIImage, and display it in the image view.

Replace amountSliderValueChanged(sender:) with the following:

@IBAction func amountSliderValueChanged(sender: UISlider) {
 
    let sliderValue = sender.value
 
    filter.setValue(sliderValue, forKey: kCIInputIntensityKey)
    let outputImage = filter.outputImage
 
    let cgimg = context.createCGImage(outputImage, fromRect: outputImage.extent())
 
    let newImage = UIImage(CGImage: cgimg)
    self.imageView.image = newImage
}

You’ll notice that you’ve changed the argument type from AnyObject to UISlider in the method definition. You know you’ll only be using this method to retrieve values from your UISlider, so you can go ahead and make this change. If you’d left it as AnyObject, you’d need to cast it to a UISlider or the next line would throw an error.

You retrieve the value from the slider (which returns a Float). Your slider is set to the default values – min 0, max 0, default 0.5. How convenient, these happen to be the right values for this CIFilter!

The CIFilter has methods that will allow you to set the values for the different keys in its dictionary. Here, you’re just setting the inputIntensity to whatever you get from your slider. Swift automatically converts the primitive CFloat value into an NSNumber object suitable for use with setValue(value:forKey:).

The rest of the code should look familiar, as it follows the same logic as viewDidLoad. You’re going to be using this code over and over again. From now on, you’ll use amountSliderValueChanged(sender:) to render the output of a CIFilter to your UIImageView.

Build and run, and you should have a functioning live slider that will alter the sepia value for your image in real time!

Getting Photos from the Photo Album

Now that you can change the values of the filter on the fly, things are starting to get real interesting! But what if you don’t care for this image of flowers? Next you’ll set up a UIImagePickerController so you can get pictures from out of the photo album and into your app so you can play with them.

You need to create a button that will bring up the photo album view, so open up Main.storyboard, drag in a button to the bottom right of the scene, and label it “Photo Album”. As before, use Auto Layout to Reset to Suggested Constraints. The button should be underneath the slider on the right side.

Make sure the Assistant Editor is visible and displaying ViewController.swift, then control-drag from the button down to just above the closing } for the ViewController class. Set the Connection to Action, the name to loadPhoto, make sure that the Event is set to Touch Up Inside, and click Connect.

Implement the loadPhoto method as follows:

@IBAction func loadPhoto(sender : AnyObject) {
  let pickerC = UIImagePickerController()
  pickerC.delegate = self
  self.presentViewController(pickerC, animated: true, completion: nil)
}

The first line of code instantiates a new UIImagePickerController. You then set the delegate of the image picker to self (the ViewController).

You get a warning here. You need to declare that ViewController conforms to the UIImagePickerControllerDelegate and UINavigationControllerDelegate protocols.

Still in ViewController.swift, change the class definition at the top of the file as follows:

class ViewController: UIViewController, UINavigationControllerDelegate, UIImagePickerControllerDelegate {

Now implement the following method:

func imagePickerController(picker: UIImagePickerController!, didFinishPickingMediaWithInfo info: NSDictionary!) {
  self.dismissViewControllerAnimated(true, completion: nil);
  println(info);
}

This UIImagePickerControllerDelegate method isn’t completed yet – it’s just a placeholder to log some information about the chosen image. Note that whenever you implement any of the UIImagePickerControllerDelegate methods, you have to dismiss the UIImagePickerController explicitly in your implementation. If you don’t, then you’ll just stare at the image picker forever!

Build and run the app, and tap the button. It will bring up the image picker with the photos in your photo album.

Here’s what you should see in the console after you’ve selected an image (something like this):

{
UIImagePickerControllerMediaType = "public.image";
UIImagePickerControllerOriginalImage = " size {1165, 770} orientation 0 scale 1.000000";
UIImagePickerControllerReferenceURL = "assets-library://asset/asset.PNG?id=DCFE1435-2C01-4820-9182-40A69B48EA67&ext=PNG";
}

Note that it has an entry in the dictionary for the “original image” selected by the user. This is what you want to pull out and filter!

Now that you’ve got a way to select an image, how do you use that as your beginImage?

Simple, just update the delegate method to look like this:

func imagePickerController(picker: UIImagePickerController!, didFinishPickingMediaWithInfo info: NSDictionary!) {
  self.dismissViewControllerAnimated(true, completion: nil);
 
  let gotImage = info[UIImagePickerControllerOriginalImage] as UIImage
 
  beginImage = CIImage(image:gotImage)
  filter.setValue(beginImage, forKey: kCIInputImageKey)
  self.amountSliderValueChanged(amountSlider)
}

You need to create a new CIImage from your selected photo. You can get the UIImage representation of the photo by finding it in the dictionary of values, under the UIImagePickerControllerOriginalImage key constant. Note that it’s better to use a constant for this, rather than a hardcoded string, because Apple could change the name of the key in the future.

You need to convert the image into a CIImage object with the CIImage(image:) constructor. You then set the key in the filter dictionary so that the input image is the new CIImage you just created.

The last line may seem odd. Remember how I pointed out that the code in changeValue ran the filter with the latest value and updated the image view with the result?

Well you need to do that again, so you can just call changeValue. Even though the slider value hasn’t changed, you can still use that method’s code to get the job done. You could break that code into its own method (and if you were going to be working with more complexity, you would, to avoid confusion), but in this case your purpose is served by re-using the amountSliderValueChanged method. Pass in the amountSlider as the sender so that it has the correct value to use.

Build and run, and now you’ll be able to update any image from your photo album!

What if you create the perfect sepia image, how do you hold on to it? You could take a screenshot, but the proper way is to save the filtered photo back into the photo album.

Saving to Photo Album

To save to the photo album, you need to use the AssetsLibrary framework. Add the following import statement to the top of ViewController.swift:

import AssetsLibrary

One thing you should know is that when you save a photo to the album, it may take a few seconds, and that process could continue even after you close the app.

This could be a problem, as the GPU stops whatever it’s doing when you switch from one app to another. If the photo hasn’t finished saving, it won’t be there when you go looking for it later!

The solution to this is to use a CPU-based CIContext for rendering. The default behavior is to use the GPU because it’s much faster, and you don’t want to slow down the filtering performance for the sake of adding save functionality. Instead, you will create a second CIContext to use for saving the image. Note that the software renderer won’t work properly in the simulator.

Add a new button to your app that will let you save the photo you are currently modifying with all the changes you’ve made. Open Main.storyboard, add a new button labeled “Save to Album”. Place the button under the slider on the left side, and add the suggested constraints.

Then connect it to a new savePhoto(sender:) method, like you did last time, and implement the method as follows:

@IBAction func savePhoto(sender: AnyObject) {
    // 1
    let imageToSave = filter.outputImage
 
    // 2
    let softwareContext = CIContext(options:[kCIContextUseSoftwareRenderer: true])
 
    // 3
    let cgimg = softwareContext.createCGImage(imageToSave, fromRect:imageToSave.extent())
 
    // 4
    let library = ALAssetsLibrary()
    library.writeImageToSavedPhotosAlbum(cgimg,
      metadata:imageToSave.properties(),
      completionBlock:nil)
}

In this code block you:

1. Get the CIImage output from the filter.
2. Create a new, software based CIContext that uses the CPU renderer.
3. Generate the CGImage.
4. Save the CGImage to the photo library.

Build and run the app (remember to run on an actual device, since you’re using software rendering), and now you can save that “perfect image” to your photo library so it’s preserved forever!

What About Image Metadata?

Let’s talk about image metadata for a moment. Image files taken on mobile phones have a variety of data associated with them, such as GPS coordinates, image format, and orientation.

Orientation in particular is something that you’ll need to preserve. The process of loading a UIImage into a CIImage, rendering to a CGImage, and converting back to a UIImage strips the metadata from the image. In order to preserve orientation, you’ll need to record it and then pass it back into the UIImage constructor.

Start by adding a new property inside the ViewController class definition:

var orientation: UIImageOrientation = .Up

Next, add the following line to imagePickerController(picker:didFinishPickingMediaWithInfo:) just before setting beginImage:

orientation = gotImage.imageOrientation

This will save the original image orientation to the property.

Finally, alter the line in amountSliderValueChanged that creates the UIImage that you set to the imageView object:

let newImage = UIImage(CGImage: cgimg, scale:1, orientation:orientation)

Now, if you take a picture taken in something other than the default orientation, it will be preserved.

What Other Filters are Available?

The CIFilter API has more than 160 filters on Mac OS, 126 of which are available on iOS 8. As of iOS 8, it is now possible to create you own custom filters as well.

In order to find out what filters are available on a given device, you can use the CIFilter method filterNamesInCategory(kCICategoryBuiltIn). This method will return an array of filter names.

In addition, each filter has an attributes() method that will return a dictionary containing information about that filter. This information includes the filter’s name and category, the kinds of inputs the filter takes, and the default and acceptable values for those inputs.

Let’s put together a method for your class that logs the information for all the currently available filters. Add this method inside the ViewController class definition:

func logAllFilters() {
  let properties = CIFilter.filterNamesInCategory(kCICategoryBuiltIn)
  println(properties)
 
  for filterName: AnyObject in properties {
    let fltr = CIFilter(name:filterName as String)
    println(fltr.attributes())
  }
}

This method simply gets the array of filters from filterNamesInCategory(). It prints the list of names first. Then, for each name in the list, it instantiates the filter and logs its attributes dictionary.

Call this method at the end of viewDidLoad():

self.logAllFilters()

You will see the many filters listed in the console like the following:

[CIAttributeFilterDisplayName: Color Monochrome, inputColor: {
    CIAttributeClass = CIColor;
    CIAttributeDefault = "(0.6 0.45 0.3 1)";
    CIAttributeType = CIAttributeTypeColor;
}, inputImage: {
    CIAttributeClass = CIImage;
    CIAttributeType = CIAttributeTypeImage;
}, CIAttributeFilterCategories: (
    CICategoryColorEffect,
    CICategoryVideo,
    CICategoryInterlaced,
    CICategoryNonSquarePixels,
    CICategoryStillImage,
    CICategoryBuiltIn
), inputIntensity: {
    CIAttributeClass = NSNumber;
    CIAttributeDefault = 1;
    CIAttributeIdentity = 0;
    CIAttributeSliderMax = 1;
    CIAttributeSliderMin = 0;
    CIAttributeType = CIAttributeTypeScalar;
}, CIAttributeFilterName: CIColorMonochrome]

Wow, that’s a lot of filters! That should give you some ideas for other filters to try out in your own app!

More Intricate Filter Chains

Now that we’ve looked at all the filters that are available on the iOS platform, it’s time to create a more intricate filter chain. In order to do this, you’ll create a dedicated method to process the CIImage. It will take a CIImage, filter it to look like an old aged photo, and return a modified CIImage.

Add the following method to ViewController:

func oldPhoto(img: CIImage, withAmount intensity: Float) -> CIImage {
  // 1
  let sepia = CIFilter(name:"CISepiaTone")
  sepia.setValue(img, forKey:kCIInputImageKey)
  sepia.setValue(intensity, forKey:"inputIntensity")
 
  // 2
  let random = CIFilter(name:"CIRandomGenerator")
 
  // 3
  let lighten = CIFilter(name:"CIColorControls")
  lighten.setValue(random.outputImage, forKey:kCIInputImageKey)
  lighten.setValue(1 - intensity, forKey:"inputBrightness")
  lighten.setValue(0, forKey:"inputSaturation")
 
  // 4
  let croppedImage = lighten.outputImage.imageByCroppingToRect(beginImage.extent())
 
  // 5
  let composite = CIFilter(name:"CIHardLightBlendMode")
  composite.setValue(sepia.outputImage, forKey:kCIInputImageKey)
  composite.setValue(croppedImage, forKey:kCIInputBackgroundImageKey)
 
  // 6
  let vignette = CIFilter(name:"CIVignette")
  vignette.setValue(composite.outputImage, forKey:kCIInputImageKey)
  vignette.setValue(intensity * 2, forKey:"inputIntensity")
  vignette.setValue(intensity * 30, forKey:"inputRadius")
 
  // 7
  return vignette.outputImage
}

Here’s what’s going on, section by section:

1. Set up the sepia filter the same way you did in the simpler scenario. You’re passing in a Float value in the method to set the intensity of the sepia effect. This value will be provided by the slider.
2. Set up a filter that creates a random noise pattern that looks like this:It doesn’t take any parameters. You’ll use this noise pattern to add texture to your final “old photo” look.
3. Alter the output of the random noise generator. You want to change it to grayscale, and lighten it up a little bit so the effect is less dramatic. You’ll notice that the input image key is set to the outputImage property of the random filter. This is a convenient way to pass the output of one filter as the input of the next.
4. imageByCroppingToRect() takes an output CIImage and crops it to the provided rect. In this case, you need to crop the output of the CIRandomGenerator filter because it tiles infinitely. If you don’t crop it at some point, you’ll get an error saying that the filters have ‘an infinite extent’. CIImages don’t actually contain image data, they describe a ‘recipe’ for creating it. It’s not until you call a method on the CIContext that the data is actually processed.
5. Combine the output of the sepia filter with the output of the CIRandomGenerator filter. This filter performs the exact same operation as the ‘Hard Light’ setting does in a photoshop layer. Most (if not all) of the filter options in photoshop are achievable using Core Image.
6. Run a vignette filter on this composited output that darkens the edges of the photo. You’re using the value from the slider to set the radius and intensity of this effect.
7. Finally, return the output of the last filter.

That’s all for this filter chain. You should now have an idea of how complex these filter chains may become. By combining Core Image filters into these kinds of chains, you can achieve an endless variety of effects.

The next thing to do is implement this method in amountSliderValueChanged(). Change these two lines:

filter.setValue(sliderValue, forKey: "inputIntensity")
let outputImage = filter.outputImage

To this one line:

let outputImage = self.oldPhoto(beginImage, withAmount: sliderValue)

This just replaces the previous sepia effect with your new, more complex filter method. You pass in the slider value for the intensity and you use the beginImage, which you set in the viewDidLoad method as the input CIImage. Build and run now and you should get a more refined old photo effect, complete with sepia, a little noise, and some vignetting.

That noise could probably be more subtle, but I’ll leave that experiment to you, dear reader. Now you have the full power of Core Image at your disposal. Go crazy!

Where To Go From Here?

Here is the example project with all of the code from the above tutorial.

That about covers the basics of using Core Image filters. It’s a pretty handy technique, and you should be able to use it to apply some neat filters to images quite quickly!

Remember, the sample app prints out a list of all the available filters to the console when it starts up. Why not try playing around with some of those? You can check out the Core Image filter reference documentation for notes on all the filters.

If you have any questions or comments on this tutorial or Core Image in general, please join the forum discussion below!

Beginning Core Image in Swift is a post from: Ray Wenderlich

The post Beginning Core Image in Swift appeared first on Ray Wenderlich.

This is the second and final part of a tutorial that teaches you how to create an app like RunKeeper, complete with color-coded maps and badges!

In the first section of the tutorial, you created an app that:

• Uses Core Location to track your route
• Continually maps your path and reports your average pace as you run
• Shows a map of your route when the run is complete; the map line is color-coded so that the slower portions are red and the faster portions are green.

That app is great for recording and displaying data, but to spark that motivation, sometimes you just need a little more of a nudge than a pretty map can provide.

So in this section, you’ll complete the demo MoonRunner app with a badge system that embodies the concept that fitness is a fun and progress-based achievement. Here’s how it works:

• A list maps out checkpoints of increasing distance to motivate the user.
• As the user runs, they can see a thumbnail of the next upcoming badge and the remaining distance to it.
• The first time a user has a run reaching a certain checkpoint, the app awards a badge and notes that run’s average speed.
• From there, silver and gold versions of the badge are awarded for reaching the checkpoint again at a proportionally faster speed.
• The post-run map displays a dot at each checkpoint along the path, with a custom callout showing the badge name and image.

Getting Started

Your creativity is the limit when it comes to the theme your badges might take. But I just finished watching the new Cosmos television series, so I was inspired to make all these badges planets, moons, or other milestones in our Solar System. How cosmic!

You already downloaded the MoonRunner resource pack in part one and added it to your project. Notice that the pack also contains quite a few images and a file named badges.txt. Open badges.txt. Notice that it contains a large JSON array of badge objects. Each badge object contains:

• A name
• A piece of cool/interesting information about the badge
• The distance in meters to achieve this badge
• The filename of the corresponding image in the resource pack

The badges go all the way from 0 meters — hey, you have to start somewhere — up to the length of a full marathon. Of course, some people choose to go even further on ultra-marathons, and you can consider those ambitious runners as having entered interstellar space.

So the first task is to parse the JSON text into an array of objects. Select File\New\File and the iOS\Cocoa Touch\Objective-C class to create a class Badge that extends NSObject.

Then edit Badge.h to match the following:

#import <Foundation/Foundation.h>
 
@interface Badge : NSObject
 
@property (strong, nonatomic) NSString *name;
@property (strong, nonatomic) NSString *imageName;
@property (strong, nonatomic) NSString *information;
@property float distance;
 
@end

Now you have your Badge object, and it’s time to parse the source JSON. Create a new class BadgeController extending NSObject, and edit the header as follows:

#import <Foundation/Foundation.h>
 
@interface BadgeController : NSObject
 
+ (BadgeController *)defaultController;
 
@end

This class will have a single instance, created once and accessed with defaultController. Open BadgeController.m. Replace the file contents with the following code:

#import "BadgeController.h"
#import "Badge.h"
 
@interface BadgeController ()
 
@property (strong, nonatomic) NSArray *badges;
 
@end
 
@implementation BadgeController
 
+ (BadgeController *)defaultController
{   
    static BadgeController *controller = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        controller = [[BadgeController alloc] init];
        controller.badges = [self badgeArray];
    });
 
    return controller;
}
 
+ (NSArray *)badgeArray
{
    NSString *filePath = [[NSBundle mainBundle] pathForResource:@"badges" ofType:@"txt"];
    NSString *jsonContent = [NSString stringWithContentsOfFile:filePath usedEncoding:nil error:nil];
    NSData *data = [jsonContent dataUsingEncoding:NSUTF8StringEncoding];
    NSArray *badgeDicts = [NSJSONSerialization JSONObjectWithData:data options:0 error:nil];
 
    NSMutableArray *badgeObjects = [NSMutableArray array];
 
    for (NSDictionary *badgeDict in badgeDicts) {
        [badgeObjects addObject:[self badgeForDictionary:badgeDict]];
    }
 
    return badgeObjects;
}
 
+ (Badge *)badgeForDictionary:(NSDictionary *)dictionary
{
    Badge *badge = [Badge new];
    badge.name = [dictionary objectForKey:@"name"];
    badge.information = [dictionary objectForKey:@"information"];
    badge.imageName = [dictionary objectForKey:@"imageName"];
    badge.distance = [[dictionary objectForKey:@"distance"] floatValue];
    return badge;
}
 
@end

There are three methods here that all work together:

1. defaultController is publicly accessible, delivers a single instance of the controller, and makes sure the parsing operation happens only once.
2. badgeArray extracts an array from the text file and creates an object from each element of the array.
3. badgeForDictionary: does the actual mapping of JSON keys to the Badge object.

And with that, you’re all set to retrieve the badge data. Time to get that data incorporated into your app!

The Badge Storyboards

What’s the good of winning all these badges if you can’t keep them in a nice glass case and marvel at them every once in a while? Or maybe you’re a little more modest and you just say you want to “keep track” of them. :]

In any case, it’s time to add some UI to your storyboards to view badges. Open Main.storyboard. Drag a new table view controller onto the storyboard and control-drag from the Badges button on the Home Screen to create a push segue:

Next, select the table view inside the table view controller you just added and open the size inspector. Increase the Row Height of the table to 80 points. Then select the prototype cell in the table view and open the attributes inspector. Set the Style to Custom and Identifier to BadgeCell.

Inside the cell, set the customary MoonRunner black background and add a large UIImageView on the left side. Add two smaller UIImageViews with the spaceship-gold and spaceship-silver assets just to its right. Then add two UILabels. Use the screenshot below to help you design the cell:

Each badge will occupy one of these cells, with its image on the left and a description of when you earned the badge, or what you need to do to earn it. The two small UIImageViews are for the silver and gold spaceship icons, in case the user earned those levels.

Next, drag in a new view controller (normal one, not table view controller this time) onto the storyboard. Then control-drag from the table view cell in the table view controller you just added to this new view controller, and select push selection segue.

Then style this new screen to look like this:

On this detail screen, you’ll see:

• A large UIImageView to show off the badge image — some of these photos from space are stunning
• A small UIButton on top of the UIImageView, using the info image as a background.
• A UILabel for the badge Name
• A UILabel for the badge Distance
• A UILabel for the date the badge was Earned
• A UILabel for the Best average pace for this distance
• A UILabel for the date the user earned the Silver version of the badge (or the pace needed to earn it, if they have yet to do so)
• The same for the Gold version of the badge
• Two small UIImageViews with the spaceship-gold and spaceship-silver assets.

The badge information is important because it gives the users a little context, placing their accomplishment in a sort of story or map. The badge images, however small, serve as an extra little reward.

Earning The Badge

You’ve already created the Badge object, and now you need an object to store when a badge was earned. This object will associate a Badge with the various Run objects, if any, where the user achieved versions of this badge.

Click File\New\File. Select iOS\Cocoa Touch\Objective-C class. Call the class BadgeEarnStatus, extending NSObject, and save the file. Then open BadgeEarnStatus.h and replace its contents with the following:

#import <Foundation/Foundation.h>
 
@class Badge;
@class Run;
 
@interface BadgeEarnStatus : NSObject
 
@property (strong, nonatomic) Badge *badge;
@property (strong, nonatomic) Run *earnRun;
@property (strong, nonatomic) Run *silverRun;
@property (strong, nonatomic) Run *goldRun;
@property (strong, nonatomic) Run *bestRun;
 
@end

Then open BadgeEarnStatus.m and add the following imports at the top of the file:

#import "Badge.h"
#import "Run.h"

Now that you have an easy way to associate a Badge with a Run, it’s time to build the logic to make those associations. Open BadgeController.h and add the following constants at the top of the file:

extern float const silverMultiplier;
extern float const goldMultiplier;

Then add the following instance method to the interface:

- (NSArray *)earnStatusesForRuns:(NSArray *)runArray;

The constants silverMultiplier and goldMultiplier will be available to other classes. They are the factors by which a user has to speed up to earn those versions of the badge.

Open BadgeController.m and add the following imports and constant definitions at the top of the file:

#import "BadgeEarnStatus.h"
#import "Run.h"
 
float const silverMultiplier = 1.05; // 5% speed increase
float const goldMultiplier = 1.10; // 10% speed increase

Then, add the following method to the implementation:

- (NSArray *)earnStatusesForRuns:(NSArray *)runs {
    NSMutableArray *earnStatuses = [NSMutableArray array];
 
    for (Badge *badge in self.badges) {
 
        BadgeEarnStatus *earnStatus = [BadgeEarnStatus new];
        earnStatus.badge = badge;
 
        for (Run *run in runs) {
 
            if (run.distance.floatValue > badge.distance) {
 
                // this is when the badge was first earned
                if (!earnStatus.earnRun) {
                    earnStatus.earnRun = run;
                }
 
                double earnRunSpeed = earnStatus.earnRun.distance.doubleValue / earnStatus.earnRun.duration.doubleValue;
                double runSpeed = run.distance.doubleValue / run.duration.doubleValue;
 
                // does it deserve silver?
                if (!earnStatus.silverRun
                    && runSpeed > earnRunSpeed * silverMultiplier) {
 
                    earnStatus.silverRun = run;
                }
 
                // does it deserve gold?
                if (!earnStatus.goldRun
                    && runSpeed > earnRunSpeed * goldMultiplier) {
 
                    earnStatus.goldRun = run;
                }
 
                // is it the best for this distance?
                if (!earnStatus.bestRun) {
                    earnStatus.bestRun = run;
 
                } else {
                    double bestRunSpeed = earnStatus.bestRun.distance.doubleValue / earnStatus.bestRun.duration.doubleValue;
 
                    if (runSpeed > bestRunSpeed) {
                        earnStatus.bestRun = run;
                    }
                }
            }
        }
 
        [earnStatuses addObject:earnStatus];
    }
 
    return earnStatuses;
}

This method compares all the user’s runs to the distance requirements for each badge, making the associations and returning all the BadgeEarnStatus objects in an array.

To do this, the first time a user reaches the badge it finds a earnRunSpeed, which becomes a reference to see if the user improved enough to qualify for the silver or gold versions.

Think of it this way – you’ll still have a chance at earning the gold version of the Mars badge, even if your friend is much faster every time. As long as you’re both making progress, you both win.

Displaying the Badges

Now it’s time to bring all this badge logic and UI together for the user. You’re going to create two view controllers and one custom table cell in order to link the storyboards with the badge data.

First, create a new class called BadgeCell extending UITableViewCell. Open BadgeCell.h and make it look like this:

#import <UIKit/UIKit.h>
 
@interface BadgeCell : UITableViewCell
 
@property (nonatomic, weak) IBOutlet UILabel *nameLabel;
@property (nonatomic, weak) IBOutlet UILabel *descLabel;
@property (nonatomic, weak) IBOutlet UIImageView *badgeImageView;
@property (nonatomic, weak) IBOutlet UIImageView *silverImageView;
@property (nonatomic, weak) IBOutlet UIImageView *goldImageView;
 
@end

Now you have a custom cell to use in the table view controller for badges you added earlier.

Next, create a class named BadgesTableViewController extending UITableViewController. Open BadgesTableViewController.h and make it look like this:

#import <UIKit/UIKit.h>
 
@interface BadgesTableViewController : UITableViewController
 
@property (strong, nonatomic) NSArray *earnStatusArray;
 
@end

The earnStatusArray will be the result of calling earnStatusesForRuns: in the BadgeController — the method you added earlier to calculate badge statuses.

Open BadgesTableViewController.m and add the following imports to the top of the file:

#import "BadgeEarnStatus.h"
#import "BadgeCell.h"
#import "Badge.h"
#import "MathController.h"
#import "Run.h"

Then add the following properties to the class extension category:

@interface BadgesTableViewController ()
 
@property (strong, nonatomic) UIColor *redColor;
@property (strong, nonatomic) UIColor *greenColor;
@property (strong, nonatomic) NSDateFormatter *dateFormatter;
@property (assign, nonatomic) CGAffineTransform transform;
 
@end

These are a few properties that will be used throughout the table view controller. The colors will be used to color each cell according to whether or not the badge has been earned, for example.

Find viewDidLoad in the implementation and make it look like this:

- (void)viewDidLoad
{
    [super viewDidLoad];
 
    self.redColor = [UIColor colorWithRed:1.0f green:20/255.0 blue:44/255.0 alpha:1.0f];
    self.greenColor = [UIColor colorWithRed:0.0f green:146/255.0 blue:78/255.0 alpha:1.0f];
    self.dateFormatter = [[NSDateFormatter alloc] init];
    [self.dateFormatter setDateStyle:NSDateFormatterMediumStyle];
    self.transform = CGAffineTransformMakeRotation(M_PI/8);
}

This sets up the properties you just added. The properties are essentially caches so that each time a new cell is created you don’t need to recreate the required properties over and over. Date formatters are especially expensive to create and therefore a good idea to cache if you can.

Next, remove the implementations of tableView:numberOfRowsInSection: and numberOfSectionsInTableView:. Then add the following methods:

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
    return self.earnStatusArray.count;
}
 
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    BadgeCell *cell = [tableView dequeueReusableCellWithIdentifier:@"BadgeCell" forIndexPath:indexPath];
    BadgeEarnStatus *earnStatus = [self.earnStatusArray objectAtIndex:indexPath.row];
 
    cell.silverImageView.hidden = !earnStatus.silverRun;
    cell.goldImageView.hidden = !earnStatus.goldRun;
 
    if (earnStatus.earnRun) {
        cell.nameLabel.textColor = self.greenColor;
        cell.nameLabel.text = earnStatus.badge.name;
        cell.descLabel.textColor = self.greenColor;
        cell.descLabel.text = [NSString stringWithFormat:@"Earned: %@", [self.dateFormatter stringFromDate:earnStatus.earnRun.timestamp]];
        cell.badgeImageView.image = [UIImage imageNamed:earnStatus.badge.imageName];
        cell.silverImageView.transform = self.transform;
        cell.goldImageView.transform = self.transform;
        cell.userInteractionEnabled = YES;
    } else {
        cell.nameLabel.textColor = self.redColor;
        cell.nameLabel.text = @"?????";
        cell.descLabel.textColor = self.redColor;
        cell.descLabel.text = [NSString stringWithFormat:@"Run %@ to Earn", [MathController stringifyDistance:earnStatus.badge.distance]];
        cell.badgeImageView.image = [UIImage imageNamed:@"question_badge.png"];
        cell.userInteractionEnabled = NO;
    }
 
    return cell;
}

These methods tell the table view how many rows to show (the number of badges) and how to set up each cell. As you can see, every cell depends on if the user earned the badge, among other things. Also, the cell can only be selected if the badge has been earned, through the use of userInteractionEnabled.

Now you need to make the badges table view controller have some data to work with. Open HomeViewController.m and add these imports at the top of the file:

#import "BadgesTableViewController.h"
#import "BadgeController.h"

Add this property to the class extension category:

@property (strong, nonatomic) NSArray *runArray;

Now add the following method:

- (void)viewWillAppear:(BOOL)animated
{
    [super viewWillAppear:animated];
 
    NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
    NSEntityDescription *entity = [NSEntityDescription
                                   entityForName:@"Run" inManagedObjectContext:self.managedObjectContext];
    [fetchRequest setEntity:entity];
 
    NSSortDescriptor *sortDescriptor = [[NSSortDescriptor alloc] initWithKey:@"timestamp" ascending:NO];
    [fetchRequest setSortDescriptors:@[sortDescriptor]];
 
    self.runArray = [self.managedObjectContext executeFetchRequest:fetchRequest error:nil];
}

This will have the effect of refreshing the run array every time the view controller appears. It does this using a Core Data fetch to fetch all the runs sorted by timestamp.

Finally, add to prepareForSegue:sender: so it looks like this:

- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
    UIViewController *nextController = [segue destinationViewController];
    if ([nextController isKindOfClass:[NewRunViewController class]]) {
        ((NewRunViewController *) nextController).managedObjectContext = self.managedObjectContext;
    } else if ([nextController isKindOfClass:[BadgesTableViewController class]]) {
        ((BadgesTableViewController *) nextController).earnStatusArray = [[BadgeController defaultController] earnStatusesForRuns:self.runArray];
    }
}

Here, when the badges table view controller is being pushed onto the navigation stack, the earn status of all badges is calculated and passed to the badge table view controller.

Now it’s time to connect all your outlets in the storyboard. Open Main.storyboard and do the following:

• Set the classes of BadgeCell and BadgesTableViewController

.

• Connect the outlets of BadgeCell: nameLabel, descLabel, badgeImageView, silverImageView, and goldImageView

.

Build &run and check out your new badges! You should see something like this:

You will only have the ‘Earth’ badge currently – but it’s a start! Now to grab some more badges!

What Does A Runner Have To Do To Get A Gold Medal Around Here?

The last view controller for MoonRunner is the one that shows the details of a badge. Create a new class called BadgeDetailsViewController, extending from UIViewController. Open BadgeDetailsViewController.h and replace its contents with the following:

#import <UIKit/UIKit.h>
 
@class BadgeEarnStatus;
 
@interface BadgeDetailsViewController : UIViewController
 
@property (strong, nonatomic) BadgeEarnStatus *earnStatus;
 
@end

Then open BadgesTableViewController.m. Add the following import at the top of the file:

#import "BadgeDetailsViewController.h"

And add the following method:

- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
    if ([[segue destinationViewController] isKindOfClass:[BadgeDetailsViewController class]]) {
        NSIndexPath *indexPath = [self.tableView indexPathForSelectedRow];
        BadgeEarnStatus *earnStatus = [self.earnStatusArray objectAtIndex:indexPath.row];
        [(BadgeDetailsViewController *)[segue destinationViewController] setEarnStatus:earnStatus];
    }
}

This sets up the segue for when a cell is tapped. It hands over the relevant BadgeEarnStatus instance for the detail view controller to display.

Open BadgeDetailsViewController.m, and add the following imports at the top of the file:

#import "BadgeEarnStatus.h"
#import "Badge.h"
#import "MathController.h"
#import "Run.h"
#import "BadgeController.h"

Then add the following properties to the class extension category:

@interface BadgeDetailsViewController ()
 
@property (nonatomic, weak) IBOutlet UIImageView *badgeImageView;
@property (nonatomic, weak) IBOutlet UILabel *nameLabel;
@property (nonatomic, weak) IBOutlet UILabel *distanceLabel;
@property (nonatomic, weak) IBOutlet UILabel *earnedLabel;
@property (nonatomic, weak) IBOutlet UILabel *silverLabel;
@property (nonatomic, weak) IBOutlet UILabel *goldLabel;
@property (nonatomic, weak) IBOutlet UILabel *bestLabel;
@property (nonatomic, weak) IBOutlet UIImageView *silverImageView;
@property (nonatomic, weak) IBOutlet UIImageView *goldImageView;
 
@end

These are all IBOutlets to the UI.

Now find viewDidLoad and make it look like this:

- (void)viewDidLoad
{
    [super viewDidLoad];
 
    NSDateFormatter *formatter = [[NSDateFormatter alloc] init];
    [formatter setDateStyle:NSDateFormatterMediumStyle];
 
    CGAffineTransform transform = CGAffineTransformMakeRotation(M_PI/8);
 
    self.nameLabel.text = self.earnStatus.badge.name;
    self.distanceLabel.text = [MathController stringifyDistance:self.earnStatus.badge.distance];
    self.badgeImageView.image = [UIImage imageNamed:self.earnStatus.badge.imageName];
    self.earnedLabel.text = [NSString stringWithFormat:@"Reached on %@" , [formatter stringFromDate:self.earnStatus.earnRun.timestamp]];
 
    if (self.earnStatus.silverRun) {
        self.silverImageView.transform = transform;
        self.silverImageView.hidden = NO;
        self.silverLabel.text = [NSString stringWithFormat:@"Earned on %@" , [formatter stringFromDate:self.earnStatus.silverRun.timestamp]];
 
    } else {
        self.silverImageView.hidden = YES;
        self.silverLabel.text = [NSString stringWithFormat:@"Pace < %@ for silver!", [MathController stringifyAvgPaceFromDist:(self.earnStatus.earnRun.distance.floatValue * silverMultiplier) overTime:self.earnStatus.earnRun.duration.intValue]];
    }
 
    if (self.earnStatus.goldRun) {
        self.goldImageView.transform = transform;
        self.goldImageView.hidden = NO;
        self.goldLabel.text = [NSString stringWithFormat:@"Earned on %@" , [formatter stringFromDate:self.earnStatus.goldRun.timestamp]];
 
    } else {
        self.goldImageView.hidden = YES;
        self.goldLabel.text = [NSString stringWithFormat:@"Pace < %@ for gold!", [MathController stringifyAvgPaceFromDist:(self.earnStatus.earnRun.distance.floatValue * goldMultiplier) overTime:self.earnStatus.earnRun.duration.intValue]];
    }
 
    self.bestLabel.text = [NSString stringWithFormat:@"Best: %@, %@", [MathController stringifyAvgPaceFromDist:self.earnStatus.bestRun.distance.floatValue overTime:self.earnStatus.bestRun.duration.intValue], [formatter stringFromDate:self.earnStatus.bestRun.timestamp]];
}

This code sets up the badge image and puts all the data about the badge earning into the labels.

The most interesting parts are the prompts that tell the user how much they need to speed up to earn the coveted silver and gold badges. I’ve found these prompts to be very motivating, as the pace is always an improvement that requires effort but is obviously possible.

Finally, add the following method:

- (IBAction)infoButtonPressed:(UIButton *)sender
{
    UIAlertView *alertView = [[UIAlertView alloc]
                              initWithTitle:self.earnStatus.badge.name
                              message:self.earnStatus.badge.information
                              delegate:nil
                              cancelButtonTitle:@"OK"
                              otherButtonTitles:nil];
    [alertView show];
}

This will be invoked when the info button is pressed. It shows a pop-up with the badge’s information.

Great! Now the code side of the badge UI is all set. Open Main.storyboard and make the following connections:

• Set the BadgeDetailsViewController class.
• Connect the outlets of BadgeDetailsViewController: badgeImageView, bestLabel, distanceLabel, earnedLabel, goldImageView, goldLabel, nameLabel, silverImageLabel, and silverLabel.
• The received action infoButtonPressed: to BadgeDetailsView.

Now build & run and check out your new badge details!

Carrot Motivation

Along with the new portion of the app devoted to badges, you need to go back through the UI of the existing app and update it to incorporate the badges!

Open Main.storyboard and find the ‘New Run’ view controller. Add a UIImageView and a UILabel to its view, somewhere above the Stop button. It should now look like this:

These will be used as a “carrot-on-a-stick” type motivator for the user as they run, giving them a sneak peak at the next badge and how much farther away it is.

Before you can hook up the UI, you need to add a couple methods to BadgeController to determine which badge is best for a certain distance, and which one is coming up next.

Open BadgeController.h and add the following method declarations to the interface:

- (Badge *)bestBadgeForDistance:(float)distance;
- (Badge *)nextBadgeForDistance:(float)distance;

Also add this line above the interface, just below the imports:

@class Badge;

Now open BadgeController.m and implement those methods like this:

- (Badge *)bestBadgeForDistance:(float)distance {
    Badge *bestBadge = self.badges.firstObject;
    for (Badge *badge in self.badges) {
        if (distance < badge.distance) {
            break;
        }
        bestBadge = badge;
    }
    return bestBadge;
}
 
- (Badge *)nextBadgeForDistance:(float)distance {
    Badge *nextBadge;
    for (Badge *badge in self.badges) {
        nextBadge = badge;
        if (distance < badge.distance) {
            break;
        }
    }
    return nextBadge;
}

These are fairly straightforward — they each take an input, distance in meters, and return either:

• bestBadgeForDistance: The badge that was last won.
• nextBadgeForDistance: The badge that is next to be won.

Now open NewRunViewController.m and add the following imports at the top of the file:

#import <AudioToolbox/AudioToolbox.h>
#import "BadgeController.h"
#import "Badge.h"

The badge-related imports are obviously needed, and the AudioToolbox import is so that a sound can be played every time you earn a new badge.

Add these three properties to the class extension category:

@property (nonatomic, strong) Badge *upcomingBadge;
@property (nonatomic, weak) IBOutlet UILabel *nextBadgeLabel;
@property (nonatomic, weak) IBOutlet UIImageView *nextBadgeImageView;

Then find viewWillAppear: and add the following code at the end of the method:

self.nextBadgeLabel.hidden = YES;
self.nextBadgeImageView.hidden = YES;

Just like the other views, the badge label and badge image need to start out hidden.

Then find startPressed: and add the following code at the end of the method:

self.nextBadgeImageView.hidden = NO;
self.nextBadgeLabel.hidden = NO;

This ensures that the badge label and badge image show up when the run starts.

Now find eachSecond and add the following code at the end of the method:

self.nextBadgeLabel.text = [NSString stringWithFormat:@"%@ until %@!", [MathController stringifyDistance:(self.upcomingBadge.distance - self.distance)], self.upcomingBadge.name];
[self checkNextBadge];

This makes sure nextBadgeLabel is always up-to-date as the run progresses.

Then, add this new method:

- (void)checkNextBadge
{
    Badge *nextBadge = [[BadgeController defaultController] nextBadgeForDistance:self.distance];
 
    if (self.upcomingBadge
        && ![nextBadge.name isEqualToString:self.upcomingBadge.name]) {
 
        [self playSuccessSound];
    }
 
    self.upcomingBadge = nextBadge;
    self.nextBadgeImageView.image = [UIImage imageNamed:nextBadge.imageName];
}

This method obtains the next badge using the method you added previously. It checks to see if this badge is new, by comparing the name to the existing upcoming badge store in the upcomingBadge property. If the badge is different, then a success sound is played because that means a new badge had been earned!

You’ll notice that you haven’t implemented playSuccessSound yet. Add the following method:

- (void)playSuccessSound
{
    NSString *path = [NSString stringWithFormat:@"%@%@", [[NSBundle mainBundle] resourcePath], @"/success.wav"];
    SystemSoundID soundID;
    NSURL *filePath = [NSURL fileURLWithPath:path isDirectory:NO];
    AudioServicesCreateSystemSoundID((CFURLRef)CFBridgingRetain(filePath), &soundID);
    AudioServicesPlaySystemSound(soundID);
 
    //also vibrate
    AudioServicesPlaySystemSound(kSystemSoundID_Vibrate);
}

This plays the success sound, but it also vibrates the phone using the system vibrate sound ID. It also helps to vibrate the phone, in case the user is running in a noisy location, like next to a busy road. Or maybe they’ve got their music on and can’t hear the sound anyway!

Open Main.storyboard and find the ‘New Run’ view controller. Connect the IBOutlets for nextBadgeLabel and nextBadgeImageView. Then build & run to watch the label and image update as you run! Stick around for the sound when you pass a new badge!

Everything Is Better When It Has a “Space Mode”

After a run has finished, it would be nice to provide the user with the ability to see the last badge that they earned during that run. Let’s add that!

Open Main.storyboard and find the ‘Run Details’ view controller. Add a UIImageView with the same frame as the existing MKMapView (directly on top of it). Then add a UIButton with the info image on it, and a UISwitch with an explanatory UILabel above it. The UI should look like this:

Hide the image view you just added by selecting Hidden from the attributes inspector.

This gives your run details a little more personality, with the capability to switch on a “Space Mode” that shows the freshly-earned badge and its information after a run. There’s no feeling quite like finishing a run and finding out you went all the way to Jupiter. :]

Open DetailViewController.m and add the following imports to the top of the file:

#import "Badge.h"
#import "BadgeController.h"

Next, add these two properties to the class extension category:

@property (nonatomic, weak) IBOutlet UIImageView *badgeImageView;
@property (nonatomic, weak) IBOutlet UIButton *infoButton;

Then add the following code to the end of configureView:

Badge *badge = [[BadgeController defaultController] bestBadgeForDistance:self.run.distance.floatValue];
self.badgeImageView.image = [UIImage imageNamed:badge.imageName];

This sets up the badge image view with the image for the badge that was last earned. It does this by fetching the badge that was last earned using the method that you added previously.

Now add the following method:

- (IBAction)displayModeToggled:(UISwitch *)sender
{
    self.badgeImageView.hidden = !sender.isOn;
    self.infoButton.hidden = !sender.isOn;
    self.mapView.hidden = sender.isOn;
}

This will be fired when the switch is toggled. It swaps out the map for the image when the switch is on, i.e. when they are in “Space Mode”!

And finally, add the following method:

- (IBAction)infoButtonPressed
{
    Badge *badge = [[BadgeController defaultController] bestBadgeForDistance:self.run.distance.floatValue];
 
    UIAlertView *alertView = [[UIAlertView alloc]
                              initWithTitle:badge.name
                              message:badge.information
                              delegate:nil
                              cancelButtonTitle:@"OK"
                              otherButtonTitles:nil];
    [alertView show];
}

This will be fired when the info button is pressed. It shows an alert with the badge information.

Now open Main.storyboard and find the ‘Run Details’ view controller. Connect badgeImageView, infoButton, displayModeToggled:, and infoButtonPressed to the views you recently added. Then build & run and bask in the glory of the badge you earn after that long, hard run!

Mapping the Solar System In Your Town

The post-run map already helps you remember your route, and even identify specific areas where your speed was lower. Another helpful feature that would be nice to add is to note exactly when you pass each badge checkpoint, so you can divide up your run.

Annotations are how map views can display point data like this. These are the moving parts you need:

• A class adopting MKAnnotation handles the data side of the annotation. Your class provides a coordinate to allow the map to know where to put the annotation.
• A class extending MKAnnotationView arranges the incoming data from an MKAnnotation into its visual form.

So you’ll begin by arranging the badge data into an array of objects conforming to MKAnnotation. Then you’ll use the MKMapViewDelegate method mapView:viewForAnnotation: to translate that data into MKAnnotationViews.

Create a new class named BadgeAnnotation which extends MKPointAnnotation. Then open BadgeAnnotation.h and replace its contents with the following code:

#import <MapKit/MapKit.h>
 
@interface BadgeAnnotation : MKPointAnnotation
 
@property (strong, nonatomic) NSString *imageName;
 
@end

Then open BadgeController.h and add this method declaration to the interface:

- (NSArray *)annotationsForRun:(Run *)run;

Add this line under the imports in the same file:

@class Run;

Next, open BadgeController.m and add the following imports to the top of the file:

#import <MapKit/MapKit.h>
#import "Location.h"
#import "MathController.h"
#import "BadgeAnnotation.h"

And then add the following method to the implementation:

- (NSArray *)annotationsForRun:(Run *)run
{
    NSMutableArray *annotations = [NSMutableArray array];
 
    int locationIndex = 1;
    float distance = 0;
 
    for (Badge *badge in self.badges) {
        if (badge.distance > run.distance.floatValue) {
            break;
        }
 
        while (locationIndex < run.locations.count) {
 
            Location *firstLoc = [run.locations objectAtIndex:(locationIndex-1)];
            Location *secondLoc = [run.locations objectAtIndex:locationIndex];
 
            CLLocation *firstLocCL = [[CLLocation alloc] initWithLatitude:firstLoc.latitude.doubleValue longitude:firstLoc.longitude.doubleValue];
            CLLocation *secondLocCL = [[CLLocation alloc] initWithLatitude:secondLoc.latitude.doubleValue longitude:secondLoc.longitude.doubleValue];
 
            distance += [secondLocCL distanceFromLocation:firstLocCL];
            locationIndex++;
 
            if (distance >= badge.distance) {
                BadgeAnnotation *annotation = [[BadgeAnnotation alloc] init];
                annotation.coordinate = secondLocCL.coordinate;
                annotation.title = badge.name;
                annotation.subtitle = [MathController stringifyDistance:badge.distance];
                annotation.imageName = badge.imageName;
                [annotations addObject:annotation];
                break;
            }
        }
    }
 
    return annotations;
}

This method loops over all the location points in the run and keeps a cumulative distance for the run. When the cumulative distance passes the next badge’s threshold, a BadgeAnnotation is created. This annotation provides the coordinates of where the badge was earned, the badge’s name, the distance through the run and the badge image name.

Now you have the data ready!

Open DetailViewController.m. Add this import to the top of the file:

#import "BadgeAnnotation.h"

Then, add the following method:

- (MKAnnotationView *)mapView:(MKMapView *)mapView viewForAnnotation:(id < MKAnnotation >)annotation
{
    BadgeAnnotation *badgeAnnotation = (BadgeAnnotation *)annotation;
 
    MKAnnotationView *annView = [mapView dequeueReusableAnnotationViewWithIdentifier:@"checkpoint"];
    if (!annView) {
        annView=[[MKAnnotationView alloc] initWithAnnotation:annotation reuseIdentifier:@"checkpoint"];
        annView.image = [UIImage imageNamed:@"mapPin"];
        annView.canShowCallout = YES;
    }
 
    UIImageView *badgeImageView = [[UIImageView alloc] initWithFrame:CGRectMake(0, 0, 75, 50)];
    badgeImageView.image = [UIImage imageNamed:badgeAnnotation.imageName];
    badgeImageView.contentMode = UIViewContentModeScaleAspectFit;
    annView.leftCalloutAccessoryView = badgeImageView;
 
    return annView;
}

This is part of the MKMapViewDelegate protocol. It is called every time the map wants a view for the given annotation. It’s your job to return a view and the map view will then handle the logic of putting it in the right place on the map.

In this method, you take an incoming annotation and tell the map how to render it. Notice that the title and subtitle properties don’t make an appearance — that rendering happens automatically inside Map Kit.

Then find loadMap and add the following line of code just underneath the call do addOverlays::

[self.mapView addAnnotations:[[BadgeController defaultController] annotationsForRun:self.run]];

With that, you tell the map view to add all the annotations.

Now you can look at your map after a run, and see all the dots that mean you passed a checkpoint! Build & run the app, start and finish a run, and click Save. The map will now have annotations for each badge earned. Click on one, and you can see its name, picture and distance. Neat!

And that’s it! The app is complete! Congratulations on finishing the app.

Where to go From Here

Over the course of this two-part tutorial, you built an app that:

• Measures and tracks your runs using Core Location
• Displays real-time data, like the run’s average pace, along with an active map
• Maps out a run with a color-coded polyline and custom annotations at each checkpoint.
• Awards badges for personal progress in distance and speed.

Ideas to take it to the next level:

• Add a table for a user’s past runs.
• Try using the speeds for segments of a run to earn badges.
  • For example, if you run your fastest 5 km in the middle of a 10 km run, how do you count that towards a silver or gold 5 km badge?
  • Find the average pace between each checkpoint and display it on the MKAnnotationView callout
  • Add badges for lifetime achievements, for instance, running a total of 100 km in a week, 1000 km all-time, etc.
  • Sync a user’s run data with a server.

If you’d like to see how it looks when it’s done, download the full project code here.

Thank you for reading! If you have questions, comments or want to share your successes, please post in the comments below! Happy running through the Solar System! :]

How To Make an App Like RunKeeper: Part 2 is a post from: Ray Wenderlich

The post How To Make an App Like RunKeeper: Part 2 appeared first on Ray Wenderlich.

Episode 9: CloudKit

In this episode, we talk about CloudKit, Apple’s back-end-as-a-service (BaaS) new in iOS 8, along with special guest Mike Katz.

We also talk about the recent discussions about it being difficult to survive as an indie iOS developer.

[Subscribe in iTunes] [RSS Feed]

Here’s what is covered in this episode:

• News: Surviving as an indie iOS developer
• Tech Talk: Cloud Kit

Links and References

Our Sponsor

• Appacitive: Ready to use backend APIs that help you reduce your total development time, giving you more time to innovate on your app.

News

• Jared Sinclair’s sales numbers for Unread
• Ben Thompson on making a business, not an app
• Marco Arment summarizing the issues
• Kickstarter documentary Tammy mentioned

Tech Talk: Cloud Kit

• Mike Katz (author of CloudKit chapters in iOS 8 by Tutorials)
• Designing for CloudKit
• CloudKit Pricing
• Parse
• Amazon Cognito

Contact Us

• Tammy Coron on Twitter
• Jake Gundersen on Twitter
• Felipe Laso Marsetti on Twitter
• Mic Pringle on Twitter
• Email the Podcast Team

Where To Go From Here?

We hope you enjoyed this podcast! We have an episode each month, so be sure to subscribe in iTunes to get access as soon as it comes out.

We’d love to hear what you think about the podcast, and any suggestions on what you’d like to hear in future episodes. Feel free to drop a comment here, or email us anytime at podcast@raywenderlich.com!

CloudKit: The raywenderlich.com Podcast Episode 9 is a post from: Ray Wenderlich

The post CloudKit: The raywenderlich.com Podcast Episode 9 appeared first on Ray Wenderlich.

Authors from raywenderlich.com at Pragma Conference 2014!

This is just a quick note to let you know that we are one of the proud sponsors of Pragma Conference 2014, this October in Milan, Italy.

Two authors from this site will be speaking there, and here’s what they’ll be speaking on:

Cesare Rocchi

Open Source Backends

There are many backend providers. Some are open source and they are actually not that complex to set up and get acquainted with.

In this presentation Cesare will provide an overview of the main open source backends. For each we will walk through the technology they are based on, their setup process, the features they support and the SDKs they include. The goal is to get to know better the twinkling ecosystem of open source backends that is constantly growing everyday.

Getting Started with BaasBox

BaasBox is an open source back end that allows you quickly building the talk-to-the-server part of your application. In this workshop you will learn how to use BaasBox’s iOS SDK and its features.

Marin Todorov

Sprite Kit Workshop

Marin Todorov held a Sprite Kit 101 presentation at the first Pragma Mark conference in 2013; that was less than a month after Sprite Kit was officially released! It was a mix of introduction to Sprite Kit and a live demo of building an Angry Birds clone in 20 minutes. The audience enjoyed this session so much that this year Pragma Mark has invited Marin Todorov for a half a day workshop on Sprite Kit and Swift!

The workshop is guaranteed to be lots of fun, there will be challenges for the ninjas in the audience, and of course Sprite Kit swag to win. If you don’t believe it – just ask people who were there last year :]

Where To Go From Here?

If these talks sound interesting to you, check out the Pragma Conference website. The organizers were kind enough to set up a generous 20% off discount for raywenderlich.com readers – just enter the coupon code PRAGMA-RAY20. Be sure to say hi to Cesare and Marin if you go!

Also stay tuned for our official raywenderlich.com conference, RWDevCon, which comes next February! :]

raywenderlich.com at Pragma Conference 2014 is a post from: Ray Wenderlich

The post raywenderlich.com at Pragma Conference 2014 appeared first on Ray Wenderlich.

Challenge

Your challenge is to make an enum with the three Microsoft CEOs: Bill Gates, Steve Ballmer, and Satya Nadella. Make Satya Nadella the default, and add a description() method. Design your enum so that the following code works:

let currentCEO = MicrosoftCEOs()
println(currentCEO.description())
 
let oFirstCEO = MicrosoftCEOs.fromRaw(1)
if let firstCEO = oFirstCEO {
  println(firstCEO.description())
} else {
  println("No such value")
}

Download demo

Download challenge

Video Tutorial: Introduction to Swift Part 9: Enums is a post from: Ray Wenderlich

The post Video Tutorial: Introduction to Swift Part 9: Enums appeared first on Ray Wenderlich.

Learn how to use the scene and game views in Unity.

Video Tutorial: Introduction to Unity Part 3: Using the Scene and Game Views is a post from: Ray Wenderlich

The post Video Tutorial: Introduction to Unity Part 3: Using the Scene and Game Views appeared first on Ray Wenderlich.

Learn how to create your own game music!

So you’ve built a great game with awesome graphics, rock-solid gameplay, and a creative storyline. What more could you ask for?

Even with all that awesomeness, you’ll find the game lacking without some great in-game music.

Hiring a musician is the best bet of course, but if you don’t have the funds for that, that’s OK too. You can easily make your own game music, using some amazing iPad apps!

One such app I really like and personally use is Korg Gadget for iPad. It collects 15 mobile synthesizers and drum machines into a single app and wraps them all with an easy-to-use sequencer.

The only skills you need to compose music in this app are tapping and dragging. You can easily export a finished song from Korg Gadget and add it to your app.

In this tutorial I’ll take you through creating a simple track in Korg Gadget using multiple instruments, exporting the file, and finally including the finished song in your app.

Ready to discover the inner musician you never knew existed? Read on! :]

Getting Started

Download Korg Gadget on the App Store. Korg Gadget isn’t cheap; the current U.S. price on the App Store is $38.99, but occasionally you can find it on sale.

Open the Korg Gadet app on your iPad and tap the document icon in the upper left corner to create a new project, as shown below:

Tap New, enter RW Game Track as the name, and tap OK.

The app then presents you with a list of sequencers, or Gadgets as they are called in the app. Choose the London drum machine as shown below:

The app then takes you to the Mixer view where you will build your song. By default, the top half of the screen displays list of tracks, like so:

Tap the Track 1 to enter Edit view:

At the top left of the screen you’ll see a Draw icon and a Select icon. Tapping these icons toggles you between “drawing” mode and “selecting” mode.

Tap any of the eight blue pads at the bottom of the screen and you’ll hear the London synthesizer drum sounds in real time. Note that the row names in your grid correspond to the names of each drum “voice”. Alternatively, you can tap on the row headings to hear the drum voices.

Tap the Drum Kit display on the left side of the console to open a popover showing the available drum sets. Scroll down and select 042 Lockeroom from the list.

To add a note to your song, simply tap the screen where you’d like to add the note. For your first attempt, recreate the pattern shown in the image below:

If you’ve placed a note in the wrong spot, just tap the note again to remove it.

Press the Play icon in the bottom toolbar to play your song; each note is played as the yellow cursor scrolls by.

By default the green loop icon is selected, so the song repeats until you tap the pause icon. If you turn off loop mode, the song stops when it reaches the end of the track.

If you want to clear your notes from the screen, press Hold to erase to wipe the notes as the cursor scrolls by.

I uploaded my example to SoundCloud so you can compare your results to mine:

Next, save your work in progress. To do this, tap Back to return to the Mixer View, tap the Document icon, then tap Save.

The basic drum groove is in place; next you’ll add a low drone sound to your track a la Blade Runner or Miami Vice.

Adding a Simple Drone

At this point you should be back in the Mixer View. Tap the circled + in the second grey box to create a new gadget, as shown below:

Choose the Chicago Gadget from the list, then tap the Chicago icon to enter Edit view.

You’ll note that this sequencer has fewer pads than the London synthesizer (7 versus the London synthesizer’s 8). The pads on this sequencer control the pitch of the note being played instead of the instrument voice. The black dots on the first, fourth, and seventh pads indicate an octave change.

The first key is middle C, which is the center key on an 88 key piano. This pitch is too high for your low drone. To lower the pitch of the notes, scrub the left column downward until you reach G1.

This time, instead of tapping the screen to place a note, tap and drag to the right as shown below — this creates a a note that plays for the entire bar:

Tap on Sound Program and choose 028 Downer Arp — this changes the voice of the note played. This preset gives you a sound like a Roland Arp synthesizer with some modulation using the “arpeggiator” effect settings from the lower right:

Feel free to experiment with switches in the Arpeggiator section: try the Up, Up/Down, 2 Oct and 1 Oct settings to see how they change the songs. You can turn off the effect by hitting the On button in the Arpeggiator section of the console.

When you are finished experimenting, return the toggle switches to the Full and Down positions.

You can hear my version here for comparison purposes:

That takes care of the foundation tracks for your song — but most songs need a melody to carry them forward.

If that sounds complicated, consider this: most popular songs only have four to six notes total in the main melody, or “hook”! :]

Adding a Melody to your Song

Tap Back to return the Mixer view and tap the + button to add a third Gadget. Choose the Wolfburg Gadget and tap the gadget to switch to Edit view.

Select the 020 Syn. Trumpet instrument using the arrow keys at the top of the console. You’ll create a pattern with this synthesizer much in the same way you created a pattern with the London synthesizer.

Replicate the pattern you see in the image below:

Each row in your grid now represents a different note, whereas with the London synthesizer each row represented a different instrument voice.

The A#3 note is played on the beat like the bass drum. I threw in a few C4 and D4 notes, some on the beat and some off the beat. On the fourth beat I add a little flare by playing F4, A#3 and G3 at the same time.

Here’s what I have so far:

Your song is quickly taking shape, but it still needs another element to pull everything together. To do this, you’ll add another low frequency drone to help fill in the bottom end.

Adding Another Low Drone

Tap Back to return to the Mixer view, and add another Gadget to your track by tapping the + button. Select the Berlin synthesizer, then enter the Edit view and set the Sound Program display to 005 Natural Lead using the + and - buttons.

Tap and drag a note across the entire measure at G1, much like you did with the other arpeggiated drone, as shown below:

Here’s the song up to this point:

You’ve covered the basics and created your first four-count bar of your song. Now it’s time to flesh this out and create a full song.

Stripping Down Your Song

When creating a song, I usually put together scenes that have a basic beat. I build the scene up as it progresses, then simplify it towards the end. Since I know the song will loop when I add it to my app, I’ll make the loop sound as smooth as possible by ending the track using the same beat with which I started.

So far, you have a single scene in your song. To flesh out your song and make it a little longer, you’ll duplicate the track you’ve already built, build the song up in the middle and then break it down towards the end. To accomplish this, you’ll use the Function button to copy, duplicate and delete the various elements of your song.

Have you been saving your work as you go along? If not, go back to the Mixer view, tap the document item and select Save to save your work in progress.

Ensure you’re in the Mixer view and tap the Function button in the lower left corner of the app. This overlays several commands on your screen. If the overlay looks different than the screenshot above, you may still be in the track’s Edit View.

In the top bar, tap Duplicate twice to create two copies of your scene as shown below:

Tap Function to exit this function.

You should now see three identical scenes labelled 1, 2 and 3 as shown below:

First, disable looping by tapping on the green loop icon in the bottom bar so that it turns gray. Then tap the play icon to play the song.

Your job now is to strip away some of the elements of your song near the beginning and end to make it sound more dynamic.

Tap the Function button to bring up the edit overlay. In Scene 1, tap Clear on Track 4 to clear the drone as shown below:

Tap Sure to confirm your action. Clear the drone from Scene 2 in the same way.

Tap Function again and you’ll see that the drone has been removed from both Scene 1 and 2 and only starts playing in Scene 3.

Press Play to hear how your song sounds now. Here’s my version up to this point:

You’re now going to modify your song so that it starts with the drum and arpeggio loops on their own in Scene 1 and adds the melody in Scene 2.

Tap Function to enter song edit mode again. Tap Clear on Track 3 of Scene 1 to clear the melody.

Press Play to hear how your song builds up now. My version is below:

You can definitely hear how it builds, but the scenes change much too quickly. You’ll fix that next.

Before moving on, now would be a great time time to Save your work.

Changing the Bar Count of a Scene

Each instrument in a Scene can be any number of bars long. Currently, each track in your song is only one bar in length — by adding more bars you can stretch out each scene and make the song build more slowly.

Tap Track 4 of Scene 1 to enter the track editor. The current length of the Scene is displayed at the top of the screen — 1 bar.

Tap the Function button and select 4 in the Bars segmented control to change the track length to four bars, like so:

Tap Function to exit.

Tap Back to return to the Mixer View; you’ll see that Track 4 is now divided into 16 sections. Tap the loop button then tap Play to hear the changes.

Repeat the steps above to make each Scene four bars.

When you return to the Mixer view you’ll notice that the drone is only a quarter of the length of the bar as shown below:

You want the drone to play over all four bars; you can use the Copy functionality to fix that.

Tap Track 4 in Scene 3; it opens to Bar 1 by default. Tap along the top of the bars to view the contents of Bars 2, 3 and 4. Press Function then press the grey Copy button on the overlay. Press 1 Bar to copy the notes from the first bar and the display will change to Select Destination as shown below:

Tap 2 Bar to copy the contents of Bar 1 into Bar 2. Repeat the above steps to copy the contents of Bar 1 into Bars 3 and 4.

Tap Back to return to the Mixer view, hit Play and you’ll hear the drone play through all four bars, like so:

Here’s my version of the song up to this point:

The song now builds more slowly, which sounds much better. Now you’ll need to mix things up a little in the song to keep it from feeling too monotonic.

Press Function in the main Mixer view and press Duplicate twice on Scene 3, and tap Function again to finish.

Then tap Track 4 on Scene 4 to edit the sequence, then drag the drone note from G1 up to A#1. This changes the pitch of the drone to set off this section a little bit. Repeat this for the second bar as well (or copy it over).

Tap Function then tap 2 to shorten the scene to two bars. Tap Back to return to the Mixer view. Repeat that step to shorten Scene 5 to two bars.

The overlay should now look like the following screenshot:

Press Play to hear your composition. You might need to tap the green loop icon to turn off scene looping.

Here’s my version of the song for comparison purposes:

Now that the track builds nicely, you can break down the ending to make it sound good when it loops.

Breaking Down Your Song

Duplicate Scene 5 twice using the same steps as before. If things are getting a little tight and you need more space on the screen, tap the Expand icon to hide the instrument mixer:

Use Function to clear the drone on Track 4 in Scenes 6 and 7. Clear the melody track in Scene 7 as well. Try to see if you can figure it out yourself without looking at the spoiler below!

Duplicate Scene 7 to create Scene 8. Delete everything from Scene 8 except for the drum track. While you’re at it, modify Scene 6 and 7 to be four bars in length. Your finished piece should look like the following screenshot:

Play your finished masterpiece all the way through; it sounds like you’re done!

Now that you have a great-sounding track, all you need to do is export it to an audio file and include it in your app.

Exporting to an Audio File

To export your song to file, press the Document icon and tap Export. You can export your song to GadgetCloud which is hosted on SoundCloud. Alternately, you can export your song as an Audio File using iTunes export, DropBox or AudioCopy, which lets you paste your composition into a compatible app.

Export the file to the destination of your choice. Now that you have a physical file you can work with, you can clean it up a little before using it in your game.

Trimming Your Song in QuickTime Player

You’ll likely need to trim your audio file a little as the export process adds a few seconds of dead air to the end of the file — this won’t sound very good when it loops!

Fortunately, it’s easy to trim your song in QuickTime player.

Open the file in QuickTime Player and set it to Loop under the View menu. Then select Trim from the Edit menu and adjust the length of your song. Listen carefully as the song loops; try to trim your song so that there isn’t a break or a choppy transition when the song loops.

Once you’re satisfied, you can Export the trimmed file. Choose Export from the File menu, then select Audio Only as the Format and save it as an m4a file.

If you’d like to see how I trimmed my file, you can check it out here: RW Game Track

All that’s left is to add the song to your app!

Adding Your Song to a Sprite Kit App

Download the completed SpriteKit Space Invaders app; if you’d like some background on the app you can read about it in this tutorial by Joel Shapiro.

Open GameScene.m in Xcode and add the following import to the top of the file:

@import AVFoundation;

Next add a private instance variable to store the music player as shown below:

@interface GameScene () {
    AVAudioPlayer *_backgroundMusicPlayer;
}

Add the following helper method to play the background music:

- (void)playBackgroundMusic:(NSString *)filename{
     NSError *error;
     NSURL *backgroundMusicURL = [[NSBundle mainBundle] URLForResource:filename withExtension:nil];
     _backgroundMusicPlayer = [[AVAudioPlayer alloc] 
          initWithContentsOfURL:backgroundMusicURL error:&error];
     _backgroundMusicPlayer.numberOfLoops = -1;
    [_backgroundMusicPlayer prepareToPlay];
    [_backgroundMusicPlayer play];
}

Finally, add the following to createContent in GameScene.m, immediately after the call to setupHud (change the filename to whatever you called yours):

[self playBackgroundMusic:@"RW Game Track.m4a"];

Build and run the app; you’ll hear the music playing as you play the game. Satisfying, isn’t it? :]

Once the game is over, the music will stop playing as the Sprite Kit scene is replaced.

Where To Go From Here?

Here is the finished RW Game Track.gdproj. You can add it to your own Korg Gadget app with iTunes sharing.

To further refine your tune, you can tweak the notes in each scene to simplify or enhance your tracks. Experiment with adding notes and drones in different places. Try the Amsterdam gadget to add some interesting sounds and effects. Most of all, have fun and get creative!

If you have any questions or comments, or would like to share your creations with us, feel free to join the discussion below!

How to Make Game Music for Beginners is a post from: Ray Wenderlich

The post How to Make Game Music for Beginners appeared first on Ray Wenderlich.

So much data, so little time.

Update note: This tutorial was updated to iOS 8 and Swift by Brad Johnson. Original post by Tutorial Team Member Nicolas Martin.

In the mobile app world, people want their information fast, and they want it now!

iOS users expect their data to be available on-demand and presented quickly. Furthermore, they expect this to all happen in an easy to use and intuitive manner. It’s a tall order, to be sure!

Many UIKit based applications use the UITableView as a way to navigate through data, since scrolling is natural and fast. But what about the cases where there are large, even huge, amounts of data to sift through? With large datasets, scrolling through massive lists becomes slow and frustrating – so it’s vitally important to allow users to search for specific items. Lucky for us, UIKit includes UISearchBar which seamlessly integrates table view search and allows for quick, responsive filtering of information.

In this tutorial, you’ll build a searchable Candy app which is based on a standard table view. You’ll add table view search capability, including dynamic filtering and adding an optional Scope Bar. In the end, you’ll know how to make your apps much more user friendly and satisfy your users’ urgent demands!

Ready for some sugar-coated search results? Read on!

Getting Started

In Xcode, create a new project by going to File\New\Project…. Choose Single View Application and click Next. Name the project CandySearch and make sure that Language is set to Swift and Devices is set to iPhone. Click Finish, browse to the location you want to create the project and then click Create.

Start by clearing out some of the default files so you can truly start from scratch. In the Project Navigator, select ViewController.swift, right-click, select Delete, and then click Move to Trash. Then open up Main.storyboard, select the only view controller and delete it. Now that you have an empty storyboard to work with, you can add the main screens in your application.

From the Object Browser (the lower half of the right sidebar) drag out a Navigation Controller to add iOS’s built-in navigation logic to the project. This will create two view controllers on the storyboard – the navigation controller itself and a table view controller inside that will be the initial view for the application.

You’ll need one more view controller as the detail view controller that is displayed when the user selects an item from the list. Drag a View Controller object onto the storyboard. Control-drag from the Table View Controller to the new view controller and select show as the manual segue from the popup.

Setting Up the Candy Class

Next you will create a struct to model the information about each piece of candy you’re displaying, such as its category and name. To do this, right click on the CandySearch folder and select New File…. Select iOS \ Source \ Swift File and click Next. Name the file Candy.swift. Open the file, and add the following definition:

struct Candy {
  let category : String
  let name : String
}

This struct has two properties: the category and name of the candy. When the user searches for a candy in your app, you’ll be referencing the name property against the user’s search string. You’ll see how the category string will become important near the end of this tutorial when you implement the Scope Bar.

You don’t need to add your own initializer here since you’ll get an automatically-generated one. By default, the initializer’s parameters will match up with properties you define in the same order. You’ll see how to create candy instances in the next section.

Now you are ready to set up the UITableView that your UISearchBar will filter!

Connecting the Table View

Next you will set up a UITableView that will work with the UISearchBar. Create a new file by right clicking on the CandySearch folder and selecting New File…. Select iOS \ Source \ Cocoa Touch Class and click Next. Name the class CandyTableViewController, make it a subclass of UITableViewController and set the Language to Swift.

You will start by adding an array for the sample data. Open CandyTableViewController.swift and add the following code inside the class definition:

var candies = [Candy]()

The candies array will be where you manage all the different Candy objects for your users to search. Speaking of which, it’s time to create some Candy! In this tutorial, you only need to create a limited number of values to illustrate how the search bar works; in a production app, you might have thousands of these searchable objects. But whether an app has thousands of objects to search or just a few, the methods used will remain the same. Scalability at it’s finest! To populate your candies array, override the viewDidLoad as follows:

override func viewDidLoad() {
  super.viewDidLoad()
 
  // Sample Data for candyArray
  self.candies = [Candy(category:"Chocolate", name:"chocolate Bar"),
    Candy(category:"Chocolate", name:"chocolate Chip"),
    Candy(category:"Chocolate", name:"dark chocolate"),
    Candy(category:"Hard", name:"lollipop"),
    Candy(category:"Hard", name:"candy cane"),
    Candy(category:"Hard", name:"jaw breaker"),
    Candy(category:"Other", name:"caramel"),
    Candy(category:"Other", name:"sour chew"),
    Candy(category:"Other", name:"gummi bear")]
 
  // Reload the table
  self.tableView.reloadData()
}

This code doesn’t do much yet, but it does some important set up for later. First, it populates the candies array with 9 different candies and categories. You’ll use this array later when you populate the table. Second, you tell the tableView that it should reload it’s data. You need to do this to ensure all the code you are about to write gets called after the candies array is populated.

Next, you’ll add functions that govern the table view itself. Implement the tableView(_:numberOfRowsInSection:) like so:

override func tableView(tableView: UITableView!, numberOfRowsInSection section: Int) -> Int {
  return self.candies.count
}

This simply tells the tableView that it should contain as many rows as there are items in the candies array you populated earlier.

Now that the tableView knows how many rows to use, you need to tell it what to put in each row. You’ll do this by implementing tableView(_:cellForRowAtIndexPath:):

override func tableView(tableView: UITableView!, cellForRowAtIndexPath indexPath: NSIndexPath!) -> UITableViewCell! {
  //ask for a reusable cell from the tableview, the tableview will create a new one if it doesn't have any
  let cell = self.tableView.dequeueReusableCellWithIdentifier("Cell", forIndexPath: indexPath) as UITableViewCell
 
  // Get the corresponding candy from our candies array
  let candy = self.candies[indexPath.row]
 
  // Configure the cell
  cell.textLabel.text = candy.name
  cell.accessoryType = UITableViewCellAccessoryType.DisclosureIndicator
 
  return cell
}

This function has three main steps. First, you dequeue a cell to use for this indexPath. You then access the candies array, reference the indexPath to decide which Candy object to pull, and then use that Candy object to populate the UITableViewCell.

You’re almost there! There’s one last step you’ll need to take before you can see your list of candies. You need to hook up all your code to your storyboard in Interface Builder. First, open Main.storyboard and select the Root View Controller. In the Identity Inspector (third tab on the top half of the right sidebar), set the Class to CandyTableViewController. This will tell the OS to load your custom class when this controller is pushed on the screen. While you’re at it, double click the Root View Controller title and change it to CandySearch to give your users an idea of what they’re doing.

Finally, you need to tell the OS what cell to use when your code looks for a new one. You may have noticed when you created the storyboard earlier that a default cell was placed in the table view. Select the cell (conveniently named “Cell”) and open the Attributes Inspector (just to the right of the Identity Inspector). Change the Identifier to Cell. This matches the reuse identifier you used in your code earlier to dequeue the cell.

Save your changes and build and run. You now have a working table view! So much candy…so little time! We need…a UISearchBar!

Setting Up the UISearchBar

If you look at the UISearchBar documentation, you’ll discover it’s pretty lazy. It doesn’t do any of the work of searching at all! The class simply provides a standard interface that users have come to expect from their iOS apps. It’s more like a middle-class manager in that respect; it’s great at delegating tasks to others.

The UISearchBar class communicates with a delegate protocol to let the rest of your app know what the user is doing. All of the actual functions for string matching and other operations will be written by you. Although this may seem a tad scary at first (and more than a little unfair!), writing custom search functions gives you tight control over how results are returned specifically in your app. Your users will appreciate searches that are intelligent — and fast.

Start by opening up Main.storyboard and dragging a Search Bar and Search Display Controller object to the table view controller. Be careful — this is different from the Search Bar object, which is also available. Position the Search Bar between the Navigation bar and the Table View.

Not sure what’s meant by a search display controller? According to Apple’s own documentation, a search display controller “manages display of a search bar and a table view that displays the results of a search of data managed by another view controller.”

That means the search display controller will have its own table view to display the results, separate from the one you just set up. So basically, the search display controller added above handles the task of showing the filtered data from a search in a separate view controller that you don’t have to worry about. :]

UISearchBar Options in the Attributes inspector

While in the storyboard, take a moment to review the properties available for the Search Bar object. You may not use all of them, but knowing what’s available in the Attributes Inspector is always valuable when working with a new UIKit component.

• Text: This will change the actual string value that is present in the search bar. As your app has no need to have a default value in the search bar, you won’t need this.
• Placeholder: This does exactly what you might expect – it allows you to put the light gray text in the Search bar that tells the user what the search bar can be used for. In the case of the Candy app, use “Search for Candy”.
• Prompt: This text will appear directly above the search bar. This is good for apps that have complicated search mechanisms, where the user might need instructions. (But in this app, the Placeholder text should be pretty clear!)
• Search Style, Bar Style, Translucent, Tint, Background and Scope Bar Images: These options allow you to customize the appearance of your search bar. The options are almost identical to those of the UINavigationBar and it is normally advisable to have your UISearchBar match your UINavigationBar for harmonious design.
• Search Text and Background Positions: These options allow you to add a custom offset to both your search text and background image.
• Show Search Results Button: Provides a button on the right side of the search bar for performing functions such as displaying recent searches or showing the last search results. Interaction with this button is managed through the Search Bar Delegate methods.
• Show Bookmarks Button: Shows the standard blue oval bookmarks icon in the right hand side of the search bar. Users expect this to bring up a list of their saved bookmarks. Like the search results button, this is also managed through the Search Bar Delegate methods.
• Show Cancel Button: This button allows users to close the separate view controller that is generated by the search bar. Leave this unchecked, as the search bar will automatically show and hide the Cancel button when the user is in Search mode.
• Shows Scope Bar & Scope Titles: The scope bar allows users to refine their search by limiting the results to a certain category, or scope. In a music application, for example, this bar may show choices such as Artists, Albums or Genres. For now, leave this box unchecked; you will implement your own scope bar later in this tutorial.
• Capitalize, Correction, Keyboard, etc.: These are options that have been borrowed from the normal UITextField options and allow you to change your search bar’s behavior. For example, if the user will be searching on proper nouns like businesses or last names, you may want to consider turning off correction as it will be annoying to users. In this tutorial, the candy names are all common nouns, so the default options will suffice.

UISearchBarDelegate and Filtering

After setting up the storyboard, you’ll need to do some coding work to get the search bar working. To allow the CandyTableViewController class to respond to the search bar, it will have to implement a few protocols. Open CandyTableViewController.swift and replace the class declaration with the following:

class CandyTableViewController : UITableViewController, UISearchBarDelegate, UISearchDisplayDelegate {

UISearchBarDelegate defines the behavior and response of a search, while UISearchDisplayDelegate defines the look and feel of the search bar.

Next, add the following property to the class:

var filteredCandies = [Candy]()

This array will hold the filtered search results.

Next, add the following helper method to the class:

func filterContentForSearchText(searchText: String) {
  // Filter the array using the filter method
  self.filteredCandies = self.candies.filter({( candy: Candy) -> Bool in
    let categoryMatch = (scope == "All") || (candy.category == scope)
    let stringMatch = candy.name.rangeOfString(searchText)
    return categoryMatch && (stringMatch != nil)
  })
}

This method will filter the candies array based on searchText (which is the search string entered by the user), and will put the results in the filteredCandies array. Swift Arrays have a method called filter() that takes a closure expression as its only parameter.

If you have some experience with Objective-C, think of closure expressions as Swift’s version of blocks. A closure is a self contained block of functionality. They are called closures because they can capture and store references to any variables or constants that are created or used in the same context the closure is created, which is known as closing. Here is the syntax for a closure expression:

{(parameters) -> (return type) in expression statements}

In this case, the filter method uses the closure expression separately on each element of the array being filtered. The parameter of the closure expression is the individual element being sorted. The closure expression returns a Bool that is true if the element should be included in the new filtered array, or false if the element should not be included. If you look at the documentation of this method, you’ll notice it uses a type referred to as <T>. This is a generic type, which means it can be any type. Since you are defining you’re own filter rules inside the closure expression, this filter method will work on an array filled with any kind of type. The closure expression’s parameter is also of type T, which is the element being filtered. In your code you replaced that with candy: Candy, since you know this array is filled with Candy objects.

rangeOfString() checks if a string contains another string. If it does and the category also matches, you return true and the current candy is included in the filtered array; if it doesn’t you return false and the current candy is not included.

Next, add the following two methods to the class:

func searchDisplayController(controller: UISearchDisplayController!, shouldReloadTableForSearchString searchString: String!) -> Bool {
  self.filterContentForSearchText(searchString)
  return true
}
 
func searchDisplayController(controller: UISearchDisplayController!, shouldReloadTableForSearchScope searchOption: Int) -> Bool {
  self.filterContentForSearchText(self.searchDisplayController.searchBar.text)
  return true
}

These two methods are part of the UISearchDisplayControllerDelegate protocol. They will call the content filtering function when the the user enters a search query. The first method runs the text filtering function whenever the user changes the search string in the search bar. The second method will handle the changes in the Scope Bar input. You haven’t yet added the Scope Bar in this tutorial, but you might as well add this UISearchBarDelegate method now since you’re going to need it later.

Build and run the app now; you’ll notice that using the Search Bar still does not bring up any filtered results! What gives? This is simply because you haven’t yet written the code to let the tableView know when to use the normal data vs. the filtered data. You’ll need to modify both the numberOfRowsInSection and cellForRowAtIndexPath functions. Replace the functions with the new implementations below:

override func tableView(tableView: UITableView!, numberOfRowsInSection section: Int) -> Int {
  if tableView == self.searchDisplayController.searchResultsTableView {
    return self.filteredCandies.count
  } else {
    return self.candies.count
  }
}
 
override func tableView(tableView: UITableView!, cellForRowAtIndexPath indexPath: NSIndexPath!) -> UITableViewCell! {
  //ask for a reusable cell from the tableview, the tableview will create a new one if it doesn't have any
  let cell = self.tableView.dequeueReusableCellWithIdentifier("Cell") as UITableViewCell
 
  var candy : Candy
  // Check to see whether the normal table or search results table is being displayed and set the Candy object from the appropriate array
  if tableView == self.searchDisplayController.searchResultsTableView {
    candy = filteredCandies[indexPath.row]
  } else {
    candy = candies[indexPath.row]
  }
 
  // Configure the cell
  cell.textLabel.text = candy.name
  cell.accessoryType = UITableViewCellAccessoryType.DisclosureIndicator
 
  return cell
}

This code tests to see if the currently displayed tableView is the search table or the normal table. If it is indeed the search table, the data is taken from the filteredCandies array. Otherwise, the data comes from the full list of items. Recall that the search display controller automatically handles showing and hiding the results table, so all your code has to do is provide the correct data (filtered or non-filtered) depending on which table view is currently displaying.

Build and run the app. You’ve got a functioning Search Bar that filters the rows of the main table! Huzzah! Play with the app for a bit to see how the user can search for various candies.

You’ve probably noticed that that the if/else logic found in the tableView(numberOfRowsInSection:) method is reused quite a few times. This is important when working with the Search Bar Display Controller and omitting this if/else check may result in bugs that will be difficult to track down. Just remember that the filtered results do not appear in the same table view as the main table. They are actually completely separate table views, but Apple has designed them in such a way that the experience is seamless for the end user — at the expense of being confusing to the novice developer!

Sending Data to a Detail View

When sending information to a detail view controller, you need to ensure that the view controller knows which table view the user is working with: the full table list, or the search results. The code for this will be similar to the code that you wrote in tableView(_:numberOfRowsInSection:) and tableView(_:cellForRowAtIndexPath:). Still in CandyTableViewController.swift, add the following methods to the class:

override func tableView(tableView: UITableView!, didSelectRowAtIndexPath indexPath: NSIndexPath!) {
  self.performSegueWithIdentifier("candyDetail", sender: tableView)
}
 
override func prepareForSegue(segue: UIStoryboardSegue!, sender: AnyObject!) {
  if segue.identifier == "candyDetail" {
    let candyDetailViewController = segue.destinationViewController as UIViewController
    if sender as UITableView == self.searchDisplayController.searchResultsTableView {
      let indexPath = self.searchDisplayController.searchResultsTableView.indexPathForSelectedRow()
      let destinationTitle = self.filteredCandies[indexPath.row].name
      candyDetailViewController.title = destinationTitle
    } else {
      let indexPath = self.tableView.indexPathForSelectedRow()
      let destinationTitle = self.candies[indexPath.row].name
      candyDetailViewController.title = destinationTitle
    }
  }
}

Open up the storyboard and make sure that the segue from the Candy Table View Controller to the Detail View has the identifier candyDetail. Build and run the code at this point and see how the app now navigates to the Detail View from either the main table or the search table with ease.

Creating an Optional Scope Bar to Filter Results

If you wish to give your users another way to filter their results, you can add a Scope Bar in conjunction with your search bar in order to filter out items by their category. The categories you will filter on are the ones you assigned to the Candy object when the candyArray was created: chocolate, hard, and other.

First, set up the scope bar on the storyboard. Go to the CandySearch View Controller and select the search bar. In the attributes inspector, check Shows Scope Bar in the Options section. Then modify the Scope Titles to be: “All”, “Chocolate”, “Hard” ,and “Other”. (You can use the + button to add more scope items and if you double-click an item, you can edit the item title).

Next, modify filterContentForSearchText in CandyTableViewController.swift to take the new scope into account. Replace the current method implementation with the following:

func filterContentForSearchText(searchText: String, scope: String = "All") {
  self.filteredCandies = self.candies.filter({( candy : Candy) -> Bool in
  var categoryMatch = (scope == "All") || (candy.category == scope)
  var stringMatch = candy.name.rangeOfString(searchText)
  return categoryMatch && (stringMatch != nil)
  })
}

This method now takes in an option scope variable (it has a default value of “All” if nothing is passed in). The method now checks both the scope and the string, and only returns true if both the category and the string match (or the category is set to “All”).

Now that you’ve modified this method, you’ll need to change the two searchDisplayController methods to account for the scope:

func searchDisplayController(controller: UISearchDisplayController!, shouldReloadTableForSearchString searchString: String!) -> Bool {
  let scopes = self.searchDisplayController.searchBar.scopeButtonTitles as [String]
  let selectedScope = scopes[self.searchDisplayController.searchBar.selectedScopeButtonIndex] as String
  self.filterContentForSearchText(searchString, scope: selectedScope)
  return true
}
 
func searchDisplayController(controller: UISearchDisplayController!, shouldReloadTableForSearchScope searchOption: Int) -> Bool {
  let scope = self.searchDisplayController.searchBar.scopeButtonTitles as [String]
  self.filterContentForSearchText(self.searchDisplayController.searchBar.text, scope: scope[searchOption])
  return true
}

Both methods now pull the scope out of the search bar and pass it to the new filter method. Build and run now. Here’s how your scope bar should look:

Where To Go From Here?

Congratulations – you now have a working app that allows you to search directly from the main table view! Here is a sample project with all of the code from the above tutorial.

Table views are used in all kinds of apps, and offering a search option is a nice touch for usability. With UISearchBar and the UISearchDisplayController, iOS provides much of the functionality out of the box so there’s no excuse for not using it. The ability to search a large table view is something that today’s users expect; when they find it isn’t present, they won’t be happy campers!

Don’t let this happen to your users. Always give them a search option.

I hope to see you adding search capabilities to your table view apps in the future. If you have any questions or comments, please join the forum discussion below!

How to Add Table View Search in Swift is a post from: Ray Wenderlich

The post How to Add Table View Search in Swift appeared first on Ray Wenderlich.

Learn how to port your Sprite Kit games from iOS to OS X!

Have you ever wished you could port your iOS Sprite Kit game to OS X? Surprisingly, it’s easier than you think.

Apple developed Sprite Kit with the goal of keeping iOS and Mac OS X development as identical as possible – which makes it extremely easy to develop for both environments simultaneously.

This tutorial will show you how to take an existing iOS Sprite Kit game — the finished project from Sprite Kit Tutorial for Beginners — and adapt it to Mac OS X.

You’ll learn how to maintain both versions in a single Xcode project and how to continue development of your game without copying and pasting heaps of code to keep both versions up to date.

It’s recommended that you have some familiarity with Mac OS X Development if you choose to work through this tutorial. However, one of the wonderful features of Sprite Kit is that you don’t need to have a lot of prior experience to turn out a great app.

If do want to learn more about Mac development, you can check out this three part tutorial on making a simple Mac app.

Getting Started

Download the starter project for this tutorial here, and build and run on your iPhone to try it out.

The starter project has a few changes from the original in order to showcase several differences between the iOS and OS X versions of the game.

Accelerometer Support

This project borrows accelerometer support from the Space Game Starter Kit which lets the player move their character up and down the screen by tilting the device, like so:

More Destructive Power

The ninja star has now been imbued with magical ninja powers of epic destruction!

Ok, maybe not that epic, but this version uses a nice particle effect to give the ninja star some visual impact.

Small Technical Improvements

Vicki Wenderlich lent her talents to the game and added a new tiled background which makes the game more aesthetically pleasing. As well, the status bar is hidden and the app now supports iPad resolutions.

Working with Projects and Targets

A project file ties all of your working files together, but what determines how your project is compiled is a target.

A single project can contain multiple targets. This lets you compile your project in several different ways, depending on which files are associated with a specific target and the specific build settings of the target. This should give you a clue as to how you’re going to set up this project to compile for OS X!

Let’s take a look at this project’s targets. Open the SpriteKitSimpleGame project, and at the top of the left panel, select your project to show the project settings. Then select SpriteKitSimpleGame in the project window.

Right now there are two targets, one for iOS and the other for iOS unit tests, as shown below:

Alternatively, you can select SpriteKitSimpleGame from the Target list if the project and target list are both expanded:

When you build an application, you build it for the device or devices supported by the target. To see which devices the current target supports, click the SpriteKitSimpleGame drop down next to the Stop button at the top-left of the window, as shown below:

This is where you’ll add a build target for Mac OS X.

Adding a Build Target for Mac OS X

Ensure your Xcode project is the active window and select File \ New \ Target as shown below:

Xcode prompts you to select a template for your new target.

Select the OS X\Application\SpriteKit Game template and click Next, as shown below:

Finally, type in the product name as SpriteKitSimpleGameMac and click Finish, like so:

To try running your app on OS X, select SpriteKitSimpleGameMac from the scheme list, then select My Mac 64-bit as shown below:

What do you think will happen when you try to build and run your project using this new target?

• A — The game will run perfectly — and that’s the end of the tutorial!
• B — The game will fail to compile with numerous errors.
• C — The game will compile but crash on launch.
• D — The game will compile and run but won’t be the game you expected.

Structuring Your Files for Multiple Targets

Now that you have a Mac OS X build target, you’ll be modifying and adding files to make the app work under OS X. Keeping track of these files can be difficult as time goes on, so it’s best to set up a system right now to help keep all the files organized.

Minimize all of your groups and add a new group named SharedResources as shown below:

This group will be the main location for your game and will contain resources that are common to both Mac OS X and iOS targets.

While you’re at it, create a separate group named Testing and move the test modules into it, like so:

Keeping the unit tests in a separate folder helps avoid visual clutter.

Now that you have your new organized structure for the various files in your project, you’ll need to move the files into the appropriate locations.

Expand SharedResources and SpriteKitSimpleGame. Click and drag the Particles and Sounds groups from SpriteKitSimpleGame to SharedResources.

Next, drag over the sprites.atlas folder, MyScene.h, MyScene.m, GameOverScene.h and GameOverScene.m. Your file structure should look like the one shown below:

Delete the Spaceship.png file — you won’t need that any longer. This is just a boilerplate file that is automatically added when you create a game with the Sprite Kit template.

All the shared files of your Sprite Kit game now reside in the SharedResources group. Everything left in the SpriteKitSimpleGame relates to launching and managing the game on iOS.

Expand the SpriteKitSimpleGameMac group. You’ll need to remove the example game files from this group before you progress any further.

Delete MyScene.h, MyScene.m and Spaceship.png file from the SpriteKitSimpleGameMac group and select Move to Trash. Your file list should look like so:

As a final check, your fully-expanded file list should look like the following:

You’ve removed unnecessary files from the project and organized it neatly. Now it’s time to modify your targets to let the compiler know which files to include with each target.

Adding Target Membership

Expand the Frameworks group and select UIKit.framework, like so:

Expand the right Utilities Panel select File Inspector, like so:

About halfway down the File Inspector you’ll see the Target Membership section. This is where you select the targets that will use this file.

UIKit is only available on the iOS platform, so leave it unchecked on your Mac OS X targets, as shown below:

The Cocoa Framework is only available on Mac OS X so ensure it’s checked for your Mac targets and unchecked for your iOS targets like so:

The Sprite Kit Framework is available to iOS and Mac OS X so set the target membership as below:

Each individual file in your project has its own target membership with the exception of texture atlases. The atlas itself is the only place you need to set a target membership and all contained textures will be automatically included.

However, classes work a little differently. You can’t set a target membership on a .h file — instead, you must set the target membership on the .m file.

Armed with your new-found understanding of target membership, work through each file in your SharedResources group and make sure both SpriteKitSimpleGame and SpriteKitSimpleGameMac are ticked on each file. In total, you should need eight ticks to get the job done.

Next, work through each file in your SpriteKitSimpleGame group and make sure that only SpriteKitSimpleGame is ticked for each — they should all be set correctly at this point, but it’s good to check.

Finally, work through each file in SpriteKitSimpleGameMac group and make sure that only SpriteKitSimpleGameMac files are ticked. Again, you shouldn’t have to change any but it never hurts to check.

Now that your project is properly set up for your iOS and Mac targets, you can get down to what you’re good at — writing code!

Getting the Game to Build and Run

As it stands right now, your project will still build and run without issue for iOS. The changes you just made have no real effect on the existing game. However, if you build and run the Mac target, you’ll see a bunch of errors. That’s because you haven’t yet accounted for the differences between iOS and OS X.

Build and run your project using the SpriteKitSimpleGameMac target; what do you see?

You’ll receive the error Module ‘CoreMotion’ not found. Mac OS X doesn’t have a CoreMotion class or its equivalent; you’ll have to work around this issue and use the keyboard to control player movement. However, your primary goal is to get the project to a buildable state before you worry about implementation details like that.

But how will you fix this? You can’t just remove the line of code referring to CoreMotion, otherwise the iOS version will break. You can’t work around this by using an if statment, since the compiler will still check each line of the code and throw an error if it doesn’t recognize something.

Open MyScene.m and replace:

@import CoreMotion;

with the following code:

#if TARGET_OS_IPHONE
@import CoreMotion;
#endif

Unlike a regular if statement, an #if is performed by the preprocessor. TARGET_OS_IPHONE returns TRUE if the current target is iOS.

Now you will need to find the remaining code related to CoreMotion and surround it with #if statements.

Find the following code in the instance variables for MyScene.m:

CMMotionManager *_motionManager;

…and replace it with:

#if TARGET_OS_IPHONE
  CMMotionManager *_motionManager;
#endif

Scroll down to the init method and find the following code:

_motionManager = [[CMMotionManager alloc] init];
_motionManager.accelerometerUpdateInterval = 0.05;
[_motionManager startAccelerometerUpdates];

Replace the above code with the following:

#if TARGET_OS_IPHONE
_motionManager = [[CMMotionManager alloc] init];
_motionManager.accelerometerUpdateInterval = 0.05;
[_motionManager startAccelerometerUpdates];
#endif

Now, find the following code [TODO: FPE: Again, are we in the same file?]:

[self updatePlayerWithTimeSinceLastUpdate:timeSinceLast];

…and replace it with the following:

#if TARGET_OS_IPHONE
[self updatePlayerWithTimeSinceLastUpdate:timeSinceLast];
#endif

Last but not least, locate the method named updatePlayerWithTimeSinceLastUpdate: and wrap the entire method with the following code:

#if TARGET_OS_IPHONE
- (void)updatePlayerWithTimeSinceLastUpdate:(CFTimeInterval)timeSinceLast 
.
.
.
}
#endif

If you build this against an iOS target, all of the above #if statements will return TRUE, so the app compiles just as it did before. In contrast, if you build this against a Mac OS X target all of the above #if statements will return FALSE and none of the above blocks will be compiled.

Take a look at the touchesEnded:withEvents: method in MyScene.m. Since the current version of Mac OS X doesn’t support touch screens, this method is meaningless. The Mac OS X version of this game will use mouse clicks instead as a perfectly adequate substitute for screen touches.

To avoid adding a bunch of boilerplate code, you’ll now create a class that inherits from SKScene to help you handle both screen touches and mouse clicks!

Adding Event Handlers

Select your SharedResources group.

On the menu bar select File \ New \ File… as shown below:

Select Objective-C Class from either the iOS or OS X category and click Next.

Name the file SKMScene and make it a subclass of SKScene.

Place the file directly under your project folder, make sure both iOS and Mac targets are ticked in the target area and click Create.

Open SKMScene.h and replace its contents with the following code:

@import SpriteKit;
 
@interface SKMScene : SKScene
 
//Screen Interactions
-(void)screenInteractionStartedAtLocation:(CGPoint)location;
-(void)screenInteractionEndedAtLocation:(CGPoint)location;
 
@end

You’ll override the above two screen interaction methods using subclasses of SKMScene.

Add the following code to SKMScene.m directly under the line @implementation SKMScene:

#if TARGET_OS_IPHONE
-(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
  UITouch *touch = [touches anyObject];
  CGPoint positionInScene = [touch locationInNode:self];
  [self screenInteractionStartedAtLocation:positionInScene];
}
 
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
{
  UITouch *touch = [touches anyObject];
  CGPoint positionInScene = [touch locationInNode:self];
  [self screenInteractionEndedAtLocation:positionInScene];
}
 
- (void)touchesCancelled:(NSSet *)touches
               withEvent:(UIEvent *)event
{
  UITouch *touch = [touches anyObject];
  CGPoint positionInScene = [touch locationInNode:self];
  [self screenInteractionEndedAtLocation:positionInScene];
}
#else
-(void)mouseDown:(NSEvent *)theEvent {
  CGPoint positionInScene = [theEvent locationInNode:self];
  [self screenInteractionStartedAtLocation:positionInScene];
}
 
- (void)mouseUp:(NSEvent *)theEvent
{
  CGPoint positionInScene = [theEvent locationInNode:self];
  [self screenInteractionEndedAtLocation:positionInScene];
}
 
- (void)mouseExited:(NSEvent *)theEvent
{
  CGPoint positionInScene = [theEvent locationInNode:self];
  [self screenInteractionEndedAtLocation:positionInScene];
}
#endif
 
-(void)screenInteractionStartedAtLocation:(CGPoint)location {
  /* Overridden by Subclass */
}
 
-(void)screenInteractionEndedAtLocation:(CGPoint)location {
  /* Overridden by Subclass */
}

That’s a fair bit of code, but if you read through from the top, it makes a lot of sense. Touching the screen or the end of a touch event calls the methods in the #if TARGET_OS_IPHONE block. You then create a CGPoint containing the pixel location of the touch and calla the relevant screenInteraction method.

Pressing a mouse button or releasing the mouse button calls the methods in the #else section. Similar to above, you create a CGPoint containing the pixel location of the touch and call the relevant screenInteraction method.

The advantage of using this subclass is that both touch and click events call a screenInteraction method. The screenInteraction methods have no code as you’ll override these in your subclass.

Open MyScene.h and add the following class declaration just under #import :

#import "SKMScene.h"

Next, update the superclass in the @interface line to SKMScene as shown below:

@interface MyScene : SKMScene

This ensures your game scene inherits from your SKMScene subclass. You can now substitute your subclasses for the touch events.

In MyScene.m find the following line:

-(void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {

…and replace it with the following:

-(void)screenInteractionEndedAtLocation:(CGPoint)location {

Next, delete the following lines from the method as you won’t need them any longer:

UITouch *touch = [touches anyObject];
CGPoint location = [touch locationInNode:self];

Build and run your project using the Mac OS X target; it should compile and run without too many issues:

Congratulations — you’re now running your Sprite Kit game on your Mac! You’ll notice that it has a few bugs:

1. Some Macs have a noticeable pause the first time you click on the screen.
2. The particle effect appears to be a little broken on some Macs.
3. Not everything is sized correctly on the screen.
4. The background music has gone noticeably silent.

You’ll tackle each of these bugs in turn — and you’ll learn about a few of the common bugs you’ll encounter when you convert apps between platforms.

Correcting Pre-loading Issues

This bug may not raise its head on all systems, but when it does it definitely points to a performance issue. “First-time-through” bugs like this usually stem from the initial load of resources into memory.

Texture atlases are the first resource type that springs to mind, but since this app doesn’t contain animations or large complex images, it’s safe to assume the problem is somewhere else.

The sound effects are the next most likely candidate as the sound files don’t get loaded until the user clicks on the screen.

To fix this, add the following instance variable to MyScene.m:

SKAction *_playPewPew;

Next, add the following line to initWithSize: inside the if statement:

_playPewPew = [SKAction playSoundFileNamed:@"pew-pew-lei.caf" waitForCompletion:NO];

This modifies your app to preload the sound file when the scene initializes.

Find the following line in screenInteractionEndedAtLocation::

[self runAction:[SKAction playSoundFileNamed:@"pew-pew-lei.caf" waitForCompletion:NO]];

…and replace it with the following:

[self runAction:_playPewPew];

Build and run your app; click the mouse and ensure that the delay has been eradicated.

If your system didn’t expose this bug, then at least the changes above will ensure that it won’t happen on someone else’s system.

Correcting SKS Issues

At the time of this writing the bug in the particle effect seems to be an issue with Xcode 5. You’ll override the file reference to the texture in your sks file.

Technically, there isn’t anything wrong with your sks file – and you won’t experience this issue on all systems – but you should fix it nonetheless.

Find the following line in projectile:dideCollideWithMonster: of MyScene.m:

SKEmitterNode *emitter = [NSKeyedUnarchiver unarchiveObjectWithFile:[[NSBundle mainBundle] pathForResource:@"SmallExplosion" ofType:@"sks"]];

Add the following code directly under the line you found above:

emitter.particleTexture = [SKTexture textureWithImageNamed:@"spark"];

All you have done above is to tell Xcode where to find the particular texture.

Build and run your app; now you can admire your epic glitch-free particle effect.

Correcting Image Resizing Issues

Navigate to your SpriteKitSimpleGameMac group and then to AppDelegate.m. Take a look at the screen size set in applicationDidFinishLaunching:.

It’s set to 1024 x 768 — this is the resolution of the non-Retina iPad.

Now take a look at the contents of sprites.atlas. As expected, all iPad versions of images are suffixed with ~ipad so that your app knows to use these images when it runs on an iPad.

Unfortunately, there is no ~mac suffix you can use here; instead, you’ll need to create a separate texture atlas for the Mac version of your app.

In order to keep your build as small as possible, you should use a texture atlas with only the resolutions your app will actually use.

Right-click on sprites.atlas and select Show in Finder to take you to the images folder.

Create a copy of sprites.atlas and delete all images from the copied folder that don’t have ~ipad in their name.

Next, remove the ~ipad designator from the file names but leave the @2x designator intact.

Rename the folder to spritesMac.atlas and drag the renamed folder into your project.

In the Choose options for adding these files dialog, make sure only the SpriteKitSimpleGameMac target is ticked in the Add to targets section as shown below:

Click Finish. Now that the folder has been imported, select sprites.atlas and turn off target membership for Macs. This ensures that each texture atlas works separately of the other.

Keeping with the spirit of staying organized, move the iOS texture atlas into the iOS group and the Mac texture atlas into the Mac group, as shown below:

Next, go to Project\Clean. This will remove any old files from your build directory (if you forget to do this it might not work, as sprites.atlas may still exist).

Build and run your app; you should see that everything loads at the proper size, as shown below:

At this point your app supports iPhone, iPad and Mac OS X resolutions — and Retina-compatible to boot.

Correcting Soundtrack Issues

Finally, you’ll need to deal with the missing soundtrack to your game.

Look at ViewController.m in the SpriteKitSimpleGame group. viewWillLayoutSubviews has a small section of code which instantiates AVAudioPlayer and sets it to repeat forever.

NSError *error;
NSURL *backgroundMusicURL = [[NSBundle mainBundle] URLForResource:@"background-music-aac" withExtension:@"caf"];
self.backgroundMusicPlayer = [[AVAudioPlayer alloc] initWithContentsOfURL:backgroundMusicURL error:&error];
self.backgroundMusicPlayer.numberOfLoops = -1;
[self.backgroundMusicPlayer prepareToPlay];
[self.backgroundMusicPlayer play];

Aha — you don’t have a ViewController in Mac OS X. Therefore, you’ll need to call this code from AppDelegate instead.

Find the following line in AppDelegate.m of the SpriteKitSimpleGameMac group:

@implementation AppDelegate

..and replace it with the following:

@import AVFoundation;
 
@implementation AppDelegate {
    AVAudioPlayer *backgroundMusicPlayer;
}

Next, add the following code to the top of applicationDidFinishLaunching::

NSError *error;
NSURL * backgroundMusicURL = [[NSBundle mainBundle] URLForResource:@"background-music-aac" withExtension:@"caf"];
backgroundMusicPlayer = [[AVAudioPlayer alloc] initWithContentsOfURL:backgroundMusicURL error:&error];
backgroundMusicPlayer.numberOfLoops = -1;
[backgroundMusicPlayer prepareToPlay];
[backgroundMusicPlayer play];

Build and run your app; the music plays on!

You’ve resolved all of the bugs from the Mac conversion, but you still haven’t solved the issue of game controls in the Mac version of the game.

Using the Keyboard

The ninja’s movements in the iOS version of the app are controlled by tilting the device. These movements are processed by CoreMotion, and the game loop calls updatePlayerWithTimeSinceLastUpdate: to calculate the new player location for the current frame.

Responding to key presses requires a slightly different approach using the available methods to listen for keypress events.

Add the following code to updatePlayerWithTimeSinceLastUpdate: in MyScene.m just before the #endif statement:

#else
-(void)keyDown:(NSEvent *)theEvent {
 
 
}

This updates to the method to respond to a keypress as well. Note that there’s a corresponding keyUp to handle the release of the key to handle events that only last for the duration of the keypress.

You don’t want to respond to just any keypress; you can find out which key was pressed using the passed-in NSEvent.

Add the following code between the curly braces of the keyDown: method you just added:

-(void)keyDown:(NSEvent *)theEvent {
  NSString *keyPressed = [theEvent charactersIgnoringModifiers];
  if ([keyPressed length] == 1) {
      NSLog(@"Key: %c",[keyPressed characterAtIndex:0]);
  }
}

Here you extract the pressed characters from the event without any modifier keys. This means key combinations like Command + S will be ignored. As well, you check that the keypress is only one character in length to filter out any other unwanted events. You’ll dump the key pressed out to the console.

Build and run your project; press a few keys while the game is running and you’ll see the keys pressed show up in the debug area, similar to the following example:

Since you’ll use the up and down arrow keys to move your player sprite, press those keys and see what you get in the console:

Hmm, that looks a little odd. The arrow keys are part of the group known as function keys, so they don’t have a proper character representation. But don’t fret: there’s an easy way to detect when function keys are pressed.

NSEvent is your best friend when it comes to managing keyboard and mouse inputs on the Mac. This tutorial merely introduces NSEvent; it’s highly recommended that you check out the full NSEvent class reference.

For now, take a quick look at the section of NSEvent documentation that deals with the function keys enum. The keys you’re concerned with are NSUpArrowFunctionKey and NSDownArrowFunctionKey.

Go back to MyScene.m and find the keyDown: method you just added.

Comment out the NSLog statement and paste the following code immediately below that:

unichar charPressed = [keyPressed characterAtIndex:0];
switch (charPressed) {
    case NSUpArrowFunctionKey:
        [_player runAction:[SKAction moveByX:0.0f y:50.0f duration:0.3]];
        break;
    case NSDownArrowFunctionKey:
        [_player runAction:[SKAction moveByX:0.0f y:-50.0f duration:0.3]];
        break;
    default:
        break;
}

Here you store the pressed character as Unicode character and compare it to the up and down function keys. You then use an SKAction to move the character up and down accordingly.

Build and run your project; press the up and down arrow keys and you should see your character moving up and down the screen like so:

You’ve spent all this time modifying the game to be played on a Mac, but you still need to check that you haven’t affected any portion of the iOS version of the game!

Build and run your project using the iOS target and play around with it a bit to make sure none of the game functions have been affected by your changes.

Where to Go From Here?

You can grab the completed sample files for this project from here.

Now that you have a good understanding of the work required to convert your iOS targeted project to a iOS / Mac targeted project, you’ll definitely want to create any new Sprite Kit games with cross-platform capabilities right from the start. I have made a cross-platform Sprite Kit project starter template on Github that might be useful – you can clone and use for your own games.

To learn more about making games that work on both iOS and OS X (especially related to scene sizes, image sizes, and aspect ratios, and UIKit vs. Cocoa Touch considerations), check out the upcoming second edition of our book iOS Games by Tutorials, where we go into more detail.

If you have any comments or questions, feel free to join the discussion below!

How to Port Your Sprite Kit Game from iOS to OS X is a post from: Ray Wenderlich

The post How to Port Your Sprite Kit Game from iOS to OS X appeared first on Ray Wenderlich.

Learn about GameObjects, the building blocks of your Unity game, and how to convert them to a prefab to maximize their reuse.

Video Tutorial: Introduction to Unity Part 4: GameObjects is a post from: Ray Wenderlich

The post Video Tutorial: Introduction to Unity Part 4: GameObjects appeared first on Ray Wenderlich.

Learn how to implement basic card game mechanics and animation.

For over 20 years, people have played Collectible Card Games (CCGs). The Wikipedia entry gives a fairly thorough recount of how these games evolved, which appear to have been inspired by role playing games like Dungeons and Dragons. Magic the Gathering is one example of a modern CCG.

At their core, CCGs are a set of custom cards representing characters, locations, abilities, events, etc. To play the game, the players must first build their own decks, then they use their individual decks to play. Most players make decks that accentuate certain factions, creatures or abilities.

In this tutorial, you’ll use Sprite Kit to manipulate images that serve as cards in a CCG app. You’ll move cards on the screen, animate them to show which cards are active, flip them over and enlarge them so you can read the text — or just admire the artwork.

If you’re new to SpriteKit, you may want to read through a beginner tutorial or indulge yourself with the iOS Games by Tutorials book. If you’re new to Swift, make sure you check out the Swift Quick Start series.

Getting Started

Since this is a card game, the best place to start is with the actual cards. Download the starter project which provides a SpriteKit project preset for an iPad in landscape mode, as well as all the images, fonts and sound files you’ll need to create a functional sample game.

Take a minute to look around the project to acquaint yourself with its file structure and content. You should see the following project folders:

1. System: Contains the basic files to set up a SpriteKit project. This includes AppDelegate.swift, GameViewController.swift, and Main.storyboard
2. Scenes: Contains an empty main scene GameScene.swift which will manage the game content.
3. Card: Contains an empty Card.swift file which will manage the playing cards.
4. Supporting Files: Contains all the images, fonts, and sound files you’ll use in the tutorial.

This game just wouldn’t be as cool without the art, so I’d like to give special thanks to Vicki from gameartguppy.com for the beautiful card artwork!

A Classy Start

Since you can’t play a card game without cards, start by making a class to represent them. Card.swift is currently a blank Swift file, so find it and add:

import Foundation
import SpriteKit
 
class Card : SKSpriteNode {
 
  required init(coder aDecoder: NSCoder!) {
    fatalError("NSCoding not supported")
  }
 
  init(imageNamed: String) {
    let cardTexture = SKTexture(imageNamed: imageNamed)
    super.init(texture: cardTexture, color: nil, size: cardTexture.size())
  }
}

You’re declaring Card as a subclass of SKSpriteNode.

To create a simple sprite with an image, you would use SKSpriteNode(imageNamed:). In order to keep this behavior, you use the inherited initializer which must call the super classes designated initializer init(texture:color:size:). You do not support NSCoding in this game.

To put sprites on the screen, open GameScene.swift and add the following code to didMoveToView():

let wolf = Card(imageNamed: "card_creature_wolf.png")
wolf.position = CGPointMake(100,200)
addChild(wolf)
 
let bear = Card(imageNamed: "card_creature_bear.png")
bear.position = CGPointMake(300, 200)
addChild(bear)

Build and run the project, and take a moment to admire the wolf and bear.

A good start…

Rule #1 for creating card games: start with creative, imaginative art. Looks like your app is shaping up nicely!

Looking at a couple of cards is fun and all, but the UI will be much cooler if you can actually move the cards. You’ll do that next!

I Want to Move It, Move It…

No matter the quality of the art, cards sitting on a screen won’t earn your app any rave reviews, because you need be able to drag them around like you can do with real paper cards. The simplest way to do this is to handle touches in the scene itself.

Still in GameScene.swift, add this new function to the class:

override func touchesMoved(touches: NSSet, withEvent event: UIEvent) {
  for touch in touches {
    let location = touch.locationInNode(self)
    let touchedNode = nodeAtPoint(location)
    touchedNode.position = location
  }
}

Build and run the project, and drag those two cards around the display.

The cards now move, but sometimes slide behind other cards. Read on to fix the problem.

As you play around with this, you’ll notice two major issues:

1. First, since the sprites are at the same zPosition, they are arranged in the same order they are added to the scene. This means the bear card is “above” the wolf card. If you’re dragging the wolf, it appears to slide beneath the bear.
2. Second, nodeAtPoint() returns the topmost sprite at that point. So when you drag the wolf under the bear, nodeAtPoint() returns the bear sprite and start changes its position, so you might find yourself moving the bear even though you originally moved the wolf.

While this effect is almost magical, it’s not the kind of magic you want to in the final app!

To fix this, you’ll modify the card’s zPosition while dragging. Your first inclination might be to change the zPosition of the sprite in touchesMoved, but this isn’t a good approach if you want to change it back later.

Using the beginning and ending functions is a better strategy. Still in GameScene.swift, and add the following methods:

override func touchesBegan(touches: NSSet, withEvent event: UIEvent) {
  for touch in touches {
    let location = touch.locationInNode(self)
    let touchedNode = nodeAtPoint(location)
    touchedNode.zPosition = 15
  }
}
 
override func touchesEnded(touches: NSSet, withEvent event: UIEvent) {
  for touch in touches {
    let location = touch.locationInNode(self)
    let touchedNode = nodeAtPoint(location)
    touchedNode.zPosition = 0
  }
}

Build and run the project again, and you’ll see the cards sliding over each other as you would expect.

Cards now correctly move over each other, but looks a little plain. You’ll fix that next.

Make sure you pick a zPosition value that is greater than other cards will be. In the sample game at the end of the tutorial, there are some overlay elements at zPosition of 20. The number 19 ensures the overlay elements showed over the cards.

Now the card is moving properly over other cards, but now you need to add some satisfying depth — say, a visual indication that the card has been lifted up.

Time to make your cards dance!

Card Animations

Still in GameScene.swift, add the following to the end of the code inside the for loop of touchesBegan()

let liftUp = SKAction.scaleTo(1.2, duration: 0.2)
touchedNode.runAction(liftUp, withKey: "pickup")

and similarly in touchesEnded()

let dropDown = SKAction.scaleTo(1.0, duration: 0.2)
touchedNode.runAction(dropDown, withKey: "drop")

Here you’re using the scaleTo(scale:duration:) method of SKAction to grow the width and height of the card to 1.2x its original size when clicked and back down to 1.0 when released.

Build and run the project to see how this looks.

This simple animation gives the appearance of picking up a card and putting it back down. Sometimes the simplest animations are the most effective.

Tinker with the scale and duration values to find what the levels that look best to you. If you set the lift and drop durations as different values you can make it appear as though that card lifts slowly, then drops quickly when released.

Wiggle, Wiggle, Wiggle

Dragging cards around now works pretty well, but you should add a bit of flair. Making the cards appear to flutter around their y-axis certainly qualifies as flair.

Since SpriteKit is a pure 2D framework, there doesn’t seem to be any way to do a partial rotation effect on a sprite. What you can do, however, is change the xScale property to give the illusion of rotation.

Again, you’ll add code to the touchesBegan() and touchesEnded() pair of functions. In touchesBegan() add the following code to the end of the for loop:

let wiggleIn = SKAction.scaleXTo(1.0, duration: 0.2)
let wiggleOut = SKAction.scaleXTo(1.2, duration: 0.2)
let wiggle = SKAction.sequence([wiggleIn, wiggleOut])
let wiggleRepeat = SKAction.repeatActionForever(wiggle)
 
touchedNode.runAction(wiggleRepeat, withKey: "wiggle")

And similarly, in touchesEnded() add:

touchedNode.removeActionForKey("wiggle")

This code makes the card appear to rotate back and forth — just a tad — as it moves around. This effect makes use of the reaction(action:, withKey:) method to add a string name to the action so that you can cancel it later.

There is a small caveat to this approach: when you remove the animation, it leaves the sprite wherever it is in the animation cycle.

You already have an action to return the card to its initial scale value of 1.0. Since scale sets both the x and y scale, that part is taken care of, but if you use another property, remember to return the initial value in the touchesEnded function.

Build and run the project, so you can see the cards now flutter when you drag them around.

A simple animation to show that this card is currently active.

Challenge: In the bonus example game at the end of the tutorial, you’ll learn about using zRotation to make the cards wobble back and forth.

Try replacing the scaleXTo actions with rotateBy to replace the “wiggle” animation with a “rocking” animation. Remember to make it a cycle, which means it needs to return to its starting point before repeating.

Try to reproduce this effect for the wiggle animation.

Solution Inside

SelectShow>

Replace the current wiggle code with the following in touchesBegan: let rotR = SKAction.rotateByAngle(0.15, duration: 0.2) let rotL = SKAction.rotateByAngle(-0.15, duration: 0.2) let cycle = SKAction.sequence([rotR, rotL, rotL, rotR]) let wiggle = SKAction.repeatActionForever(cycle) touchedNode.runAction(wiggle, withKey: "wiggle") This gives your cards a satisfying little wiggle, but there’s still one problem. Try dropping the card mid-cycle. Does it rotate incorrectly? Yes, and that’s your next problem to solve, by adding the following line to touchesEnded at the end of the for loop: runAction(SKAction.rotateToAngle(0, duration: 0.2), withKey:"rotate") Now you have a nice looking wiggle action that properly rotates itself when you let go of a card!

Tracking Damage

In many collectible card games, monsters like these have hit points associated with them, and can fight each other.

To implement this, you’ll need a label on top of the cards so the user can track damage inflicted on each creature. Still in GameScene.swift, add the following new method:

func newDamageLabel() -> SKLabelNode {
  let damageLabel = SKLabelNode(fontNamed: "OpenSans-Bold")
  damageLabel.name = "damageLabel"
  damageLabel.fontSize = 12
  damageLabel.fontColor = UIColor(red: 0.47, green: 0.0, blue: 0.0, alpha: 1.0)
  damageLabel.text = "0"
  damageLabel.position = CGPointMake(25, 40)
 
  return damageLabel
}

This helper method creates a new SKLabelNode which in turn will display the damage inflicted upon each card. It uses a custom font that is included in the starter project with the correct info.plist settings.

Are you wondering how the position works in this example?

Since the label is a child of the card sprite, the position is relative to the sprite’s anchor point and that is the center, by default. Usually this just takes some trial and error to get the label positioned exactly where you want it.

Use this new method to add a damage label to each card by adding the following code to the end of didMoveToView():

wolf.addChild(newDamageLabel())
bear.addChild(newDamageLabel())

Build and run the project. You should now see a red ’0′ within each card.

Cards now have a label that shows how much damage they’ve taken.

Try dragging a card, but click on the label to start dragging rather than the card itself. Notice that the label flys off somewhere — perhaps to a magical kingdom where it can rule with impunity?

No, it’s not actually that mysterious. ;]

The problem here is that when you call nodeAtPoint it returns the topmost SKNode of any type, which in this case is the SKLabelNode. When you then change the node’s position, the label moves instead of the card. Ahhh…yes, there is a logical explanation.

The result of starting a touch on top of the damage label. Oops. (Changed the background to white to make the label more visible)

Pros and Cons Of Scene Touch Handling

Before going any further, let’s stop for a moment and muse upon some of the advantages and disadvantages of handling the touches at the scene level.

Touch handling at the scene level is a good place to start working with a project because it’s the simplest, easiest approach. In fact, if your sprites have transparent regions that should be ignored, such as hex grids, this may be the only reasonable solution.

However, it starts to fall apart when you have composite sprites. For example, these could contain multiple images, labels or even a health bar. It can also be unwieldy and complicated if you have different rules for different sprites.

One gotcha that comes into play when you use nodeAtPoint is that it always returns a node.

What if you drag outside of one of the card sprites? Because SKScene is a subclass of SKNode, if the touch location intersects no other node, the scene itself returns as a SKNode.

When you changed the position and did animations before, you may not have known but you really should’ve checked to see that touchedNode was not the scene itself, but it’s okay because this is a learning experience.

You’ll be happy to know there is a better solution…

Handle Those Touches! Handle Them!

What can you do instead? Well, you can make the Card class responsible for handling its own touches. The logistics of this approach are fairly straightforward. Open Card.swift and add the following to init(imageNamed:):

userInteractionEnabled = true

This allows the Card class to intercept touches as opposed to passing them through to the scene. SpriteKit will send touch events to the topmost instance with this property set.

Next, you remove the three touch handler functions,touchesBegan(), touchesMoved(), and touchesEnded() from GameScene.swift and add them to Card.swift.

The original code won’t work exactly as-is, so it needs some changes to work within the node.

As a challenge, see if you can make the appropriate changes without checking the spoiler!

Hint: Since touch events are sent directly to the correct sprite, you don’t have to figure out which sprite to modify.

override func touchesBegan(touches: NSSet, withEvent event: UIEvent) {
  for touch in touches {
    // note: removed references to touchedNode
    // 'self' in most cases is not required in Swift
    zPosition = 15
    let liftUp = SKAction.scaleTo(1.2, duration: 0.2)
    runAction(liftUp, withKey: "pickup")
 
    let wiggleIn = SKAction.scaleXTo(1.0, duration: 0.2)
    let wiggleOut = SKAction.scaleXTo(1.2, duration: 0.2)
    let wiggle = SKAction.sequence([wiggleIn, wiggleOut])
    let wiggleRepeat = SKAction.repeatActionForever(wiggle)
 
    // again, since this is the touched sprite
    // run the action on self (implied)
    runAction(wiggleRepeat, withKey: "wiggle")
  }
}
 
override func touchesMoved(touches: NSSet, withEvent event: UIEvent) {
  for touch in touches {
    let location = touch.locationInNode(scene) // make sure this is scene, not self
    let touchedNode = nodeAtPoint(location)
    touchedNode.position = location
  }
}
 
override func touchesEnded(touches: NSSet, withEvent event: UIEvent) {
  for touch in touches {
    zPosition = 0
    let dropDown = SKAction.scaleTo(1.0, duration: 0.2)
    runAction(dropDown, withKey: "drop")
    removeActionForKey("wiggle")
  }
}

Build and run the project, and you’ll notice that this fixes the earlier issue of the flying label.

Card can be moved the same as before.

Two Sides of the Story

Now take a moment to observe how the Card nodes initialize. Currently, you’re simply using the string image name to create a texture, and sending that to the superclass initializer.

In order to add attributes like attack and defense values, or mystical spell effects, you need to setup properties and configure them based on the specific card’s data. Instead of using strings to identify cards, which are prone to typos, you can define an enumeration instead. Open Card.swift and add the following between the import lines and the class definition:

enum CardName: Int {
    case CreatureWolf = 0,
    CreatureBear,       // 1
    CreatureDragon,     // 2
    Energy,             // 3
    SpellDeathRay,      // 4
    SpellRabid,         // 5
    SpellSleep,         // 6
    SpellStoneskin      // 7
}

This defines CardName as a new type that you can use to identify individual cards. The integer values will be helpful as a reference when working with the cards in a deck.

Next, you need to define some custom properties for the Card class. Add this between the class declaration line and init

let frontTexture: SKTexture
let backTexture: SKTexture
var largeTexture: SKTexture?
let largeTextureFilename: String

Replace init(imageNamed:) in Card.swift with

init(cardNamed: CardName) {
 
  // initialize properties
  backTexture = SKTexture(imageNamed: "card_back.png")
 
  switch cardNamed {
  case .CreatureWolf:
    frontTexture = SKTexture(imageNamed: "card_creature_wolf.png")
    largeTextureFilename = "card_creature_wolf_large.png"
 
  case .CreatureBear:
    frontTexture = SKTexture(imageNamed: "card_creature_bear.png")
    largeTextureFilename = "Card_creature_bear_large.png"
 
  default:
    frontTexture = SKTexture(imageNamed: "card_back.png")
    largeTextureFilename = "card_back_large.png"
  }
 
  // call designated initializer on super
  super.init(texture: frontTexture, color: nil, size: frontTexture.size())
 
 
  // set properties defined in super
  userInteractionEnabled = true
}

Finally, open GameScene.swift and change didMoveToView() to use the new enum instead of the string filename:

let wolf = Card(cardNamed: .CreatureWolf)
wolf.position = CGPointMake(100,200)
addChild(wolf)
 
let bear = Card(cardNamed: .CreatureBear)
bear.position = CGPointMake(300, 200)
addChild(bear)

There are several changes here:

• First, you add a new type called CardName, the advantage of an enum like this is that the compiler knows all the possible values and it will warn you if you mistype one of the names. Additionally, Xcode autocomplete should be able to help as you type the first few characters of the name.
• Next, you create four new properties in Card.swift to store the values of each SKTexture, which will be utilized based on the state of the card. Each card requires a front image, back image and large front image. largeTextureFilename is there to save memory by preventing a large image from loading until it’s actually needed.
• Next you update the init method to take a CardName rather than a String and set each of the newly created properties based on the type of Card. This makes use of the new-and-improved switch statement in Swift. Here, switch cases do not automatically fall through. Additionally, you must either provide a default case, or cover all possible values. Once you have custom properties, such as attack and defense, you can assign those values inside the switch statement.

  There is a specific order you have to follow when initializing swift objects.

  • First, make sure all of the properties defined in the class have default values.
  • Second, call a designated initializer for the superclass.
  • Third, set any properties defined in the superclass, and call any functions you need to on the object.
• Lastly, you update the code in GameScene.swift to use the new init method of Card.

Build and run the project, and make sure that everything works just as it did before.

Challenge:
Finish Card by adding the correct images for the other cards, such as the fierce dragon. You’ll find the images in the cards folder inside Supporting Files.

Dun Dun Dun

Flip Flop

Finally, add some card-like actions to make the game more realistic. Since the basic premise is that two players will share an iPad, the cards need to be able to turn face down so the other player cannot see them.

An easy way to do this is to make the card flip over when you double tap it. However, you need a property to keep track of the card state to make this possible.

Open Card.swift and add the following property below the other properties:

var faceUp = true

Next, add a function to swap the textures that will make a card appears flipped:

func flip() {
  if faceUp {
    self.texture = self.backTexture
    if let damageLabel = self.childNodeWithName("damageLabel") {
      damageLabel.hidden = true
    }
    self.faceUp = false
  } else {
    self.texture = self.frontTexture
    if let damageLabel = self.childNodeWithName("damageLabel") {
      damageLabel.hidden = false
    }
    self.faceUp = true
  }
}

Finally, add the following to the beginning of touchesBegan, just inside the for-in loop.

if touch.tapCount > 1 {
  flip()
}

Now you understand why you saved the front and back card images as textures earlier — it makes flipping the cards delightfully easy. You also hide damageLabel so the number is not shown when the card is face down.

Build and run the project and flip those cards.

Simple card flip by swapping out the texture. The little bounce is the pick-up animation triggered by the first touch.

The effect is ok, but you can do better. One trick is to use the scaleToX animation to make it look as though it actually flips.

Replace flip with:

func flip() {
  let firstHalfFlip = SKAction.scaleXTo(0.0, duration: 0.4)
  let secondHalfFlip = SKAction.scaleXTo(1.0, duration: 0.4)
 
  setScale(1.0)
 
  if faceUp {
    runAction(firstHalfFlip) {
      self.texture = self.backTexture
      if let damageLabel = self.childNodeWithName("damageLabel") {
        damageLabel.hidden = true
      }
      self.faceUp = false
      self.runAction(secondHalfFlip)
    }
  } else {
    runAction(firstHalfFlip) {
      self.texture = self.frontTexture
      if let damageLabel = self.childNodeWithName("damageLabel") {
        damageLabel.hidden = false
      }
      self.faceUp = true
      self.runAction(secondHalfFlip)
    }
  }
}

The scaleXTo action shrinks only the horizontal direction and gives it a pretty cool 2D flip animation. The animation splits into two halves so that you can swap the texture halfway. The setScale function makes sure the other scale animations don’t get in the way.

Build and run the project to see the new “flip” effect in action.

Now you have a nice looking flip animation.

Things are looking great, but you can’t fully appreciate the bear’s goofy grin when the cards are so small. If only you could enlarge a selected card to see its details…

Big Time

The last effect you’ll work with in this tutorial is modifying the double tap action so that it enlarges the card. Add these two properties to the beginning of Card.swift with the other properties:

var enlarged = false
var savedPosition = CGPointZero

Add the following method to perform the enlarge action:

func enlarge() {
  if enlarged {
    enlarged = false
    zPosition = 0
    position = savedPosition
    setScale(1.0)
  } else {
    enlarged = true
    savedPosition = position
    zPosition = 20
    position = CGPointMake(CGRectGetMidX(parent.frame), CGRectGetMidY(parent.frame))
    removeAllActions()
    setScale(5.0)
  }
}

Remember to update touchesBegan() to call the new function, instead of flip()

if touch.tapCount > 1 {
  enlarge()
}
 
if enlarged { return }

Finally, make a small update to touchesMoved() and touchesEnded by adding the following line to each before the for-in loop:

if enlarged { return }

You need to add the extra property savedPosition so the card can be moved back to its original position. This is the point when touch-handling logic becomes a bit tricky, as mentioned earlier.

The tapCount check at the beginning of the function prevents glitches when the card is enlarged and then tapped again. Without the early return, the large image would shrink and start the wiggle animation.

It also doesn’t make sense to move the enlarged image, and there is nothing to do when the touch ends, so both functions return early when the card is enlarged.

Build and run the app to see the card grow and grow to fill the screen.

Basic card enlarging. Would look much better with some animation, and the enlarged image is fuzzy.

But why is it all pixelated? Vicki’s artwork is much too nice to place under such duress. You’re enlarging this way because you’re not using the large versions of the images in the cards_large folder inside Supporting Files.

Because loading the large images for all the cards at the beginning can waste memory, it’s best to make it so they don’t load until the user needs them.

The final version of the enlarge function is as follows:

func enlarge() {
  if enlarged {
    let slide = SKAction.moveTo(savedPosition, duration:0.3)
    let scaleDown = SKAction.scaleTo(1.0, duration:0.3)
    runAction(SKAction.group([slide, scaleDown])) {
      self.enlarged = false
      self.zPosition = 0
    }
  } else {
    enlarged = true
    savedPosition = position
 
    if largeTexture != nil {
      texture = largeTexture
    } else {
      largeTexture = SKTexture(imageNamed: largeTextureFilename)
      texture = largeTexture
    }
 
    zPosition = 20
 
    let newPosition = CGPointMake(CGRectGetMidX(parent.frame), CGRectGetMidY(parent.frame))
    removeAllActions()
 
    let slide = SKAction.moveTo(newPosition, duration:0.3)
    let scaleUp = SKAction.scaleTo(5.0, duration:0.3)
    runAction(SKAction.group([slide, scaleUp]))
  }
}

The animations are fairly straightforward at this point.

The card’s position saves before running an animation, so it returns to its original position. To prevent the pickup and drop animations from interfering with the animation as it scales up, you add the removeAllActions() function.

When the scale down animations run, the enlarged and zPosition properties don’t set until the animation completes. If these values change earlier, an enlarged card sitting behind another card will appear to slide underneath as it returns to its previous position.

Since largeTexture is defined as an optional, it can have a value of nil, or “no value”. The if statement tests to see if it has a value, and loads the texture if it doesn’t.

Build and run the app once again. You should now see a nice, smooth animation from the card’s initial position to the final enlarged position. You’ll also see the cards in full, clean, unpixelated splendor.

Animating the card enlargement, and swapping to the large image make this look much nicer.

Where to Go from Here?

The final project for this tutorial can be found here.

At this point, you understand the basic — and some not so basic — card mechanics that you can put to use in your own card game.

This sample project has many subtle animations that you can tweak, so make sure you play around with the different values to find what you like and what works for you.

Once you’re happy with the animations, there are board regions, decks, attacks and many other features that are simply too much to address in a single article like this. Take a look at the completed example game in Objective-C and Swift to learn more about the other elements that go into game development.

Use the forum below to comment, ask questions or share your ideas for animating cards with Swift. Thanks for taking the time to work through this tutorial!

Card Game Mechanics in Sprite Kit with Swift is a post from: Ray Wenderlich

The post Card Game Mechanics in Sprite Kit with Swift appeared first on Ray Wenderlich.

Learn how to make a custom control like a slider that has two thumbs

Update note: This tutorial was updated for iOS 8 and Swift by Mikael Konutgan. Original post by Tutorial Team member Colin Eberhardt.

User interface controls are one of the most important building blocks of any application. They serve as the graphical components that allow your users to view and interact with your application. Apple supplies a set of controls, such as UITextField, UIButton and UISwitch. Armed with this toolbox of pre-existing controls, you can create a great variety of user interfaces.

However, sometimes you need to do something just a little bit different; something that the stock controls can’t handle quite the way you want.

Custom controls are nothing more than controls that you have created yourself; that is, controls that do not come with the UIKit framework. Custom controls, just like standard controls, should be generic and versatile. As a result, you’ll find there is an active and vibrant community of developers who love to share their custom control creations.

In this tutorial, you will implement your very own RangeSlider custom control. This control is like a double-ended slider, where you can pick both a minimum and maximum value. You’ll touch on such concepts as extending existing controls, designing and implementing your control’s API, and even how to share your new control with the development community.

Time to start customizing!

Getting Started

Say you’re developing an application for searching property-for-sale listings. This fictional application allows the user to filter search results so they fall within a certain price range.

You could provide an interface which presents the user with a pair of UISlider controls, one for setting the maximum price and one for setting the minimum price. However, this interface doesn’t really help the user visualize the price range. It would be much better to present a single slider with two thumbs to indicate the high and low price range they are searching for.

You could build this range slider by subclassing UIView and creating a bespoke view for visualizing price ranges. That would be fine for the context of your app — but it would be a struggle to port it to other apps.

It’s a much better idea to make this new component as generic as possible, so that you can reuse it in any context where it’s appropriate. This is the very essence of custom controls.

Fire up Xcode. Go to File/New/Project, select the iOS/Application/Single View Application template and click Next. On the next screen, enter CustomSliderExample as the product name, choose your desired Organization Name and Organization Identifier, then make sure that Swift is selected as the language, iPhone is selected as the Device and that Use Core Data is not selected.

Finally choose a place to save the project and click Create.

The first decision you need to make when creating a custom control is which existing class to subclass, or extend, in order to make your new control.

Your class must be a UIView subclass in order for it be available in the application’s UI.

If you check Apple’s UIKit reference, you’ll see that a number of the framework controls such as UILabel and UIWebView subclass UIView directly. However, there are a handful, such as UIButton and UISwitch which subclass UIControl, as shown in the hierarchy below:

UIControl implements the target-action pattern, which is a mechanism for notifying subscribers of changes. UIControl also has a few properties that relate to control state. You’ll be using the target-action pattern in this custom control, so UIControl will serve as a great starting point.

Right-click the CustomSliderExample group in the Project Navigator and select New File…, then select the iOS/Source/Cocoa Touch Class template and click Next. Call the class RangeSlider, enter UIControl into the Subclass of field and make sure the language is Swift. Click Next and then Create to choose the default location to store the file associated with this new class.

Although writing code is pretty awesome, you probably want to see your control rendered on the screen to measure your progress! Before you write any code for your control, you should add your control to the view controller so that you can watch the evolution of the control.

Open up ViewController.swift and replace its contents with the following:

import UIKit
 
class ViewController: UIViewController {
    let rangeSlider = RangeSlider(frame: CGRectZero)
 
    override func viewDidLoad() {
        super.viewDidLoad()
 
        rangeSlider.backgroundColor = UIColor.redColor()
        view.addSubview(rangeSlider)
    }
 
    override func viewDidLayoutSubviews() {
        let margin: CGFloat = 20.0
        let width = view.bounds.width - 2.0 * margin
        rangeSlider.frame = CGRect(x: margin, y: margin + topLayoutGuide.length,
            width: width, height: 31.0)
    }
}

The above code simply creates an instance of your all-new control in the given frame and adds it to the view. The control background color has been set to red so that it will be visible against the app’s background. If you didn’t set the control’s background to red, then the control would be clear — and you’d be wondering where your control went! :]

Build and run your app; you should see something very similar to the following:

Before you add the visual elements to your control, you’ll need a few properties to keep track of the various pieces of information that are stored in your control. This will form the start of your control’s Application Programming Interface, or API for short.

Adding Default Control Properties

Open up RangeSlider.swift and replace the code with the following:

import UIKit
 
class RangeSlider: UIControl {
    var minimumValue = 0.0
    var maximumValue = 1.0
    var lowerValue = 0.2
    var upperValue = 0.8
}

These four properties are all you need to describe the state of this control, providing maximum and minimum values for the range, along with the upper and lower values set by the user.

Well-designed controls should define some default property values, or else your control will look a little strange when it draws on the screen! You did that above as well.

Now it’s time to work on the interactive elements of your control; namely, the thumbs to represent the high and low values, and the track the thumbs slide on.

Images vs. CoreGraphics

There are two main ways that you can render controls on-screen:

1. Images – create images that represent the various elements of your control
2. CoreGraphics – render your control using a combination of layers and CoreGraphics

There are pros and cons to each technique, as outlined below:

Images — constructing your control using images is probably the simplest option in terms of authoring the control — as long as you know how to draw! :] If you want your fellow developers to be able to change the look and feel of your control, you would typically expose these images as UIImage properties.

Using images provides the most flexibility to developers who will use your control. Developers can change every single pixel and every detail of your control’s appearance, but this requires good graphic design skills — and it’s difficult to modify the control from code.

Core Graphics — constructing your control using Core Graphics means that you have to write the rendering code yourself, which will require a bit more effort. However, this technique allows you to create a more flexible API.

Using Core Graphics, you can parameterize every feature of your control, such as colors, border thickness, and curvature — pretty much every visual element that goes into drawing your control! This approach allows developers who use your control to fully tailor it to suit their needs.

In this tutorial you’ll use the second technique — rendering the control using Core Graphics.

Open up RangeSlider.swift and add the following import to the top of the file, just below import UIKit:

import QuartzCore

Add the following properties to RangeSlider, just after the ones we defined above:

let trackLayer = CALayer()
let lowerThumbLayer = CALayer()
let upperThumbLayer = CALayer()
 
var thumbWidth: CGFloat {
    return CGFloat(bounds.height)
}

These three layers — trackLayer, lowerThumbLayer, and upperThumbLayer — will be used to render the various components of your slider control. thumbWidth will be used for layout purposes.

Next up are some default graphical properties of the control itself.

Inside the RangeSlider class, add an initializer and the following helper functions:

init(frame: CGRect) {
    super.init(frame: frame)
 
    trackLayer.backgroundColor = UIColor.blueColor().CGColor
    layer.addSublayer(trackLayer)
 
    lowerThumbLayer.backgroundColor = UIColor.greenColor().CGColor
    layer.addSublayer(lowerThumbLayer)
 
    upperThumbLayer.backgroundColor = UIColor.greenColor().CGColor
    layer.addSublayer(upperThumbLayer)
 
    updateLayerFrames()
}
 
func updateLayerFrames() {
    trackLayer.frame = bounds.rectByInsetting(dx: 0.0, dy: bounds.height / 3)
    trackLayer.setNeedsDisplay()
 
    let lowerThumbCenter = CGFloat(positionForValue(lowerValue))
 
    lowerThumbLayer.frame = CGRect(x: lowerThumbCenter - thumbWidth / 2.0, y: 0.0,
      width: thumbWidth, height: thumbWidth)
    lowerThumbLayer.setNeedsDisplay()
 
    let upperThumbCenter = CGFloat(positionForValue(upperValue))
    upperThumbLayer.frame = CGRect(x: upperThumbCenter - thumbWidth / 2.0, y: 0.0,
        width: thumbWidth, height: thumbWidth)
    upperThumbLayer.setNeedsDisplay()
}
 
func positionForValue(value: Double) -> Double {
    let widthDouble = Double(thumbWidth)
    return Double(bounds.width - thumbWidth) * (value - minimumValue) /
        (maximumValue - minimumValue) + Double(thumbWidth / 2.0)
}

The initializer simply creates three layers and adds them as children of the control’s root layer, then updateLayerFrames, well, updates the layer frames to fit! :]

Finally, positionForValue maps a value to a location on screen using a simple ratio to scale the position between the minimum and maximum range of the control.

Next, override frame, and implement a property observer by adding the following to RangeSlider.swift:

override var frame: CGRect {
    didSet {
        updateLayerFrames()
    }
}

The property observer updates the layer frames when the frame changes. This is necessary when the control is initialized with a frame that is not its final frame like in ViewController.swift.

Build and run your app; your slider is starting to take shape! It should look similar to the screenshot below: