Series 3 — Part 2 of 2

GetX in Flutter — Part 2: Dependency Injection and a Verdict

Series: Exploring Flutter State Management Alternatives

In Part 1 I built a basic GetX app and explored its state management and navigation. In this post I look at dependency injection, fix the bugs I introduced along the way, and land on a verdict for when I would choose GetX over Riverpod.

Dependency injection in GetX

GetX uses a service locator pattern. You register a dependency with Get.put() or Get.lazyPut(), and retrieve it anywhere with Get.find(). This is fundamentally different from Riverpod's compile-time provider graph.

// Register
Get.put(ProductController());

// Retrieve anywhere
final controller = Get.find<ProductController>();

The advantage is simplicity. The disadvantage is that Get.find() can throw at runtime if the dependency has not been registered yet. With Riverpod, the compiler would catch missing providers. With GetX, it is a runtime crash.

Bugs I hit and fixed

I ran into two issues during the implementation:

1. Unregistered Dependency: Get.find() failed because I was calling it before Get.put() had executed. The fix was to move registration into the route's Bindings class.
2. Disposed Callback Navigation: Navigation inside an async callback was triggering after the widget tree had disposed — a classic issue when using global navigation without checking the component's mounted state.

GetX vs Riverpod: when to use which

After building with both, here is my honest take:

• GetX is excellent for rapid prototyping, hackathons, and simple apps where you want to move fast and the team is small.
• Riverpod is better for production apps where testability, compile-time safety, and explicit dependency graphs matter more than reducing boilerplate.

Both can be combined with MVVM. GetX makes it optional; Riverpod makes it natural.

What I learned

• Compile-time vs Runtime: Get.find() is a runtime error if the dependency is not registered — Riverpod catches this at compile time.
• Use Bindings: Binding classes in GetX are the right place to register dependencies, not main().
• Pick for longevity: GetX is fast to write; Riverpod is safer to maintain. Choose based on the project's lifecycle.