What is Dependency Injection?

In simple terms, DI is a design pattern that enables a class to receive dependencies from an external source rather than creating them itself.

Imagine a scenario where you’re constructing a house. You could either create every item (bricks, cement, windows, doors, etc.) yourself or get them delivered from various suppliers. The latter approach is similar to DI: it’s all about getting ‘dependencies’ (i.e., services or objects) ‘injected’ into a class.

class House {
  constructor() {
    this.brick = new Brick();
    this.cement = new Cement();
  }
}

In the code snippet above, House creates its own dependencies. Here are some reasons why this is problematic:

1. Testing difficulty: In this approach, when you want to test the House class, you are forced to also test with Brick and Cement objects. You can't replace these dependencies with mock objects for testing, because the House class is directly instantiated with new Brick and Cement instances.

2. Less flexibility: The House class is rigidly configured to use Brick and Cement. What if later you want to construct a House with Stone and Clay instead? You'd need to modify the House class itself, which isn't ideal, especially if the House class is used widely in your application.

3. Code reusability: By creating dependencies within the class, it becomes hard to reuse them across different classes or modules. For instance, if you need to use the same Brick and Cement instances in another class, you cannot do so without creating new instances.

Now, let’s see how Dependency Injection could change this.

Why Dependency Injection?

In the code snippet below, House is no longer responsible for creating Brick or Cement. It simply declares what it needs, and it's up to the system (in Angular's case, the injector) to provide those dependencies. This makes your code much easier to manage and evolve over time.

class House {
  constructor(brick: Brick, cement: Cement) {
    this.brick = brick;
    this.cement = cement;
  }
}

Dependency Injection helps to solve the problems identified above. Let’s discuss how DI addresses each of those problems.

1. Testing made easier: With DI, testing becomes easier because you can inject mock versions of your dependencies during testing. For instance, if Brick and Cement services make HTTP requests to a server, and you want to isolate House from these server requests during testing, you can provide mock versions of Brick and Cement that do not make actual HTTP requests.

2. Flexibility: DI provides flexibility to your classes. If the House class needs to use Stone and Clay instead of Brick and Cement, you can simply change the services you inject without needing to change the House class itself. This way, House is less concerned about the specific implementation of the dependencies it uses and more focused on how it uses them. This is also known as the Dependency Inversion Principle: depend on abstractions, not on concrete classes.

3. Code reusability: DI promotes code reusability. Once Brick and Cement services are created, they can be injected wherever required, avoiding the need to create new instances every time. This makes your code cleaner and more efficient.

Dependency Injection in Angular

Now that we understand the basics of DI let’s see how it works in Angular. Angular’s DI framework provides dependencies to a class upon instantiation. These dependencies are typically services that provide functionality such as fetching data from a server or logging user interactions.

To start with, let’s define a simple service called LogService that logs messages to the console.

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class LogService {
  log(message: string) {
    console.log(`LogService: ${message}`);
  }
}

Next, let’s inject this service into a component called AppComponent.

import { Component } from '@angular/core';
import { LogService } from './log.service';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css'],
})
export class AppComponent {
  title = 'Hello Angular!';

  constructor(private logService: LogService) {
    this.logService.log(this.title);
  }
}

In the code above, the Angular DI system injects an instance of LogService into AppComponent via its constructor. We can then use this service to log a message to the console.

The @Injectable Decorator

You might have noticed the @Injectable decorator on LogService. This decorator tells Angular that this service might itself have dependencies. Even though our LogService doesn't have any dependencies at the moment, it's good practice to add @Injectable in preparation for future needs.

Providers and Injector

Two key concepts in Angular DI are providers and injectors. These two concepts are integral to Angular’s Dependency Injection (DI) system, but they can sometimes be a bit tricky to understand. To make it easier, think of the injector as a bakery and the provider as the recipe for creating a service.

Providers: Your Service’s Recipe

A provider is like a recipe for creating an instance of a service. It tells the injector how to create or obtain that service. It’s typically the service class itself. Let’s consider an example where we have a service called UserService. This service might look like this:

