Stay focused on code simplicity, and don t optimize before you need to. in Objective-C

Generator Data Matrix 2d barcode in Objective-C Stay focused on code simplicity, and don t optimize before you need to.

The application we re going to build in this chapter is a simple music player. Its UI will consist of a text field for the URL of an audio file and buttons to play or pause the audio. Since we re focusing on audio in this chapter, we won t spend time walking through the UI, so we can focus solely on the audio code. Apple s audio APIs are known as Core Audio and consist of a toolbox of components that can be used to slice audio files into pieces and stream them to the audio hardware. One thing that is not a part of Core Audio is networking, and keeping this in mind is important as you design your code. Despite the fact that we re playing audio delivered over a network, audio transport is a distinct task from audio playback. If you are able to keep these tasks clearly delineated in code, you ll have an easier time refactoring and adding features.

When delivering audio to a device via the Internet, you can employ two models of delivery: streaming or downloading. With streaming audio, the audio servers deliver bytes over the network at the same bit rate as the audio. For example, audio encoded as 64kbps would be streamed out at a rate of, you guessed it, 64kbps. Streamed audio is typically used when you have a continuous, unending music stream. In the download model of audio delivery, your music is divided into discrete chunks of data (for example, one song at a time), and the client will download one data chunk as fast as possible, play it, and begin downloading the next chunk only when the first chunk is nearing completion. Each model has advantages and disadvantages. Streaming requires less memory overhead on the client (data is consumed as soon as it is delivered) and requires less complexity for the client implementation (at the expense of more complexity on the server). But streaming can also be somewhat vulnerable to audio disruptions due to network latency and dropouts. Downloaded audio, on the other hand, has greater memory overhead (since the audio segments may be quite large) and more client complexity. But downloaded audio is also more resilient to network disruptions, since the network bandwidth is fully utilized rather than capped at a fixed amount. There s no right or wrong answer in choosing between streaming or downloading, and different services use different models. Pandora happens to use a downloading model, which is the model we ll use for our sample application as well. The download model makes our servers simpler and our audio less prone to interruptions. Your mileage may vary. Our application will download audio by requesting files over a simple HTTP connection. To do this on the iPhone, you may use NSURLConnection, an Objective-C API, or it s plain C counterpart CFURLRequest. The Core Audio documentation tends to provide examples that use CFURL, and CFURL is a rawer API, with more configuration capability than NSURLConnection. However, we ve chosen to use NSURLConnection in Pandora Radio, because it s easier to use than CFURLRequest and provides plenty of power for our purposes. So we ll be using NSURLConnection in our sample application. Once bytes have been received over the network, we need to hand them off to Core Audio for playback. Figure 6-1 shows how this process works: bytes are received from the network, and bytes are then parsed into audio packets using AudioFileStream. Buffers are allocated via AudioQueue to hold packets, and then buffers are sent to the audio hardware using (again) the AudioQueue. While parsing and hardware may sound a bit scary and complex, the Core Audio APIs hide most of the difficult details of this process.