There is something different that we have done in the previous view. We have an ng-controller declaration for WorkoutAudioController inside the existing parent controller context WorkoutController.

$routeProvider.when('/workout', { templateUrl: 'partials/workout.html', controller: 'WorkoutController' });

This effectively creates a child MVC component within the parent MVC component. Also, since the ng-controller directive creates a new scope, the child MVC component has its own scope to play with. The following screenshot highlights this hierarchy:

This new scope inherits (prototypal inheritance) from the parent scope, and has access to the model state defined on parent $scope. Such segregation of functionality helps in better organization of code and makes implementation simple. As views and controllers start to become complex, there are always opportunities to split a large view into smaller manageable subviews that can have their own model and controller as we are doing with our workout audio view and controller.

We could have moved the view template (the span container) for audio into a separate file and included it in the workout.html file using ng-include (as done for description-panel.html), hence achieving a true separation of components. However, for now we are just decorating the span with the ng-controller attribute.

Let's add the WorkoutAudioController function to the workout.js file itself. Open workout.js and start with adding the WorkoutAudioController declaration and some customary code after the WorkoutController implementation:

angular.module('7minWorkout')
  .controller('WorkoutAudioController', ['$scope', '$timeout', function ($scope, $timeout)    {
   $scope.exercisesAudio = [];
   var init = function () {
   }
   init();
}]);

The standard controller declaration has a skeleton init method and the exercisesAudio property, which will store all audio clips for each exercise defined in Exercise.nameSound.

When should this array be filled? Well, when the workout (workoutPlan) data is loaded. When does that happen? WorkoutAudioController does not know when it happens, but it can use the AngularJS watch infrastructure to find out. Since the WorkoutAudioController scope has access to the workoutPlan property defined on the parent controller scope, it can watch the property for changes. This is what we are going to do. Add this code after the declaration of the exercisesAudio array in WorkoutAudioController:

var workoutPlanwatch = $scope.$watch('workoutPlan', function (newValue, oldValue) {
    if (newValue) {  // newValue==workoutPlan
        angular.forEach( $scope.workoutPlan.exercises, 
        function (exercise) {
            $scope.exercisesAudio.push({
                src: exercise.details.nameSound,
                type: "audio/wav"
            });
        });
        workoutPlanwatch(); //unbind the watch.
    }
});

This watch loads all the exercise name audio clips into the exercisesAudio array once workoutPlan is loaded.

One interesting statement here is:

workoutPlanwatch();

As the comment suggests, it is a mechanism to remove the watch from an already watched scope property. We do it by storing the return value of the $scope.$watch function call, which is a function reference. We then can call this function whenever we want to remove the watch, which is the case after the first loading of workoutPlan data. Remember the workout data is not going to change during the workout.

Similarly, to track the progress of the exercise, we need to watch for the currentExercise and currentExerciseDuration properties. Add these two watches following the previous watch:

$scope.$watch('currentExercise', function (newValue, oldValue) {
  if (newValue && newValue !== oldValue) {
    if ($scope.currentExercise.details.name == 'rest') {
      $timeout(function () { $scope.nextUpAudio.play();}
, 2000);
      $timeout(function () { $scope.nextUpExerciseAudio.play($scope.currentExerciseIndex + 1, true);}
, 3000);
}
    }
});

$scope.$watch('currentExerciseDuration', function (newValue, oldValue) {
if (newValue) {
if (newValue == Math.floor($scope.currentExercise.duration / 2) && $scope.currentExercise.details.name !== 'rest') {
         $scope.halfWayAudio.play();
        } 
   else if (newValue == $scope.currentExercise.duration - 3) {
            $scope.aboutToCompleteAudio.play();
        }
    }
});

The first watch on currentExercise is used to play the audio of the next exercise in line during the rest periods. Since the audio for the next exercise is a combination of two audio clips, one that echoes next-up and another that echoes the exercise name (from the array that we have built previously using the workoutPlan watch), we play them one after another. This is how the audio declaration for the the next-up audio looks:

<audio media-player="nextUpAudio" src="content/nextup.mp3"></audio>
<audio media-player="nextUpExerciseAudio" playlist="exercisesAudio"></audio>

The first one is like other audio elements that take the audio using the src attribute. However, the nextUpExerciseAudio value takes playlist, which is an array of audio sources. During every rest period, we play the audio from one of the array elements by calling:

$scope.nextUpExerciseAudio.play($scope.currentExerciseIndex + 1, true);}

To play the audio content in succession, we use $timeout to control the audio playback order. One plays after 2 seconds and the next after 3 seconds.

The second watch on currentExerciseDuration gets invoked every second and plays specific audio elements at mid-time and before the exercise ends.

Now is the time to verify the implementation, but before we do that we need to include the audio clips that we have referenced in the code. The audio files are located in the audio folder of the app inside chapter3/checkpoint2/app/content.

Copy the audio clips and refresh the workout page. Now we have full-fledged audio support in 7 Minute Workout. Wait a minute, there is a small issue! The next up exercise audio is off by one. To verify this, wait for the first exercise to complete and the rest period to start. The next up exercise audio does not match with the exercise that is coming up next, it is one step ahead. Let's fix it.

