1. Code
  2. PhoneGap

Build an AudioPlayer with PhoneGap: Application Logic

Read Time:11 minsLanguages:

This is the second part of the series about Audero Audio Player. In this article, we're going to create the business logic of our player. I'll also explain some of the Cordova APIs that were introduced in the previous article.

Series Overview

Creating the Player

In this section, I'll show you the class called Player, which let us play, stop, rewind and fast-forward. The class relies heavily on the Media API; without its methods, our player will be completely useless. In addition to the Media API, this class takes advantage of the alert() method of the Notification API. The look of the alert varies among platforms. Most of the supported operating systems use a native dialog box but others, like Bada 2.X, use the classic browser's alert() function, which is less customizable. The former method accepts up to four parameters:

  1. message: A string containing the message to show
  2. alertCallback: A callback to invoke when the alert dialog is dismissed
  3. title: The title of the dialog (the default value is "Alert")
  4. buttonName: The button's text included in the dialog (the default value is "OK")

Bear in mind that Windows Phone 7 ignores the button name and always uses the default. Windows Phone 7 and 8 don't have a built-in browser alert, so if you want to use alert('message');, you have to assign window.alert = navigator.notification.alert.

Now that I've explained the APIs used by Player, we can take a look at how it's made. We have three properties:

  • media: the reference to the current sound object
  • mediaTimer: which will contain a unique interval ID created using the setInterval() function that we'll pass to clearInterval() to stop the sound's timer
  • isPlaying: a variable that specifies if the current sound is playing or not. In addition to the property, the class has several methods.

The initMedia() method initializes the media property with a Media object that represents the sound selected by the user. The latter is notified using the Notification API in case of error. The aim of the playPause, stop(), and seekPosition() methods should be obvious, so I'll move on. The resetLayout() and changePlayButton() methods are very simple. They are used to reset or update the player's layout according to the action performed by the user. The last remaining method is updateSliderPosition(),  which is similar to the time slider. The latter has zero (the beginning of the slider) as the default value for the current position, set using the value="0" attribute. This must be updated accordingly while the sound is playing to give to the user visual feedback concerning elapsed playing time.

We've uncovered all the details of this class, so here is the source code of the file:

Managing the Audio Files

This section illustrates the AppFile class that will be used to create, delete, and load the sounds using the Web Storage API. This API has two areas, Session and Local, but Cordova uses the latter. All the sounds are stored in an item titled "files" as you can see by looking at the _tableName properties.

Please note that this API is only able to store basic data. Therefore, to fit our need to store objects, we'll use the JSON format. JavaScript has a class to deal with this format called JSON. It uses the methods parse() to parse a string and recreate the appropriate data, and stringify() to convert the object in a string. As a final note, I won't be using the dot notation of the API because Windows Phone 7 doesn’t support it, so we'll use the setItem() and getItem() methods to ensure compatibility for all devices.

Now that you have an overview of how we'll store the data, let's talk about the data that we need to save. The only information that we need for each found sound is the name (name property) and an absolute path (fullPath property). The AppFile class also has a "constant", called EXTENSIONS, where we'll set the extensions that will be tested against each file. If they match up, the file will be collected by the application. We have a method to add a file (addFile()), one method to delete a file (deleteFile()), one method that deletes the whole database (deleteFiles()), and, lastly, two methods that retrieve the file from the database: getAppFiles() to retrieve all the files, and getAppFile() to retrieve just one. The class also has four comparison methods, two static (compare() and compareIgnoreCase()) and two non-static (compareTo() and compareToIgnoreCase()). The last method is the one used to retrieve the index of a certain file, getIndex(). The AppFile class enables you to perform all the basic operations you may need.

The code that implements what we've discussed can be read here:

The Utility Class

The utility.js file is very short and easy to understand. It only has two methods. One is used to convert milliseconds into a formatted string that will be shown in the player, while the other is a JavaScript implementation of the well known Java method endsWith.

Here is the source:

Putting it All Together

This section discusses the last JavaScript file of the project, application.js, which contains the Application class. Its aim is to attach events to the app page's elements. Those events will take advantage of the classes we've seen thus far and enable the player to work properly.

The code of the illustrated function is listed below:

Managing External Links

In the previous part of this series, I mentioned that an interesting point of the credits page was the attribute target="_blank" applied to the links. This section will explain why the openLinksInApp() method of the Application class makes sense.

Once upon a time, Cordova used to open external links in the same Cordova WebView that was running the application. When a link was open and the user clicked the "back" button, the last displayed page was shown exactly as it was before the user left it. In the newer version, this has changed. Nowadays, the external links are opened, by default, using the Cordova WebView if the URL is in your app's whitelist. URLs that aren't on your whitelist are opened using the InAppBrowser API. If you don't manage the links in the right way, or if the user taps a link that is shown in the InAppBrowser or the system and then chooses to go back, all the jQuery Mobile enhancements are lost. This behavior happens because the CSS and JavaScript files are loaded by the main page, and the following ones are loaded using AJAX. Before uncovering the solution, let's take a look at what's the InAppBrowser.

The InAppBrowser is a web-browser that is shown in your app when you use the call.

This API has three methods:

  • addEventListener(): Allows you to listen for three events (loadstart, loadstop, and exit) and attach a function that runs as soon as those events are fired
  • removeEventListener(): Removes a previously-attached listener.
  • close(): Used to close the InAppBrowser window.

So, what's the solution? The aim of the openLinksInApp() function, coupled with the whitelist specified in the configuration file, is to catch the clicks on all the external links recognized by using the target="_blank" attribute, and open them using the method. With this technique, we'll avoid the problem described, and our player will continue to look and work as expected.

Next Part

In the third and last installment of this series, we'll see the last remaining files so that you can complete the project and play around with it.

Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.