@Injectable({
  providedIn: 'root',
})
export class UserService {
  getUsers() {
    return ['John', 'Jane', 'Bob'];
  }
}

Here, UserService is a provider because it's the recipe for creating an instance of the UserService. The @Injectable decorator tells Angular that this class can be used as a provider.

Where Do We Define Providers?

We usually define providers in Angular modules or components using the providers property. When you define providers, Angular creates an injector with all those providers. When a class needs a service, the injector checks its container of instances to see if it already has one to reuse. If not, the injector makes a new one using the provider.

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css'],
  providers: [UserService] // UserService is the provider
})
export class AppComponent { ... }

In our UserService example above, we actually used a shortcut with providedIn: 'root'. This automatically provides the UserService in the root injector, which is like the main bakery for the whole app. This means that UserService will be available anywhere in our app.

Injectors: The Bakery

An injector is a mechanism that is responsible for creating instances of services and injecting them into classes like components, other services, etc. Think of the injector as a bakery. If you ask it for a cake (UserService in our example), it will look to see if it has a cake already made. If it does, it gives you that cake. If it doesn't, it uses the recipe (provider) to make a new cake and then gives you the cake.

Here’s an example of how an injector might be asked for a service:

import { Component } from '@angular/core';
import { UserService } from './user.service';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css'],
})
export class AppComponent {
  users: string[];

  constructor(private userService: UserService) {
    this.users = userService.getUsers();
    console.log(this.users);
  }
}

In this example, AppComponent asks the injector for UserService. The injector then checks if it has an instance of UserService to give. If it does, it will provide that instance. If it doesn't, it will use the UserService provider (recipe) to create a new instance and then give that to AppComponent.

The injector in Angular is not explicitly defined by developers in the code. Rather, it’s implicitly created and managed by the Angular framework itself. Angular creates a root injector for the application when it bootstraps the application, using the providers defined in the root module (AppModule by convention).

In Angular, an injector is created for every Angular module and component. So when you define a module or a component, Angular implicitly creates an injector for it.

If you provide a service at the component level, Angular will create a new instance of the injector for that component and its child components. This instance will be different from the one associated with the root or any other module. This allows Angular to have a hierarchical injector system, which means you can override service instances and control the scope of services.

To recap, providers and injectors work together to make Angular’s Dependency Injection system work. Providers are like recipes that tell the injector how to create or find an instance of a service. The injector is like a bakery that takes in these recipes and uses them to create and provide these instances. This whole process allows us to write modular, reusable, and testable code in our Angular applications.

Further Reading

https://angular.io/guide/dependency-injection

As a programmer, you will work with different types of data, and most of the time, you will need to work with collections of data.

So what are collections?

If you're familiar with programming then you understand the concept of data types such as boolean, int, string, etc.

Now suppose you are working on a library application that displays and manages books. In this case, you have to use a group of objects (books) of the same type. In common terms, this is a collection because you can collect those objects and add or remove them when needed.

Collections, therefore, contain many objects of the same type.

Collection types in kotlin

Kotlin supports the use of the following types:

1. List
2. Sets
3. Map or Dictionary

You might ask why do you need different types of collections if I will be storing objects of the same type?

So let's explore each of these and understand how different they are from each other.

Lists in kotlin

Lists have the following properties:

• They are ordered - This means that the order of items in the list matters.

• They are dynamic- This refers to memory, meaning that the size is not fixed. You can add as many items as you need.

• They can be immutable or mutable - Mutable lists allow you to add, remove, and insert elements while immutable lists do not allow you to add or remove elements.

• They can be duplicates- Which means you can have duplicate values or items in the list. For example, you can have two books with the same name in a list of books.

Creating a list

fun main() {
  val list = listOf(2, 3, 5, 6, 7)
  println(list)
}

The above list contains an immutable list of integer numbers. You cannot insert or remove an element from the above list.

To do that, you need to create a mutable list ie.