To fix the audio synchronization issue, let's first debug and identify what is causing the problem.

Put a breakpoint inside workoutPlan watch (inside the if condition) and start the workout. Wait for the breakpoint to hit. When it hits, check the value of workoutPlan.exercises:

The first time this watch is triggered (newValue is not null), the workoutPlan.exercises array has 11 elements as seen in the previous screenshot. Nonetheless, we added 12 exercises when we loaded the plan for the first time in startWorkout. This is causing the synchronization issue between the next-up audio and the exercise order. However, why do we have one element fewer?

The first line inside the startWorkout function does the necessary assignment to workoutPlan:

$scope.workoutPlan = createWorkout();

If our understanding of watches is correct, then the watch should get triggered as soon as we assign $scope.workoutPlan a value—in other words, whenever $scope.workoutPlan changes.

This is not the case, and it can be confirmed by debugging the startWorkout function. The watch does not trigger while we are inside startWorkout and well beyond that. The last line of startWorkout is:

startExercise($scope.workoutPlan.exercises.shift());

By removing an item from the exercises array, we are one item short when the watch actually triggers.

As it turns out, change detection/tracking does not work in real-time. Clearly, our understanding of watches is not 100 percent correct!

To fix this innocuous looking problem, we will have to dig deeper into the inner working of Angular and then fix parts of our workout implementation.

Let's step back and try to understand how the AngularJS watch infrastructure works. How is it able to update HTML DOM on model data changes? Remember HTML directives and interpolations too use the same watch infrastructure.

The properties that we watch in Angular are standard JavaScript objects/values and since JavaScript properties (at least till now) are not observable, there is no way for Angular to know when the model data changed.

This raises the fundamental question: how does AngularJS detect these changes?

Well, AngularJS detects changes only when the $scope.$apply(exp) function is invoked. This function can take an argument exp that it evaluates in the current scope context. Internally, $apply evaluates exp and then calls the $rootScope.$digest() function.

The call to $digest() triggers the model change detection process. The immediate question that comes to mind is: "when is $apply called and who calls it?" Before we can answer this question, it would be good to know what happens in the digest cycle.

The invoking of the $digest() function on $rootScope in the Angular world is called the digest cycle. It is termed as cycle because it is a repeating process. What happens during the digest loop is that Angular internally starts two smaller loops as follows:

Uncaught Error: 10 $digest() iterations reached. Aborting!

When both the $evalAsync and $watch loops are complete, AngularJS updates the HTML DOM and the digest cycle itself ends.

An important thing that needs to be highlighted here is that the digest cycle evaluates every model property being watched in any scope across the application. This may seem inefficient at first as on each digest cycle we evaluate each and every property being watched irrespective of where the changes are made, but this works very well in real life.

The only missing piece of the model change tracking jigsaw is: when is $scope.$apply called or when does the digest cycle run? Till now we have never invoked the $scope.$apply method anywhere.

Angular made a very plausible assumption about when the model can change. It assumes model data can get updated on events such as user interaction (via the mouse and keyboard), form field updates, Ajax calls, or timer functions such as setTimeout and setInteval. It then provided a set of directives and services that wrap these events and internally call $scope.$apply when such events occur.

Here is a source code snippet (simplified) from the ng-click directive in AngularJS:

element.on("click", function(event) {
  scope.$apply(function() {
    fn(scope, {$event:event});
   });
 });

The element.on method is a jQuery- (or jqlite)-based method that adds an event handler for click events. When the mouse click event occurs, the event handler calls scope.$apply, hence triggering the digest cycle. It is precisely for this reason that we do not litter our implementation with calls to $scope.$apply() everywhere.

Now that we know what the digest cycle is, and that change detection is not real-time, things start to make sense. The workoutPlan watch did not trigger between these two calls in startWorkout:

var startWorkout = function () {
   $scope.workoutPlan = createWorkout();
   // Existing code
   startExercise($scope.workoutPlan.exercises.shift());
 }

Here, the exercise and exercise audio arrays went out of sync. Let's fix it.

Removing elements from the exercise array after each exercise is a suboptimal implementation as we have to build this array every time the workout starts. It will be better if we do not alter the array once the exercise starts and instead use the currentExerciseIndex property with the exercises array to always locate the current exercise in progress.

Go ahead and copy the updated WorkoutController functions: startWorkout, startExercise, and getNextExercise from workout.js located in chapter2/checkpoint2/app/js/7MinWorkout.

The updated functions now are using the currentExerciseIndex instead of removing items from the exercises array.

There is a fix required in workout.html too. Update the highlighted code:

<h3 class="col-sm-6 text-right" ng-if="currentExercise.details.name=='rest'">Next up: <strong>{{workoutPlan.exercises[currentExerciseIndex + 1].details.title}}</strong></h3>

Now, the upcoming audio should be in sync with the next exercise. We can verify it by running the workout again and listening to the upcoming exercise audio during the rest period.

Other than learning about dirty checking and digest cycles, we have learned other important things in this section too. Let's summarize them as follows:

With audio support out of the way, we are one step closer to a fully functional app. One of the missing features that will be an essential addition to our app is the exercise pause feature.