How to implement a podcast player in an iOS application? (part 2/2)

Since 2018, Idean has been developing Oscar, a Capgemini application that features articles, offers, experts, and podcasts related to tech and Capgemini.

Oscar is an app UI/UX design based, you can download it on the store here:

‎Capgemini Oscar

In this short series of 2 articles, we will discover how to create and add an audio player in an existing application (built for iPhone portrait only):

• The first article was about the technical part (audio, notifications, controls…).
• This second article is about the views creation and implementation.

The code is in Swift, and there might be some better solutions out there.

Previously on our journey…

In the previous article, I exposed the requirements of the podcast player. This one will focus on the views and this requirement:

Playing a playlist of audio files (from stream urls) in a persistent way across the application and on background.

The full screen player

The full screen player (PlayerDetailsViewController)

Let’s begin with few small steps:

• Import MediaPlayer.
• Define a Bool : wasPlayingBeforeSlideTouch, that will help us to handle the slider usage.
• Define 2 variables, one for the Audio and one for the Playlist.

Initialising everything

On the viewDidLoad, we have to initialise the view.

In the viewDidLoad, notice the PlayerManager.shared.addObserver(self). It is also important to remove the observer from the PlayerManager on the deinit method.

Observers

To update the view in real time, we have to observe the podcastPlayer of the PlayerManager.

We also need to define your delegate methods, in order to update the state of your view.

The controls

This part is very straightforward, all we have to do is call the PlayerManager control methods matching each of our buttons (play, pause, next, previous, forward, backward, changing rate…).

The slider

As you can see in the screenshot above, there is a UISlider that allows the user to navigate through the audio stream. To handle this, we need these methods.

Now that you have the main tips for the PlayerDetailsViewController, let’s see the small player.

The small player

This small bubble is important for keeping the player persistent in the application (even if other solutions could have been chosen).

Small player (FloatingButtonController)

So, how was it built ? Spoiler: a lot of calculus is involved!

We named it FloatingButtonController.

The window

You need your button to be embedded inside a window. This window belongs to the FloatingButtonController.

At the initialisation of the controller, the window is configured.

As you can see, the controller observes the keyboard to adapt the window level (so that the button is not displayed on top of the keyboard).

The protocol

To communicate with the PlayerManager, we created a protocol for the FloatingButtonController to implement.

Creating the view

We will not dive into the code to create the small button, or the cross in the middle of the screen (but you can find it here). We will just explore the logic behind it.

First, we need to load the view and add gestures to be informed of the interactions with the button.

Gestures

When the button is tapped, the full screen player is displayed. But what about other gestures ?

First here’s a quick reminder on our subject: the user can drag the button on both sides of the screen. For this, we can use the panGesture, that gives the position and the translation of the button. With some calculus, we can determine the future position of the button.

Second quick reminder: the user can drag the button toward the bottom area of the screen (where the delete view is) to stop the audio from being played, and close the player session.

This part was a real struggle to develop. To ease the understanding of this, let’s look at this video(recorded from an iPhone simulator).

To show and hide the controller:

Putting everything together

Finally, let’s go back to the PlayerManger. This singleton creates the views, takes care of their visibility, updates their state and content.

This code is pretty straightforward. First, you can see the variables used to keep track of views and controllers. Then, the setup methods to instantiate the small player (button) and the big player (details). In the end, the methods to show and hide them.

Recap

This feature was not a small one, so I hope my explanations on how it was made could inspire or help you in some ways.

You can find the entire code of the mini-serie here (of course, you can adapt it to fit your needs).

Feel free to share your feedback in the comments! And don’t hesitate to tell me if this was helpful.

Thank you for reading.