fun main() {
  val list = mutablelistOf(2, 3, 5, 6, 7)
  println(list)
}

Now you can perform operations such as:

  list[2] = 100  // change the element at index 2 to 100
  println(list[2]) // 100
  list.add(index = 3, element = 500) // add an element at index 3
  println(list[3]) // 500
  list.remove(7) // remove element 7
  println(list) // [2, 3, 100, 500, 6]
  list.removeAt(0) // remove the element at index 0 ie element 2
  println(list) // [3, 100, 500, 6]

Sets in kotlin

A set is a collection of elements where each of the elements is unique and there are no duplicates. Properties:

• They are unordered- order does not matter
• They are unique - No duplicates
• They can be either mutable or immutable

Creating sets

To create immutable sets:

fun main() {
  val numbers = setOf(2, 3, 5, 6, 7)
  println(numbers) 
}

To create mutable sets:

fun main() {
  val numbers = mutableSetOf(2, 3, 5, 6, 7)
  println(numbers)
}

Sets use an object’s hashCode() internally to filter out duplicates. If the set is mutable and you try to add another element to it, the new object will replace the old one. You can override hashCode() and manually determine how to differentiate the elements.

Sets are a bit different than lists when it comes to accessing data. You wouldn’t look up items in a set using indices since the index of an item is actually its hash code. If you know the hash code, then you should already have the value.

Maps in kotlin

A Map stores key-value pairs (or entries ); keys are unique, but different keys can be paired with equal values. And like other collections, maps can be both mutable and immutable.

Creating a map

We initialize all the collections the same way. So, just like the other collections, you can create mutable or immutable maps:

Immutable map

fun main() {
  val peopleAges = mapOf(
      "Fred" to "23",
      "Ann" to "9",
      "Grace" to "40")
}

Mutable map

fun main() {
  val peopleAges = mutableMapOf(
      "Fred" to "23",
      "Ann" to "9",
      "Grace" to "40")
}

With mutable maps, you can add or remove items using the keys and the method put().

Add items

peopleAges.put("Nick", 22) //This adds another key-value element

Change items

peopleAges["Fred"]=24  //This changes the value of Fred's age from 23 to 24

Iterating through maps is a bit different from the rest of the Kotlin collections. Since maps have two objects for each element, you have to iterate over pairs, instead of single values. You can do this in the following way:

peopleAges.forEach { key, value -> println("Value for key $key is $value") }

You iterate through the pairs. In each iteration, you receive both the key and the value for that key, since it’s often necessary to know and consume both the key and the value.

Conclusion

Collections are very crucial in programming. This tutorial has introduced you to the most common collections in kotlin. To read more about kotlin collections and the various methods associated with each collection type, check out the Kotlin documentation.

This post lists a few tutorials and courses that I have found to be valuable for anyone starting out with kotlin android development.

1. Android basics in Kotlin- Google

This is the best course for a complete beginner in android and kotlin. The course assumes no prior knowledge in either android and kotlin.

Google Android Basics in Kotlin

2. Developing Android Apps with Kotlin - Udacity

The course is well organized to teach you the basics of android development using kotlin.

Developing Android Apps with Kotlin

3. Build A Simple Android App With Kotlin - Youtube tutorial

This is a youtube tutorial by Philip Lackner on the Traversy Media youtube channel. In this tutorial, you will learn the basics of kotlin android development by building a todo list app.

Build A Simple Android App With Kotlin

4. Kotlin Course - Tutorial for Beginners by freeCodeCamp

This is a kotlin crash course for anyone looking to learn the Kotlin programing language which is the official language for android development.

Kotlin Course - Tutorial for Beginners

5. Android Development Course - Build Native Apps with Kotlin Tutorial

Learn to build native Android apps with Kotlin. You will also learn how to use Android Jetpack, Firebase, Room, MVVM, Navigation, LiveData, and Kotlin Coroutines. This full course explains how to build an entire Android app using best practices.

Android Development Course - Build Native Apps with Kotlin Tutorial