Learn iOS 8 App Development, Second Edition (2014)

Chapter 9. Sweet, Sweet Music

Choosing and playing music from your iPod library is a great way to add some toe-tapping fun to your app. You can also add your own music and audio effects to actions and games. Both are relatively easy to do, and I’ll get to those straightaway. But don’t stop reading this chapter at that point. Sound in iOS apps exists in a larger world of competing audio sources, real-world events, and an ever-changing configuration of hardware. Making audio work nicely in this demanding, and sometimes complex, environment is the real test of your iOS development skills. This chapter covers the following:

· Choosing tracks from the iPod music library

· Playing music in the iPod music library

· Obtaining the details (title, artist, album, artwork) of a track

· Playing sound files

· Configuring the behavior of audio in your app

· Mixing music with other sounds

· Responding to interruptions

· Responding to hardware changes

Along the way, you’ll pick up some timesaving Xcode tricks, manage view objects without an outlet connection, and learn some mad constraint skills. Are you ready to make some noise?

Note The app you’re about to create will run in the simulator, but the simulator does not have any music in its iPod library. If you want to pick a song and play music, you’ll need a provisioned iOS device.

Making Your Own iPod

The two most common sources for prerecorded sounds in an iOS app are audio resource files and audio files in the user’s iPod library. The app you’ll develop in this chapter plays both—at the same time! It’s a dubbing app that lets you play a track from your iPod’s music library and then spontaneously add your own percussive instrument sounds. So if you’ve ever felt that Delibes’ Flower Duet (Lakmé, Act 1) would sound so much better with a tambourine, this is the app you’ve been waiting for.

Design

Your app design is a simple, one-screen affair that I’ve named DrumDub. At the bottom are controls for choosing a track from your music library and for pausing and resuming playback. At the top you’ll find information about the track that’s playing. In the middle are buttons to add percussive sounds, all shown in Figure 9-1.

Figure 9-1. DrumDub rough sketch

You’ll start by building the iPod music playback. Later you’ll add the album artwork, and finally you’ll mix in the percussion sounds. As always, start by creating a new Xcode project.

1. Use the Single View Application template.

2. Name the project DrumDub.

3. Set the language to Swift.

4. Set the device to Universal.

5. Save the project.

6. In the project’s supported interface orientations, find the iPhone/iPod section and turn off landscape left and right, leaving only portrait enabled. (The iPad version can run in any orientation.)

Adding a Music Picker

The first step is to create an interface so the user can choose a song, or songs, from their iPod music library. After Chapter 7 (where you used the photo library picker), you shouldn’t be surprised to learn that iOS provides a ready-made music picker interface. All you have to do is configure it and present it to the user.

You’ll present the music picker interface when the user taps the Song button in the interface. For that you’ll need an action. Start by adding this stub function to your ViewController.swift file:

@IBAction func selectTrack(sender: AnyObject!) {
}

Switch to the Main.storyboard Interface Builder file. In the object library, find the Toolbar object. Drag a toolbar into your interface, positioning it at the bottom of the view. The toolbar already includes a bar button item. Select it and change its Title property to Song. Connect its sent action (Control+right-drag) to the view controller’s selectTrack: action, as shown in Figure 9-2.

Figure 9-2. Connecting Song action

Switch back to the ViewController.swift file and finish your selectTrack(_:) function (new code in bold).

@IBAction func selectTrack(sender: AnyObject!) {
let picker = MPMediaPickerController(mediaTypes: .AnyAudio)
picker.delegate = self
picker.allowsPickingMultipleItems = false
picker.prompt = "Choose a song"
presentViewController(picker, animated: true, completion: nil)
}

This code creates a new MPMediaPickerController object that will let the user choose any audio type. The media picker is rather flexible and can be set up to present various types of audio and/or video content on the device. The categories for audio content are as follows:

· Music (MPMediaType.Music)

· Podcasts (MPMusicType.Podcast)

· Audiobooks (MPMediaType.AudioBook)

· iTunes U (MPMediaType.AudioITunesU)

By combining these binary values, you can configure your media picker to present any combination of those categories you desire. The constant MPMediaType.AnyAudio includes all categories, allowing the user to choose any audio item in their library. A similar set of flags allows video content to be selected.

Tip Some parameters, like the mediaTypes parameter in MPMediaPickerController(mediaTypes:), are interpreted not as a single integer value but as a collection of bits or flags. The raw value of each individual MPMediaType constant is a power of 2—a single 1 bit in the integer. You can combine them by logically ORing the values together to form arbitrary combinations, such as (.Music | .AudioBook). The resulting value would present all music tracks and audiobooks but would not let the user pick podcasts or iTunes U content. The convenient .AnyAudio constant is just all-possible audio flags ORed together.

