Image for post
Image for post

Service Locator pattern in Android

Daniel Novak
Jan 31, 2018 · 3 min read

Dependency injection is all the rage now on Android but there are also some other patterns worth considering for managing dependencies. A Service Locator is a very simple pattern which can be implemented in few lines (50?) of code and can sometimes be a viable alternative or complement to DI frameworks like Dagger 2.

The Service Locator is considered by some (or many) as an anti-pattern, but I would argue that you always have to choose the right tool for the job (and it’s good to have a variety of tools in your toolbox). In some cases the Service Locator can be an extremely simple and efficient solution. It can also get handy in case you have constraints like APK size, method count, build speed or overall complexity.

If you would like to learn more then there is a famous article about the Service Locator and Dependency Injection and their differences and use cases from Martin Fowler and I highly recommend it. Also there is an article from Guy Murphy that sheds a different (more positive) light on the service locator anti-pattern debate.

How does Service Locator help you?

  • It allows you to switch different implementations of one interface at runtime (good for testing or switching implementation based on device)
  • * On Android, it can also “inject” the ApplicationContext to your class

In a way it’s like using Dagger where all your components are ApplicationScope. It has no notion of Scopes, every instance is application wide. A Service Locator is especially good for stateless and/or classes that are able to store their state and survive process death on Android. This can be your RestService, DBService…

Usage

Within the code we should be able to get the current implementation by simply calling SL.get(IRestService.class), prompting the locator to lazily create an instance of this class based on the current configuration (real or mock), return it in the call and store it for further retrieval.

A simple example how the basic usage of SL looks like.

The configuration

A simple Android implementation

I have added one small “twist” to the basic Service Locator implementation. On Android often times you need to access the Application Context and we can inject this into your constructor. For this implementation we only allow classes with empty or single Context parameter constructors.

The interface (e.g. IRestService) needs to extend the empty IService interface. This has no functional impact but it’s easier to quickly find interfaces / classes that are meant to be used with the Service Locator.

You need to call SL.init(this) to set the Application Context. This Context instance will then be delivered through your constructor (only in case your constructor takes a Context).

Use with caution

Example implementation: https://gist.github.com/DanielNovak/06bc27fa4ecea63207c424bef88199df

INLOOPX

People at INLOOPX writing about anything.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store