The idea behind DI is that an object does not create/manage its own dependencies; instead the dependencies are provided from the outside. These dependencies are made available either through a constructor, called constructor injection (as with Angular), or by directly setting the object properties, called property injection.

Here is a rudimentary example of DI in action. Consider a class Component that requires a Logger object for some logging operation.

function Component() {
  var logger = new Logger(); //Logger is now ready to be used.
}

The dependency of the Logger class is hardwired inside the component. What if we externalize this dependency? So the class becomes:

function Component(l) {
  var logger=l;
}

This innocuous-looking change has a major impact. By adding the ability to provide the dependency from an external source, we now have the capability to alter the logging behavior of the Component class without touching it. For example, we have the following lines of code:

var c1WithDBLog=new Component(new DBLogger());
var c1WithFileLog=new Component(new FileLogger());

We create two Component objects with different logging capabilities without altering the Component class implementation. The c1WithDBLog object logs to a DB and c1WithFileLog to a file (assuming both DBLogger and FileLogger are derived from the Logger class). We can now understand how powerful DI is, in allowing us to change the behavior of a component just by manipulating its dependencies.

Once DI is in place, the responsibility for resolving the dependencies falls on the calling code or client/consumer code that wants to use the Component class.

To make this process less cumbersome for the calling code, we have DI containers/frameworks. These containers are responsible for constructing the dependencies and providing them to our client/consumer code. The AngularJS DI framework does the same for our controllers, directives, filters, and services.

We have already seen an example of DI where the $scope object is magically injected into the controller function:

