Android Design Pattern Essentials

5 min readOct 23, 2020

Design Pattern — In simple terms this refers to the procedures by which developers can solve problems easily. These patterns were developed by software developers while working or solving a problem. In addition, these patterns were developed by following proper object-oriented concepts. It kind of gives you a proper solution for a common problem.

For example, you have your database connector class which performs all your database operations, so you want to have only a single instance of this class at once. So to do this you can use the SingleTon design pattern which ensures that your class will have only a single instance at once.

You will find a lot of resources about design patterns but what I have tried to write here is to provide you a starting point with some of the commonly used design patterns in android with basic examples. If you want to learn more about these design patterns I will attach some resources at the end of this article.

So keep reading!

Types of Design patterns in android

There are three types of design patterns. They are,

1. Creational Patterns — how you create objects. Examples are (Builder, Dependency injection, Singleton)

2. Structural patterns — how you compose objects. Examples are (Adapter, Facade)

3. Behavioral Patterns — how you coordinate object interactions. It lets you assign responsibility for different app functions. Examples are (Command, Observer, Model View Controller, Model View ViewModel, Clean Architecture)

Now let’s dive into some details portion about different kinds of design patterns.

Builder Design Pattern

Let’s start with an example: At a sandwich spot down my block, I use a small pencil to check off the bread, ingredients, and condiments I’d like on my sandwich from a checklist on a slip of paper. Even though the checklist’s title instructs me to “build my own” sandwich, I really only fill out the form and hand it over the counter. I’m not actually doing the sandwich-building, just the customizing…and the consuming.

Similarly, the Builder pattern separates the construction of a complex object (the slicing of bread, the stacking of pickles) from its representation (a yummy sandwich); in this way, the same construction process can create different representations.

As an example,

This builder proceeds step-by-step and lets you specify only the parts of your AlertDialog that matter to you.

AlertDialog.Builder(this)
  .setTitle("Metaphorical Sandwich Dialog")
  .setMessage("Metaphorical message to please use the spicy mustard.")
  .setNegativeButton("No thanks", { dialogInterface, i ->
    // "No thanks" button was clicked
  })
  .setPositiveButton("OK", { dialogInterface, i ->
    // "OK" button was clicked
  })
  .show()

Dependency Injection

Dependency injection is like moving into a furnished apartment. Everything you need is already there; you don’t have to wait for furniture delivery or rent goods from online rental services.

In strictly software terms, dependency injection has you provide any objects required when you instantiate a new object; the new object doesn’t need to construct or customize the objects itself.

Singleton

Singleton design pattern ensures that at a time only a single instance will be available. Such as database instance, we can make the instance of database Singleton to make things much simpler.

This was just a simple example of how a singleton design pattern works.

Adapter Design Pattern

This pattern lets two incompatible classes work together by converting the interface of a class into another interface the client expects.

The name Adapter defines actually what it is. It works as an intermediatory between two separate entity. For example, you want to charge your phone. The first thing you need is a power source and the second thing in the medium by which you can exchange power into your phone. And for charging your phone the charger is the medium.

Facade Design Pattern

The Facade pattern provides a higher-level interface that makes a set of other interfaces easier to use. The following diagram illustrates this idea in more detail:

Retrofit from Square is an open-source Android library that helps you implement the Facade pattern; you create an interface to provide API data to client classes like so:

The client simply needs to call listBooks () to receive a list of Book objects in the callback. It’s nice and clean.

Command Design pattern

When you order some Pizza in a restaurant, you don’t necessarily know which cook will prepare your pizza; you only give your order to the waiter, who posts the order in the kitchen for the next available cook.

Similarly, the Command pattern lets you issue requests without knowing the receiver. You encapsulate a request as an object and send it off; deciding how to complete the request is an entirely separate mechanism.

Observer Design Pattern

The Observer pattern defines a one-to-many dependency between objects. When one object changes state, all of its dependents are notified and updated automatically.

This is a versatile pattern; you can use it for operations of indeterminate time, such as API calls. You can also use it to respond to user input.

The RxAndroid framework (aka Reactive Android) will let you implement this pattern throughout your app:

In short, you define Observable objects that will emit values. These values can emit all at once, as a continuous stream, or at any rate and duration.

Model View Controller

Basically most of us familiar with the term MVC and MVVM. This design pattern lets us make our code more decoupled and reusable. And by decoupled we meant that there should be the maximum level of independence between each module.

Model: your data classes. If you have User or Product objects, these “model” the real world.

View: your visual classes. Everything the user sees falls under this category.

Controller: the glue or intermediator between the two. It updates the view, takes user input, and makes changes to the model.

Model View ViewModel

This is kind of similar to the MVC pattern. The Model and View components are the same. The ViewModel object is the “glue” or “intermediator” between the model and view layers but operates differently than the Controller component.

When the model updates, the corresponding views update as well via the data binding. Similarly, as the user interacts with the view, the bindings work in the opposite direction to automatically update the model. This reactive pattern removes a lot of glue code.

So this was just a simple illustration of these design patterns, you can read about them more and implement them to solve your problems. The following are some of the references which will help you to learn in-depth about these design patterns.

Resources for in-depth analysis:

Thanks for reading and claps will be amazing.