You then make your ViewController object the picker’s delegate. For that to work, your view controller needs to conform to the MPMediaPickerControllerDelegate protocol. Add that to your class declaration now (new code in bold).

class ViewController: UIViewController, MPMediaPickerControllerDelegate {

Next, the option to allow picking multiple tracks at once is disabled. The user will be able to choose only one song at a time. And set a prompt, or title, so the user knows what you’re asking them to do.

Finally, the controller is presented, allowing it to take over the interface and choose a song. This is enough code to see it working, so give it a try. Set the project’s scheme to your iOS device and click the Run button, as shown on the left in Figure 9-3. The toolbar appears, and you can tap the Song button to bring up the music picker, browse your audio library, and choose a song, as shown on the right in Figure 9-3. If you run the app in the simulator, the picker will work, but there won’t be anything to pick (as shown on the middle of Figure 9-3).

Figure 9-3. Testing the audio picker

QUERYING THE IPOD MUSIC LIBRARY

You don’t have to use the media picker to choose items from the user’s iPod library. It’s just the most convenient method.

It’s possible to create your own interface or not have an interface at all. The iPod framework provides classes that allow your app to explore and search the user’s media collection as if it was a database. (Come to think of it, it is a database, so that description is literally true.)

You do this by creating a query object that defines what you’re searching for. This can be as simple as “all R&B songs” or more nuanced, such as “all tracks longer than 2 minutes, belonging to the ‘dance’ genre, with a BPM tag between 110 and 120.” The result is a list of media items matching that description, which you can present any way you like (cough—table—cough).

You can read more about this in the iPod Library Access Programming Guide that you will find in Xcode’s Documentation and API Reference. Read the section “Getting Media Items Programmatically” to get started.

Using a Music Player

What happens next is, well, nothing happens next. When the user picks a track or taps the Cancel button, one of these delegate functions is called:

mediaPicker(_:,didPickMediaItems:)
mediaPickerDidCancel(_:)

Nothing happened because you haven’t written either. Start by writing mediaPicker(_:,didPickMediaItems:). This method will retrieve the audio track the user picked and start it playing using an MPMusicPlayerController object.

Add the first delegate method to your ViewController class.

func mediaPicker(mediaPicker: MPMediaPickerController!,
didPickMediaItems mediaItemCollection: MPMediaItemCollection!) {
if let songChoices = mediaItemCollection {
if songChoices.count != 0 {
musicPlayer.setQueueWithItemCollection(songChoices)
musicPlayer.play()
}
}
dismissViewControllerAnimated(true, completion: nil)
}

The mediaItemCollection parameter contains the list of tracks, books, or videos the user picked. Remember that the picker can be used to choose multiple items at once. Since you set the allowsPickingMultipleItems property to false, your picker will always return a single item.

We double-check to see that at least one track was chosen (just to be sure) and then use the collection to set the music player’s playback queue. The playback queue is a list of tracks to play and works just like a playlist. In this case, it’s a playlist of one. The next statement starts the music playing. It’s that simple.

Note While the music player’s playback queue works just like a playlist, it isn’t an iPod playlist. It won’t appear in the iPod interface as a playlist, and iOS won’t save it for you. If you want this functionality in your app, you can do it yourself. Using what you learned in Chapter 5, present the items in the media collection as a table, allowing the user to reorder, delete, or add new items (using the media picker again) as they like. Call the music player’s setQueueWithItemCollection(_:) function again with the updated collection.

So, what’s the problem with this code? The problem is there is no musicPlayer property yet! Write a read-only computed property for musicPlayer that lazily creates the object.

var musicPlayer: MPMusicPlayerController {
if musicPlayer_Lazy == nil {
musicPlayer_Lazy = MPMusicPlayerController()
musicPlayer_Lazy!.shuffleMode = .Off
musicPlayer_Lazy!.repeatMode = .None
}
return musicPlayer_Lazy!
}
private var musicPlayer_Lazy: MPMusicPlayerController?

Note This code follows two well-used design patterns: singleton and lazy initialization. The code implements a computed musicPlayer property; any code that requests that property (myController.musicPlayer) invokes this code. The code checks to see whether anMPMusicPlayerController object—stored in musicPlayer_Lazy—has already been created. If not, it creates one, configures it, and saves it in the musicPlayer_Lazy instance variable. This happens only once. All subsequent requests to get musicPlayer see that the musicPlayer_Lazy variable is already set and immediately return the (single) object.

When you construct an application music player (see the “Application and iPod Music Players” sidebar), the player inherits the current iPod playback settings for things such as shuffle and repeat modes. You don’t want any of that, so you turn them off.

APPLICATION AND IPOD MUSIC PLAYERS

Your app has access to two different music player objects. The application music player belongs to your app. Its current playlist and settings exist only in your app, and it stops playing when your app stops.

You can also request the system music player object, using MPMusicPlayerController.systemMusicPlayer(). The system music player object is a direct connection to the iPod player in the device. It reflects the current state of music playing in the iPod app. Any changes you make (such as pausing playback or altering shuffle mode) change the iPod app. Music playback continues after your app stops.

There’s only one quirk. The system music player object won’t report information about media that’s being streamed, say via home sharing. But other than that, the system music player object is a transparent extension of the built-in iPod app and allows your app to participate in, and integrate with, the user’s current music activity.

Only one music player can be playing at a time. If your app starts an application music player, it takes over the music playback service, causing the built-in iPod player to stop. Likewise, if your application music player is playing and the user starts the system player, your music player is stopped.

Now toss in a delegate function to handle the case where the user declines to choose a track.

func mediaPickerDidCancel(mediaPicker: MPMediaPickerController!) {
dismissViewControllerAnimated(true, completion: nil)
}

Your basic playback code is now complete. Run your app, choose a track, and enjoy the music.

The MPMusicPlayerController object is self-contained. It takes care of all the standard iPod behavior for you. It will, for example, automatically fade out if interrupted by an alarm or incoming call or stop playback when the user unplugs their headphones. I’ll talk a lot more about these events later in this chapter.

That’s not to say you can’t influence the music player. In fact, you have a remarkable amount of control over it. You can start and stop the player, adjust the volume, skip forward or backward in the playlist, set shuffle and repeat modes, change the playback rate, and more. The player will also tell you a lot about what it’s doing and playing. Using these properties and methods, you could create your own, full-featured music player.

For this app, you don’t need a full-featured music player. But it would be nice to at least know what’s playing and be able to pause it. Get ready to add that next.

Adding Playback Control

Start by adding some buttons to pause and play the current song. These buttons will need actions, so add these two methods to your ViewController.swift file:

@IBAction func play(sender: AnyObject!) {
musicPlayer.play()
}

@IBAction func pause(sender: AnyObject!) {
musicPlayer.pause()
}

You’ll also need to update the state of the play and pause buttons, so add some connections for that.

@IBOutlet var playButton: UIBarButtonItem!
@IBOutlet var pauseButton: UIBarButtonItem!

Switch to your Main.storyboard file and add the following objects to the toolbar, inserting them to the left of the Song button, in order, as shown in Figure 9-4:

1. A Flexible Space Bar Button Item

2. A Bar Button Item, changing its style to Plain, changing its identifier to Play, and unchecking Enabled

3. A Bar Button Item, changing its style to Plain, changing its identifier to Pause, and unchecking Enabled

4. A Flexible Space Bar Button Item

Figure 9-4. Adding controls to the toolbar

Finally, set all of the connections. Control+right-click the play button and connect its action to the play: action (in the View Controller) and connect the pause button to the pause: action. Select the View Controller object and use the connections inspector to connect theplayButton outlet to the play button and to connect the pauseButton outlet to the pause button.

With the interface objects created and connected, consider for a moment how these buttons should work. You want the following:

· The play button to be active (tappable) when the music player is not currently playing

· The play button’s action to start the music playing

· The pause button to be active when the music player is playing

· The pause button’s action to pause the music player

The button’s actions will start and stop the music player. You’ll need to update the enabled state of the buttons whenever the player starts or stops playing. The first part you’ve already done, in the play(_:) and pause(_:) functions. The second half is updating the button states (enabling or disabling them) at the appropriate times, and for that you’ll need to get some information from the music player.

Receiving Music Player Notifications

The music player runs in a background thread. Normally, it plays tracks in its playlist until it runs out and stops. It can also pause in response to external events: the user presses the pause button on their headphone cable, or they unplug the iPod from a dock. How do you think your app will learn about these events?

If you said, “From delegate functions or notifications,” give yourself a big round of applause! Reading the documentation for the MPMusicPlayerController class, you discover that the music player will optionally send notifications whenever important changes occur, which happen to include when it starts or stops playing. To be notified of those events, you’ll need to register your controller object to receive them. As you remember from Chapter 5, to receive notifications you must do the following:

1. Create a notification function.

2. Register with the notification center to become an observer for the notification.

Start by adding this notification function to your ViewController.swift implementation:

func playbackStateDidChange(notification: NSNotification) {
let playing = ( musicPlayer.playbackState == .Playing )
playButton!.enabled = !playing
pauseButton!.enabled = playing
}

Your notification handler examines the current playbackState of your music player. The player’s playback state will be one of stopped, playing, paused, interrupted, seeking forward, or seeking backward. In this implementation, the only likely states are playing, stopped, interrupted, and paused.

If the player is playing, the pause button is enabled, and the play button is disabled. If it’s not playing, the opposite occurs. This presents the play button as an option whenever the player is not playing and presents the pause button when it is.

Your controller won’t receive these notifications until two additional steps are taken. First, you must register to receive these notifications. In the musicPlayer getter block, add this immediately after the player object is created and configured (new code in bold):

musicPlayer_Lazy = MPMusicPlayerController()
musicPlayer_Lazy!.shuffleMode = .Off
musicPlayer_Lazy!.repeatMode = .None
let center = NSNotificationCenter.defaultCenter()
center.addObserver( self,
selector: "playbackStateDidChange:",
name: MPMusicPlayerControllerPlaybackStateDidChangeNotification,
object: musicPlayer_Lazy)

The second step is to enable the music player’s notifications. MPMusicPlayerController does not, by default, send these notifications. You must explicitly request that it does. Immediately after the previous code, add one more line.

musicPlayer_Lazy!.beginGeneratingPlaybackNotifications()

Your playback controls are now finished. Run your app and see that they work, as shown in Figure 9-5.

Figure 9-5. Working playback controls

Both buttons start out disabled. When you choose a track to play, the pause button becomes active (the middle of Figure 9-5). If you pause the song or let it finish playing, the play button becomes active (on the right in Figure 9-5).

MVC AT WORK

You’re watching the model-view-controller design pattern at work—again. In this scenario, your music player (despite the fact it’s called a “music controller”) is your data model. It contains the state of the music playback. Whenever that state changes, your controller receives a notification and updates the relevant views—in this case, the play and pause buttons.

You didn’t write any code to update the play or pause button when you start or stop the player. Those requests are just sent to the music player. If one of those requests results in a state change, the music player posts the appropriate notifications, and the affected views are updated.

While functional, your app lacks a certain je ne sais quoi. Oh, who are we kidding? This interface is as dull as dishwater! Let’s spruce it up a bit.

Adding Media Metadata

A colorful aspect of the music player object is its nowPlayingItem property. This property returns an object containing metadata about the song that’s playing. The object works like a dictionary, revealing all kinds of interesting tidbits about the current song. This includes information such as its title, the artist, the track number, the musical genre, any album artwork, and much more.

Note Metadata is “data about data.” A file, like a document, contains data. The name of that file, when it was created, and so on, is its metadata—it’s data that describes the data in the file. A waveform stored in a song file is data. The name of the song, the artist, and its genre are all metadata.

For your app, you’ll add an image view to display the album’s cover and text fields to show the song’s title, the album it came from, and the artist. Start by adding new interface objects to Main.storyboard.

Creating a Metadata View

You’re going to add an image view and a few label views to the interface. The image view will display the song’s album artwork, while the label views will show the song, artist, and album currently playing (see Figure 9-1). But this isn’t a one-size-fits-all layout. The image and label views that would fit on an iPhone would look odd and puny on an iPad. And the layout that would look good on an iPad would look strange on an iPhone. So, what do you do?

The answer is in adaptive constraints, which are new in iOS 8. As you remember from Chapter 2, the view controller is associated with a size class. A size class is a broad indication of the space available for your interface. There are only two size classes: Regular (there’s plenty of room for your interface to spread out) and Compact (your interface needs to be tight). These aren’t indications of actual device sizes—although you can get that information if your app needs it. They’re intended to make it easy to create alternate layouts that work in a variety of device sizes and orientations, without getting tangled up in the specifics.

Your interface has two size classes, one for horizontal and one for vertical. For example, if you’re using an iPhone 5 in portrait orientation, your view’s size class will be Compact/Regular. This means the horizontal size class is Compact, and the vertical size class is Regular.

The constraint sets you’re about to create are the most complex ones in this book. But you’ll also see that, with a little planning, it’s not difficult to create sophisticated sets of layout constraints that intelligently adapt to different devices and orientations, without writing a single line of code.

Adding the Image View

Select the Main.storyboard file. Using the object library, find the Image View object and add one to the interface. Position it (roughly) in the upper-left corner of the view, as shown in Figure 9-6.

Figure 9-6. Adding the album view

The size and position of the image view will be determined by its constraints. There’s only one rule for constraints; you must add enough constraints so that iOS can unambiguously determine the view’s position (horizontal and vertical) and its size (height and width). And you can’t add constraints that conflict. OK, that’s two rules.

Coming up with constraints for a particular layout or device size is pretty easy. What’s fun is coming up with sets of constraints so your interface will lay out nicely on all devices, in all supported orientations. For DrumDub, you need only two layouts:

· For the iPhone/iPod:

o Artwork is smaller and nestled in the upper-left corner.

o The song info labels fill the space to the right.

· For the iPad:

o Artwork view is larger.

o The artwork image and song info labels split the screen, so the image is to the left of center, and the labels are to the right.

This required two set of constraints, one for a Compact/Regular (iPhone) interface and one for a Regular/Regular (iPad) interface. Furthermore, there are some constraints that are common to both interfaces. All of the needed constraints are shown in Table 9-1.

Table 9-1. Artwork Image View Constraint Sets