angular.module('7minWorkout').controller('WorkoutController', function($scope){

Here, we instruct AngularJS that whenever it instantiates the controller, it should inject the scope that was created as part of the ng-controller directive declaration. The preceding line is an implicit DI. As AngularJS is creating the controller and injecting the dependency, everything is transparent to us. We just use the injected dependencies.

To resolve dependencies, AngularJS uses name matching. For each dependency (a parameter such as $scope) defined on the function, Angular tries to locate the dependency from a list of components that have already been registered.

This search is done based on the name of the parameter. In the preceding controller function declaration, we need to provide the $scope string verbatim for DI to work. We can try this out by changing the function parameter $scope in function($scope) to $scope1 and refreshing the browser. The developer console will show the following error:

Error: [$injector:unpr] Unknown provider: $scope1Provider <- $scope1

The approach of using names for dependency resolution has its downsides. One of them is that the previous code breaks when minified.

.controller('WorkoutController', function($scope){

.controller('WorkoutController', ['$scope', function($scope) {

The $interval service is a wrapper over the window.setInterval method. The primary purpose of this service is to call a specific function continuously, at specific intervals.

While invoking $interval, we set up a callback function (the first argument) that gets invoked at specific intervals (the second argument) for a specific number of times (the third argument). In our case, we set up an anonymous function that decrements the currentExerciseDuration property after every one second (1000 ms) for the number of times defined in currentExercise.duration (configured to 30 in each exercise).

We have now used our first AngularJS service $interval. Additionally, as explained in the Dependency injection section, this service needs to be injected in the controller before we can use it. So let's do it by changing the controller definition to the following:

angular.module('7minWorkout')
  .controller('WorkoutController', ['$scope', '$interval', function ($scope, $interval) {

Well, injecting dependency was easy!

Time to check how things are looking! We are going to create a makeshift HTML view and test out our implementation.

The model tracking infrastructure of Angular is exposed over the $scope object. Till now, we have used the scope object just to manage our model properties and nothing else. But this scope object has much more to offer via the scope API functions. One of the functions it provides is $watch. This function allows us to register a listener that gets called when the scope property changes. The $watch method definition looks like this:

$scope.$watch(watchExpression, [listener], [objectEquality]);

The first parameter, watchExpression, can be either a string expression or a function. If the watchExpression value changes, the listener is invoked.

For a string expression, the expression is evaluated in the context of the current scope. This implies that the string expression that we provide should only contain properties/methods that are available on the current scope. If we pass a function as the first argument, AngularJS will call it at predefined times called digest cycles in the AngularJS world. We will learn about digest cycles in the following Lesson.

The second parameter listener takes a function. This function is invoked with three parameters namely newValue, oldValue, and the current scope. This is where we write logic to respond to the changes.

The third parameter is a Boolean argument objectEquality that determines how the inequality or change is detected. To start with, Angular not only allows us to watch primitive types such as strings, numeric, Boolean, and dates, but also objects. When objectEquality is false, strict comparison is done using the !== operator. For objects, this boils down to just reference matching.

However, when objectEquality is set to true, AngularJS uses an angular.equals framework function to compare the old and new values. The documentation for this method at https://docs.angularjs.org/api/ng/function/angular.equals provides details on how the equality is established.

To understand how objects are compared for inequality, it is best to look at some examples.

This gives a watch expression:

$scope.$watch('obj',function(n,o){console.log('Data changed!');});

These changes to $scope.obj will trigger the watch listener:

$scope.obj={};  // Logs 'Data changed!'
$scope.obj=obj1; // Logs 'Data changed!'
$scope.obj=null; // Logs 'Data changed!'

Whereas these will not:

$scope.obj.prop1=value; // Does not log 'Data changed!'
$scope.obj.prop2={}; // Does not log 'Data changed!'
$scope.obj=$scope.obj; // Does not log 'Data changed!'

In the preceding scenarios, the framework is not tracking internal object changes.

Instead, let's set the third parameter to true:

$scope.$watch('obj', function(n,o){console.log('Data changed!'},true);

All the previous changes will trigger the listener except the last one.

If we watch an object with objectEquality set to true then keep in mind that the framework does not tell which property in the object has changed. To do this, we need to manually compare the new object (n) and the old object (o).

Do these watches affect performance? Yes, a little. To perform comparison between the new and old values of a model property, Angular needs to track the last value of the model. This extra bookkeeping comes at a cost and each $watch instance that we add or is added by the framework does have a small impact on the overall performance. Add to that the fact that, if objectEquality is set to true, Angular has to now keep a copy of complete objects for the purpose of detecting model changes. This might not be a problem for standard pages, but for large pages containing a multitude of data-bound elements the performance can get affected. Therefore, minimize the use of object equality and keep the number of view bindings under control.

$watchCollection(expression, listener);

With this basic understanding of $watch in place, let's go ahead and add some controller logic.

In our Workout controller, we need to add a watch that tracks currentExerciseDuration. Add the following code to the WorkoutController function:

$scope.$watch('currentExerciseDuration', function (nVal) {
    if (nVal == $scope.currentExercise.duration) {
        var next = getNextExercise($scope.currentExercise);
        if (next) {
            startExercise(next);
        } else {
            console.log("Workout complete!")
        }
    }
});

We add a watch on currentExerciseDuration and whenever it approaches the total duration of the current exercise (if (nVal == $scope.currentExercise.duration)), we retrieve the next exercise by calling the getNextExercise function and then start that exercise. If the next exercise retrieved is null, then the workout is complete.

With this, we are ready to test our implementation. So, go ahead and refresh the index. Exercises should flip after every 10 or 30 seconds. Great!

But, as we decided earlier, we are not going to use the $watch approach. There is a slightly better way to transition to the next exercise where we do not require setting up any watch. We will be using the AngularJS Promise API to do it.

Browsers execute our JavaScript code on a single thread. This implies that we cannot have any blocking operation as it will freeze the browser and hence counts as a bad user experience. Due to this reason, a number of JavaScript API functions such as functions related to timing events (setTimeout and setInterval) and network operations (XMLHttpRequest) are asynchronous in nature. This asynchronous behavior requires us to use callbacks for every asynchronous call made. Most of us have used the ajax() API of jQuery and provided a function callback for a complete/success variable in the config object.

The problem with callbacks is that they can easily become unmanageable. To understand this, let's look at this example from the Q documentation:

step1(function (value1) {
    step2(value1, function(value2) {
        step3(value2, function(value3) {
            step4(value3, function(value4) {
                // Do something with value4
            });
        });
    });
});

With a promise library, callbacks such as the one just mentioned can be converted into:

Q.fcall(promisedStep1)
.then(promisedStep2)
.then(promisedStep3)
.then(promisedStep4)
.then(function (value4) {
    // Do something with value4
})
.catch(function (error) {
    // Handle any error from all above steps
})
.done();

The power of chaining instead of nesting allows us to keep code more organized.

Technically speaking, a promise is an object that provides a value or exception in the future for an operation that it wraps. The Promise API is used to wrap execution of an asynchronous method. A promise-based asynchronous function hence does not take callbacks but instead returns a promise object. This promise object gets resolved some time in the future when the data or error from the asynchronous operation is received.

To consume a promise, the promise API in AngularJS exposes three methods:

We will learn more about promises and how to implement our own promises in the coming Lessons. Nonetheless, for now we just need to consume a promise returned by an $interval service.

The $interval service that we used to decrement the time duration of exercises (currentExerciseDuration) itself returns a promise as shown:

$interval(function () {
        $scope.currentExerciseDuration = $scope.currentExerciseDuration + 1;
    }, 1000, $scope.currentExercise.duration);

This promise is resolved after the $interval service invokes the callback method (the first argument) for $scope.currentExercise.duration (the third argument) and in our case, 30 times is the value for a normal exercise. Therefore, we can use the then method of the Promise API to invoke our exercise transition logic in the promise success callback parameter. Here is the updated startExercise method with promise implementation highlighted:

var startExercise = function (exercisePlan) {
     $scope.currentExercise = exercisePlan;
     $scope.currentExerciseDuration = 0;
     $interval(function () {
         ++$scope.currentExerciseDuration;
     }, 1000, $scope.currentExercise.duration)
     .then(function () {
         var next = getNextExercise(exercisePlan);
         if (next) {
             startExercise(next);
         } else {
             console.log("Workout complete!")
         }
     });
 };

The code inside the then callback function is the same code that we added when using the $watch-based approach in the last section. Comment the existing $watch code and run the app again. We should get the same results. We did it without setting up any watch for the exercise transition.

If everything is set up correctly, our view should transition between exercises during the workout. Let's concentrate our efforts on the view.

To use the SPA capabilities of the framework, the view HTML needs to be augmented with some new constructs. Let's alter the index.html file and make it ready for use as a SPA view template. Add this piece of HTML inside the <body> tag, after the navbar declaration:

<div class="container body-content app-container">
        <div ng-view></div>
</div>

In the preceding HTML, we are setting up a nested div structure. The inner div has a new directive declaration, ng-view. The immediate question is, what does this directive do?

Well, HTML elements with this ng-view directive act as a container that hosts partial HTML templates received from the server. In our case, the content of the start, workout, and finish pages will be added as inner HTML to this div. This will happen when we navigate across these three pages.

For the framework to know which template to load at what time (inside the ng-view div element), it works with an Angular service named $route. This $route service is responsible for providing routing and deep-linking capabilities in AngularJS.

However, before we can use the $route service, we need to configure it. Let's try to configure the service to make things clearer.

The standard Angular $route service is not part of the core Angular module but defined in another module ngRoute. Hence, we need to import it in a similar manner to the way we imported the 7minWorkout module. So go ahead and update the app.js file with the ngRoute module dependency.

angular.module('app', ['ngRoute', '7minWorkout']);

We will also need to reference the module's JavaScript file as it is not part of the standard framework file angular.js. Add reference to the angular-route.js file after the reference to angular.js in index.html.

<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.3.3/angular.js"></script>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.3.3/angular-route.js"></script>

The last part to configure is the actual routes. We need to configure the routes for each of the three pages. Once configured, the routing service will match routes and provide enough information to the ng-view directive to help it render the correct partial view.

In the AngularJS world, any configurations required before the app becomes usable are defined using the module API's config method. Components defined in any module can use this method's callback to do some type of initialization.

Load the app.js file and update the module declaration code for the app module to:

angular.module('app', ['ngRoute', '7minWorkout']).
config(function ($routeProvider) {
    $routeProvider.when('/start', {
        templateUrl: 'partials/start.html'
    });
    $routeProvider.when('/workout', {
        templateUrl: 'partials/workout.html',
        controller: 'WorkoutController'
    });
    $routeProvider.when('/finish', {
        templateUrl: 'partials/finish.html'
    });
    $routeProvider.otherwise({
        redirectTo: '/start'
    });
});

Before we discuss the preceding code, let's understand a bit more about module initialization and the role of the config function in it.

AngularJS does not have a single entry point where it can wire up the complete application. Instead, once the DOM is ready and the framework is loaded, it looks for the ng-app directive and starts module initialization. This module initialization process not only loads the module declared by ng-app but also all its dependent modules and any dependencies that the linked modules have, like a chain. Every module goes through two stages as it becomes available for consumption. It starts with:

With this basic understanding of module initialization stages and the role of the config stage, let's get back to our route configuration code.

The config function just mentioned takes a callback function that gets called during the config stage. The function is called with the $routeProvider dependency. We define three main routes here and one fall back route using the $routeProvider API.

We call the when function of $routeProvider that takes two arguments:

The other method $routeProvider is otherwise used for a wildcard route match. If the route does not match any of the routes defined (/start, /workout, and /finish), then, by default, it redirects the user to the /start route in the browser; in other words, it loads the start page. We can verify this by providing routes such as http://<hostname>/index.html#/abc.

The following screenshot tries to highlight what role the index.html, ng-view, and $route services play:

Since we have defined three partial HTML files in the route, it's time to add them to the partial folder. Copy the start.html and finish.html files from the Lesson01/checkpoint4/app/partials and create a new file, workout.html.

Move all the code in the div fragment <div class="row"> from index.html into workout.html. Also remove the ng-controller declaration from the body tag. The body tag should now read as follows:

<body ng-app="app">

The ng-controller declaration from the body tag should be removed as we have already directed Angular to inject the WorkoutController controller function when navigating to the #/workout route during our route configuration (see the preceding $routeProvider config route).

Go ahead and refresh the index page. If you have followed our guidance, you will land on the page with the URL such as http://<hostname>/index.html#/start. This is our apps start page. Click on the Start button and you will navigate to the workout page (href='#/workout'); the workout will start. To check how the finish page looks, you need to change the URL in the browser. Change the fragment after # character to /finish.

As of now, when the workout finishes, transitioning to the finish page does not happen. We have not implemented this transition. The navigation from the start page to workout was embedded in a tag (href='#/workout'). Transition to the finish page will be done inside the controller.

If you thought we would use the $route service for navigation in our controller, you are a tad wrong. The $route service (https://docs.angularjs.org/api/ngRoute/service/$route) has no method to change the current route. Nonetheless, the $route service has a dependency on another service, $location. We will use the $location service to transition to the finish page.

Here is how the AngularJS documentation (https://docs.angularjs.org/api/ng/service/$location) describes $location service:

Open workout.js and replace the console.log("Workout complete!") line with this:

$location.path('/finish');

As always, we should add the dependency of the $location service to WorkoutController, as follows:

angular.module('7minWorkout')
  .controller('WorkoutController', ['$scope', '$interval', '$location', function ($scope, $interval, $location) {

Since we have started our discussion on the $location service, let's explore the capabilities of the $location service in more depth.

The $location service is responsible for providing client-side navigation for our app. If routes are configured for an app, the location service intercepts the browser address changes, hence stopping browser postbacks/refreshes.

If we examine the browser addresses for these routes, they contain an extra # character and the address appears in the following manner:

http://<hostname>/index.html#/start (or #/workout or #/finish)

The # character in the URL is something we may have used to bookmark sections within the page, but the $location service is using this bookmark-type URL to provide correct route information. This is called the hashbang mode of addressing.

We can get rid of # if we enable HTML5 mode configuration. This setting change has to be done at the config stage using the html5Mode method of the $locationProvider API. Let's call this method inside the module config function:

$locationProvider.html5Mode(true);

The addresses will now look like:

http://<hostname>/start (or /workout or /finish)

However, there is a caveat. It only works as long as we don't refresh the page and we do not type in the address of our browser directly. To have a true URL, rewrite as shown in the preceding code. We need to add support for it on the server side too. Remember when we are refreshing the page, we are reloading the Angular app from the start too so URLs mentioned previously will give 404 errors as Angular $location cannot intercept page refreshes.

The $location service also enables us to extract and manipulate parts of address fragments. The following diagram describes the various fragments of an address and how to reference and manipulate them.

We have already made use of the path function to navigate to the finish page. That is pretty much all we'll say about the $location service for now.

At the end we have converted our simple 7 Minute Workout into an SPA. Now we can see how easy it was to create an SPA using AngularJS. We get all the benefit of standard web apps: unique bookmarkable URLs for each view (page) and the ability to move back and forward using the browser's back and forward buttons but without those annoying page refreshes. If we show some patience after the last exercise completes, the finish page will indeed load.

The app looks a little better now, so let's continue to improve the app.

The ng-include directive, like the ng-view directive, allows us to embed HTML content, but unlike ng-view it is not tied to the current route of the app. Both ng-view and ng-include can load the template HTML from:

The ng-include directive is a perfect way to split a page into smaller, more manageable chunks of HTML content. By doing this, we can achieve some level of reusability as these chunks can be embedded across views or multiple times within a single view.

Now the question arises of whether we should embed the view as script blocks or load the partial views from a server. Loading partials from the server involves one extra call but, once Angular gets the partial template, it caches it for future use. Therefore, the performance hit is very small. Including templates inline can make the page more bloated, at least while designing the view.

In general, if the partial view is small, it is fine to include it in the parent view as a script block (the inline embedded approach). If the partial view code starts to grow, using a separate file makes more sense (the server view).

Note that, in both ng-include directives, we have used quoted string values ('partials/description-panel.html' and 'video-panel.html'). This is required as ng-include expects an expression and as always expressions are evaluated in the context of the current scope. To provide a constant value, we need to quote it.

The use of expressions to specify a path for ng-include makes it a very powerful directive. We can control which HTML fragments are loaded from the controller. We can define a property or function on the scope and bind that to the ng-include value. Now any change to the bound property will change the bound HTML template. For example, consider this include function:

<div ng-include='template'></div>

In the controller, we can do something like this:

if(someCondition) {
  $scope.template='view1'  // Loads view1 into the above div
}
else 
{
  $scope.template='view2'  // Loads view2 into the above div
}

The ng-include directive creates a new scope that inherits (prototypal inheritance) from its parent scope. This implies that the parent scope properties are visible to the child scope and hence the HTML templates can reference these properties seamlessly. We can verify this as we reference the scope properties defined in WorkoutController in the partials/description-panel.html and video-panel.html partials.

Another interesting directive that we have used in our video panel partials is ng-repeat. The job of the ng-repeat directive is to append a fragment of HTML repeatedly, based on elements in an array or the properties of an object.

The ng-repeat directive is a powerful and a frequently used directive. As the name suggests, it repeats! It duplicates an HTML fragment based on an array or object properties. We use it to generate YouTube video output in the right pane:

<div ng-repeat="video in currentExercise.details.related.videos">
  <iframe width="330" height="220" src="{{video}}" frameborder="0" allowfullscreen></iframe>
</div>

The ng-repeat directive looks a bit different from standard Angular expressions. It supports the following expression formats:

We can provide our own tracking expression for Angular using the tracking_expression argument. This expression can be a property on the collection object. For example, if we have a task collection returned from a server, we can use its ID property in the following way:

task in tasks track by task.id

With this change, Angular will use the id property of a task to track elements in the array. This also implies that the property must be unique or we will get the following error:

[ngRepeat:dupes] Duplicates in a repeater are not allowed. Use 'track by' expression to specify unique keys. Repeater: task in tasks track by task.id, Duplicate key: 1

Also see jsFiddle http://jsfiddle.net/cmyworld/n972k/ to understand how track is used in AngularJS.

The ng-repeat directive, like ng-include, also creates a new scope. However, unlike ng-include, it creates it every time it renders a new element. So, for an array of n items, n scopes will get created. Just like ng-include, scopes created by ng-repeat also inherit from the parent scope.

It will be interesting to see how many scopes are active on the workout page. Let's use the Batarang chrome plugin for this again. Navigate to the workout page (#/workout), open the Batarang plugin, and enable it. The scope hierarchy for the workout page should look something like this:

As we can see, ng-view, ng-include, and ng-repeat all create new scopes that inherit from the parent scope. If we wait a bit and let the exercise transition happen, we will see new scopes getting created and old ones getting destroyed (observe their IDs 002,004). This screenshot was taken during the first exercise (jumping jack). We can also look at the model properties attached to each scope in Batarang by clicking on the scope links (such as Scope (006)).

The previous screenshot also highlights what has caused the new scope to be created. Starting from $rootScope, which is the parent of all the scopes, a scope hierarchy has been created. In this scope hierarchy, the properties/functions defined on the parent scope are available to the child scope to consume. We can confirm this by looking at the two ng-include partials. These partials are referring to a property currentExercise that has been defined on the parent scope (004).

This feature is complete. Let's now add another capability to our app and learn about another great feature of AngularJS: filters.

The primary aim of an Angular filter is to format the value of an expression displayed to the user. Filters can be used across views, services, controllers, and directives. The framework comes with multiple predefined filters such as date, number, lowercase, uppercase, and others. This is how we use a filter in a view:

{{ expression | filterName : inputParam1 }}

An expression is followed by the pipe symbol |, which is followed by the filter name and then an optional parameter (inputParam1) separated by a colon (:). Here are some examples of the date filter. Given this date 7 August 2014, 10:30:50 in the current time zone:

$scope.myDate=new Date(2014,7,7,10,30,50);

<br>{{myDate}} <!--2014-08-07T05:00:50.000Z-->
<br>{{myDate | date}}  <!--Aug 7, 2014-->
<br>{{myDate | date : 'medium'}}  <!--Aug 7, 2014 10:30:50 AM-->
<br>{{myDate | date : 'short'}}  <!--8/7/14 10:30 AM-->
<br>{{myDate | date : 'd-M-yy EEEE'}} <!--7-8-14 Thursday-->

It is not very often that we use filters inside services, controllers, or directives but if we do need to do it, we have two options. Let's say we want to format the same date inside a controller:

The final result is the same.

Angular has a number of inbuilt filters that come in handy during view rendering. Some of the most used filters are:

Filters are an excellent mechanism for transforming the source model into different formats without changing the model data itself. Whenever we have a requirement to present data in a specific format, rather than changing the model data to suit the presentation needs we should use AngularJS filters to achieve this. The next sections provide a great example of this where we implement a filter that converts second into hh:mm:ss format.

Our filter secondsToTime will convert a numeric value into hh:mm:ss format. Open the filters.js file and add the following code to it:

angular.module('7minWorkout').filter('secondsToTime', function () {
    return function (input) {
        var sec = parseInt(input, 10);
        if (isNaN(sec)) return "00:00:00";

        var hours = Math.floor(sec / 3600);
        var minutes = Math.floor((sec - (hours * 3600)) / 60);
        var seconds = sec - (hours * 3600) - (minutes * 60);

        return ("0" + hours).substr(-2) + ':'
                + ("0" + minutes).substr(-2) + ':'
                + ("0" + seconds).substr(-2);    
}
});

We again use the Module API to first retrieve the 7minWorkout module. We then invoke the Module API method filter. The function takes two arguments: the name of the filter and a filter function. Our filter function does not take any dependency but we have the capability to add dependencies to this function. The function should return a factory function that is called by the framework with the input value. This function (function (input)) in turn should return the transformed value.

The implementation is quite straightforward as we convert seconds into hours, minutes, and seconds. Then we concatenate the result into a string value and return the value. The 0 addition on the left for each hour, minute, and seconds variable is to format the value with a leading 0 in case the calculated value for hours, minutes, or seconds is less than 10.

Before we use this filter in our view, we need to implement the workout time remaining logic in our controller. Let's do that. Open the workout.js file and update the WorkoutPlan constructor function by adding a new function totalWorkoutDuration:

function WorkoutPlan(args) {
  //existing WorkoutPlan constructor function code
  this.totalWorkoutDuration = function () {
    if (this.exercises.length == 0) return 0;
    var total = 0;
    angular.forEach(this.exercises, function (exercise) {
        total = total + exercise.duration;
    });
    return this.restBetweenExercise * (this.exercises.length - 1) + total;
} 

This method calculates the total time of the workout by adding up the time duration for each exercise plus the number of rest durations. We use a new AngularJS library function forEach to iterate over the workout exercise array. The angular.forEach library takes an array as the first argument and a function that gets invoked for every item in the array.

Now locate the startWorkout function and update it by adding these two sections:

var startWorkout = function () {
  workoutPlan = createWorkout();
  $scope.workoutTimeRemaining = workoutPlan.totalWorkoutDuration();

    // Existing code. Removed for clarity

    $interval(function () {
        $scope.workoutTimeRemaining = $scope.workoutTimeRemaining - 1;
    }, 1000, $scope.workoutTimeRemaining);

    startExercise(workoutPlan.exercises.shift());
};

We assign totalWorkoutDuration for the workout plan to $scope.workoutTimeRemaining and at the end of the method before calling startExercise, we add another $interval service to decrement this value after every second, for a total of workoutTimeRemaining times.

That was easy and quick. Now it's time to update the view. Go to workout.html and add the highlighted line in the following code:

<div class="workout-display-div">
  <h4>Workout Remaining - {{workoutTimeRemaining | secondsToTime}}</h4>
  <h1>{{currentExercise.details.title}}</h1>

Now, every time the expression workoutTimeRemaining changes, the filter will execute again and the view will get updated. Save the file and refresh the browser. We should see a countdown timer for the workout!

Wait a minute. The total workout duration shown is 7 minutes 50 seconds not 7 minutes. Well, that's not a problem with our calculation even though the total workout duration indeed is 7:50 minutes. Basically, this is a sub-8 minute workout so we call it 7 Minute Workout!

Before we conclude this Lesson, we are going to add one last enhancement that will add to the usability of the app. We will show the name of the next exercise during the rest periods.