DEV Community: Thanh Tam

Singleton in Android

Thanh Tam — Fri, 06 Jan 2023 01:55:29 +0000

The Singleton design pattern is a software design pattern that ensures that a class has only one instance, and provides a global point of access to that instance. This can be useful in Android development when you need to share data or state across multiple activities or fragments.

There are several ways to implement the Singleton pattern in Android, each with its own set of pros and cons. Here, we'll take a look at three common approaches:

Lazy initialization: This is the most straightforward way to implement the Singleton pattern. The instance is created only when it is needed, and it is stored as a static field. This approach is simple, but it is not thread-safe and can cause performance issues if the instance is expensive to create.
Eager initialization: In this approach, the instance is created as a static field when the class is first loaded. This ensures that the instance is always available, but it can waste resources if the instance is not actually needed.
Double-checked locking: This approach uses a combination of lazy initialization and synchronization to create the instance in a thread-safe way. It is more complex than the other two approaches, but it provides the best performance in cases where the instance is expensive to create.

Which approach is best for your project will depend on your specific needs. Lazy initialization is a good choice if the instance is inexpensive to create, while double-checked locking is a better choice if the instance is expensive to create. Eager initialization is a good choice if the instance must be available immediately, but it can waste resources if the instance is not actually needed.

In summary, the Singleton design pattern is a useful tool for managing global state and shared data in Android development. By carefully considering the trade-offs between different implementation approaches, you can choose the one that is best suited to your project's needs.

SOLID in Android

Thanh Tam — Thu, 05 Jan 2023 01:49:58 +0000

SOLID is a set of five principles that can help developers write more maintainable and scalable software. The acronym stands for:

Single Responsibility Principle (SRP)
Open-Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)
In this blog post, we'll go through each of these principles and discuss how they can be applied to Android development.

Single Responsibility Principle (SRP)

The Single Responsibility Principle (SRP) states that a class should have only one reason to change. In other words, a class should have a single, well-defined responsibility.

One way to apply this principle in Android development is to create classes that are specific to a particular feature or task. For example, you might have a class that is responsible for handling network requests, a class that is responsible for rendering a list of items on the screen, and a class that is responsible for storing data in a database.

By creating classes that have a single responsibility, you can make your code more maintainable and easier to understand. When you need to change something, you know exactly where to look and you don't have to wade through a lot of unrelated code to find what you're looking for.

Open-Closed Principle (OCP)

The Open-Closed Principle (OCP) states that software entities (such as classes, modules, and functions) should be open for extension but closed for modification.

This means that you should design your classes in such a way that they can be extended to add new functionality without changing the existing code.

One way to apply this principle in Android development is to use inheritance and polymorphism. For example, you might create a base class that defines a set of common methods and properties, and then create derived classes that override or extend those methods as needed. This allows you to add new functionality without modifying the base class.

Another way to apply the OCP is to use interfaces. By defining an interface and then implementing it in your classes, you can add new functionality without changing the existing code.

Liskov Substitution Principle (LSP)

The Liskov Substitution Principle (LSP) states that objects of a subclass should be able to be used in the same way as objects of the base class.

In other words, if a class is derived from another class, it should be able to be used in the same way as the base class without causing any problems.

To apply this principle in Android development, you should ensure that your derived classes correctly implement the methods and properties of the base class. This means that the derived class should be a "strict superset" of the base class, meaning that it should have all of the same methods and properties, and possibly more.

Interface Segregation Principle (ISP)

The Interface Segregation Principle (ISP) states that clients should not be forced to depend on interfaces they do not use.

In other words, you should not create interfaces with a lot of methods that are not relevant to all of the classes that implement them. This can lead to "fat" interfaces that are difficult to implement and maintain.

To apply this principle in Android development, you should create smaller, more focused interfaces that only contain the methods that are relevant to a specific group of classes. This will make it easier for those classes to implement the interface and will also make your code

What is Dependency Injection

Thanh Tam — Wed, 04 Jan 2023 10:50:20 +0000

Dependency injection is a software design pattern that allows a system to be more flexible and modular by decoupling the implementation of objects from the objects that use them. It does this by allowing the objects that use other objects (called clients) to specify which objects they will use (called dependencies) at runtime, rather than having the clients create the dependencies themselves.

The key benefit of dependency injection is that it enables clients to specify their dependencies at runtime rather than hardcoding them. This makes it easier to change the implementation of a dependency without affecting the client, as well as making it easier to test the client in isolation.

There are several ways to implement dependency injection, including constructor injection, setter injection, and interface injection. In constructor injection, the dependencies are provided to the client via the constructor when the client is created. In setter injection, the dependencies are set on the client using setter methods. In interface injection, the dependencies are passed to the client through an interface implemented by the client.

Here's an example of constructor injection in Kotlin:

interface FileSystem {
    fun readFile(path: String): String
}

class RealFileSystem: FileSystem {
    override fun readFile(path: String): String {
        // implementation to read a file from the real file system goes here
    }
}

class MyClass(private val fileSystem: FileSystem) {
    fun doSomething() {
        val fileContents = fileSystem.readFile("/path/to/file.txt")
        // use the file contents to do something
    }
}

val fileSystem = RealFileSystem()
val myClass = MyClass(fileSystem)
myClass.doSomething()

In this example, MyClass has a dependency on FileSystem, which it needs to read a file. The FileSystem dependency is injected into MyClass via the constructor when MyClass is created. This allows MyClass to use any implementation of FileSystem without knowing how it is implemented.

It's also possible to use setter injection in Kotlin like this:

interface FileSystem {
    fun readFile(path: String): String
}

class RealFileSystem: FileSystem {
    override fun readFile(path: String): String {
        // implementation to read a file from the real file system goes here
    }
}

class MyClass {
    private lateinit var fileSystem: FileSystem

    fun setFileSystem(fileSystem: FileSystem) {
        this.fileSystem = fileSystem
    }

    fun doSomething() {
        val fileContents = fileSystem.readFile("/path/to/file.txt")
        // use the file contents to do something
    }
}

val fileSystem = RealFileSystem()
val myClass = MyClass()
myClass.setFileSystem(fileSystem)
myClass.doSomething()

Here, the fileSystem dependency is set on MyClass using the setFileSystem setter method.

Overall, dependency injection is a useful pattern for achieving loose coupling between objects, which can make a system more flexible and easier to maintain.