Dependency Injection Flutter Using GetIt Injectable

Understanding Dependency Injection in Flutter

Before diving into GetIt's implementation, understanding why dependency injection matters provides essential context for making architectural decisions. A dependency is any object or service that another object requires to function--when your home screen needs to display user data, it depends on an authentication service and a user repository.

Without a systematic approach to providing these dependencies, you face two problematic alternatives: creating them internally (which creates tight coupling and makes testing difficult) or passing them through constructors (which creates verbose widget trees and requires threading dependencies through multiple layers).

Why Manual Dependency Management Fails

Consider a typical Flutter application without dependency injection. Your widget might create an API service directly, which in turn creates an HTTP client and authentication handler. When you need to test this widget, you cannot easily substitute mock services because the dependencies are hard-coded within the widget itself.

When your authentication approach changes, you must update every widget that creates authentication-related objects. When you discover a memory leak in your HTTP client, tracking down every instantiation becomes a debugging odyssey.

The Service Locator Pattern

GetIt implements the service locator pattern, which serves as a centralized registry for dependencies. Rather than creating dependencies directly or passing them through every constructor, components request their dependencies from this global registry. The service locator ensures that each request returns the appropriate instance--whether that instance should be a shared singleton, a newly created object, or a lazily initialized service.

Unlike traditional dependency injection frameworks that rely on constructor injection or property injection, GetIt provides dependencies through a central registry that components access directly. This distinction matters because dependencies become implicit rather than declared in interfaces. When you refactor a class, you might not immediately see all the places that depend on it since the dependencies are resolved at runtime through the locator rather than at compile time through constructor signatures. However, this approach significantly reduces boilerplate--you do not need to thread dependencies through multiple layers of widget constructors, and adding a new dependency does not require modifying every class in your call chain. For Flutter developers coming from Android or iOS backgrounds where constructor injection is the norm, this represents a meaningful shift in how you think about component relationships and dependency flow. Our web development services help teams implement clean architecture patterns that scale efficiently.

Getting Started with GetIt in Your Flutter Project

Installing GetIt requires adding a single dependency to your pubspec.yaml file. The package has achieved stable status and sees active maintenance, making it suitable for production applications. Once installed, you create a global GetIt instance that serves as your service locator throughout the application.

Basic Setup and Configuration

The foundation of any GetIt implementation involves creating the service locator instance and defining a setup function that registers your application's dependencies. This setup function runs early in your application's lifecycle, typically before calling runApp(), ensuring that all services are available when widgets begin building.

Your First Service Registration

Registering a service with GetIt involves choosing an appropriate registration method based on how you want that service to be managed. For most shared services--your API clients, repositories, and authentication handlers--registerLazySingleton provides optimal behavior: the service is created only when first requested, then reused for all subsequent requests.

The following code demonstrates a complete GetIt setup for your Flutter application:

// lib/service_locator.dart
import 'package:get_it/get_it.dart';

final getIt = GetIt.I;

// lib/setup_locator.dart
import 'service_locator.dart';

void setupLocator() {
 // Register API service as lazy singleton
 getIt.registerLazySingleton<ApiService>(() => ApiService());
 
 // Register repository as lazy singleton
 getIt.registerLazySingleton<UserRepository>(() => UserRepositoryImpl(getIt()));
 
 // Register authentication service
 getIt.registerLazySingleton<AuthService>(() => AuthService(getIt()));
}

// lib/main.dart
import 'setup_locator.dart';

void main() {
 setupLocator();
 runApp(const MyApp());
}

In this setup, the getIt instance serves as your global service locator. The setupLocator() function runs once at application startup, registering all your services with their appropriate lifecycle management. When you call getIt<ApiService>(), GetIt creates the ApiService instance (if it does not already exist) and returns it for use in your widgets and services.

Integrating Injectable for Automated Registration

While manual registration works well for smaller applications, Injectable extends GetIt with code generation that eliminates boilerplate registration code. By annotating your service classes with @injectable, you allow Injectable's build_runner to generate the registration code automatically, keeping your service locator configuration synchronized with your actual service implementations.

Setting Up Injectable

Configuring Injectable requires adding both the injectable and injectablegenerator packages to your dev dependencies, then creating a service locator setup file that calls init() to process generated code. The generation step runs as part of your normal development workflow, typically triggered by a command that rebuilds the generated registration file whenever your service classes change.

Add these dependencies to your pubspec.yaml:

dev_dependencies:
 injectable:
 injectable_generator:
 build_runner:

Create your service locator configuration file:

// lib/injection.dart
import 'package:get_it/get_it.dart';
import 'package:injectable/injectable.dart';

final getIt = GetIt.I;

@InjectableInit()
void configureInjection(String env) {
 $initGetIt(getIt, environment: env);
}

Annotate your services with @injectable:

import 'package:injectable/annotations.dart';

@injectable
class ApiService {
 final Dio dio;
 
 @injectable
 ApiService(this.dio);
}

@injectable
class UserRepositoryImpl implements UserRepository {
 final ApiService apiService;
 
 @injectable
 UserRepositoryImpl(this.apiService);
}

Generate the registration code by running:

flutter pub run build_runner build --delete-conflicting-outputs

Configuring Generation for Different Environments

Injectable supports environment-specific registrations through @Environment annotations, allowing you to register different implementations for development, staging, and production builds. Your development environment might use a mock API service, while production uses the real implementation--Injectable generates appropriate registrations based on the environment you specify when building or running your application.

@Environment('dev')
@injectable
class MockApiService implements ApiService {
 // Mock implementation for development
}

@Environment('prod')
@injectable
class RealApiService implements ApiService {
 // Production implementation
}

Initialize with your target environment:

void main() {
 configureInjection(Environment.dev); // or Environment.prod
 runApp(const MyApp());
}

Automating dependency registration through code generation aligns with modern AI automation practices that reduce manual configuration and minimize human error in complex software systems.

Best Practices for Flutter Dependency Injection

Effective dependency injection requires discipline beyond simply registering services. The following practices help maintain clean architecture while leveraging GetIt's capabilities fully.

Registering Shared Dependencies Only

Resist the temptation to register every class in your application. GetIt works best as a registry for truly shared dependencies--services, repositories, and configuration objects that multiple parts of your application need. Widget-specific state, temporary view models, and one-off utilities do not belong in the service locator and should remain local to their respective widgets or screens.

Choosing the Right Registration Method

Match your registration method to your service's lifecycle requirements. Shared services with no internal state benefit from registerLazySingleton. Services that must initialize before the application starts use registerSingleton. Widget-specific state managers and other transient objects should use registerFactory to ensure isolation.

Cleanup and Disposal

Services that hold resources--database connections, stream subscriptions, file handles--should implement a disposal mechanism. GetIt allows asynchronous disposal through the dispose parameter, where you provide a function that releases resources when your application shuts down or when you explicitly reset the service locator during testing.

getIt.registerLazySingleton<DatabaseService>(
 () => DatabaseService(),
 dispose: (instance) => instance.close(),
);

Testing with Dependency Injection

One of dependency injection's primary benefits is improved testability. By accessing services through GetIt rather than creating them internally, you can substitute mock services during testing without modifying your production code. The GetIt.reset() function clears all registrations between tests, ensuring test isolation and preventing state leakage across test suites. Proper testing practices are essential for maintaining code quality in any web development project.

setUp(() {
 GetIt.I.reset();
 getIt.registerFactory<ApiService>(() => MockApiService());
});

test('user repository fetches data', () {
 final repository = getIt<UserRepository>();
 expect(repository.getUser('123'), isNotNull);
});

Common Patterns and Examples

Practical application of GetIt and Injectable involves patterns that emerge repeatedly across Flutter projects. Understanding these patterns helps you make good architectural decisions from the start.

Repository Pattern with DI

Repositories that abstract data sources benefit significantly from dependency injection. Your data layer can depend on repository interfaces while concrete implementations are registered separately. This abstraction allows switching between local storage and remote APIs, enabling offline-first development and facilitating testing with mock data sources.

// Abstract the repository interface
abstract class UserRepository {
 Future<User> getUser(String id);
 Future<void> saveUser(User user);
}

// Concrete implementation
@injectable
class UserRepositoryImpl implements UserRepository {
 final ApiService apiService;
 final LocalStorage localStorage;
 
 @injectable
 UserRepositoryImpl(this.apiService, this.localStorage);
 
 @override
 Future<User> getUser(String id) async {
 // Implementation
 }
}

// Register with Injectable
@module
abstract class RepositoryModule {
 @injectable
 UserRepository getUserRepository(UserRepositoryImpl impl) => impl;
}

State Management with GetIt

BLoC, Riverpod, and other state management solutions integrate naturally with GetIt. Factory registration creates independent state management instances for each widget, while lazy singleton registration works well for application-level state that multiple screens need to access.

// Register BLoC as factory - each widget gets its own instance
getIt.registerFactory(() => CounterBloc(getIt<CounterRepository>()));

// In your widget
class CounterScreen extends StatelessWidget {
 final counterBloc = getIt<CounterBloc>();
 
 @override
 Widget build(BuildContext context) {
 return BlocProvider.value(
 value: counterBloc,
 child: CounterView(),
 );
 }
}

Advanced: Modular Architecture

Larger applications often benefit from modular architecture, where different features have their own service registrations. GetIt supports this through modular setup functions that register related services together, keeping the overall architecture organized as the application grows. Building modular architectures is a core practice in our web development services.

// auth_module.dart
void setupAuthModule() {
 getIt.registerLazySingleton<AuthService>(() => AuthServiceImpl());
 getIt.registerLazySingleton<UserSession>(() => UserSession());
}

// data_module.dart
void setupDataModule() {
 getIt.registerLazySingleton<ApiClient>(() => ApiClient());
 getIt.registerLazySingleton<CacheManager>(() => CacheManager());
}

// main setup
void main() {
 setupAuthModule();
 setupDataModule();
 runApp(const MyApp());
}

These patterns provide a foundation for building maintainable Flutter applications. By separating concerns through dependency injection, you create code that remains flexible as requirements evolve and new features are added.

Sources

1. HackerNoon: Flutter Dependency Injection - Complete Guide Using GetIt
2. LogRocket: Dependency injection in Flutter using GetIt and Injectable