Open for work
Back to Mobile Application blogs
Mobile Application5 Min Read

Enterprise State Management: Why We Rely on Provider and BLoC for Flutter Apps

State management is notoriously the most difficult part of frontend mobile development. If poorly architected, an app quickly devolves into "spaghetti code." Learn how Isaii Technologies scales massive enterprise applications like retail POS systems and HRMS using Flutter’s most powerful state management patterns: Provider and BLoC.

By Isaii Team

Enterprise State Management: Why We Rely on Provider and BLoC for Flutter Apps

The State Management Trap

In software engineering, state management means the manipulation of data stored in the application's memory. Have you logged in? What products do you have in your cart? Is the dark mode option turned on?

During the initial stage of mastering any framework, such as Flutter, developers use elementary methods such as setState() to update the interface. Upon receiving a click, setState() causes a new data-based rendering of the screen. For a simple calculator application, it is ideal.

However, when developing an enterprise application, the use of setState() can become a disaster.

Let us consider the development of Bill Buddy retail Point-of-Sale (POS) application. In case the cashier scans a product using a barcode reader, the application should, at the same time, update the interface of the cart, calculate the taxes dynamically, find the necessary product in real-time in the warehouse, apply the client's discount, and forward the transaction to a Java backend.

In order to develop scalable and enterprise-level applications using Flutter, it is important to separate the User Interface (the screen pixels) from the Business Logic (the calculations and data). At Isaii Technologies, this strict separation is done using both Provider and BLoC.

Separating business logic from the UI ensures that our engineering teams can scale applications without breaking existing features
Separating business logic from the UI ensures that our engineering teams can scale applications without breaking existing features

Foundation: Dependancy Injection via Provider
Prior to managing the state, it is necessary to have an efficient mechanism in place to pass the data within the widget tree.

If the user authentication token is validated at the very top of the app during login, how is the "Account Settings" screen on the lower end of the app supposed to get hold of that token? Passing of the data all the way down to each screen is not only inefficient but error-prone.

This is where Provider steps in. Provider is a very elegant solution to dependency injection. It simply wraps our widget tree around and allows us to "provide" data such as user session, theme preferences or connection to database from the top of the widget tree. Any screen at any level will be able to fetch the data directly without needing to pass it through the intervening layers.

Provider is perfect for simple and passive state management. However, once the data becomes dynamic and transactional, we pull out the big guns.

Enterprise Heavyweight: The BLoC Architecture
BLoC (Business Logic Component) is the industry best when it comes to managing state in the enterprise for applications built using Flutter. This architectural style follows a strict, unidirectional data flow that makes use of Streams and Events.

The UI is no longer in control; the UI is simply the dumb screen that generates "Events" for the BLoC. The BLoC does everything else—communicates with the database, calculates the math, and returns a "State" to the UI.

Why Isaii Uses BLoC for Complex Modules

Take an example of the Isaii HRMS system. When the employee uses the mobile app to clock in using geofencing technology, the app should confirm that the GPS location of the employee is valid, that the employee is part of the right shift roster, and that the timestamp will be stored securely despite any temporary loss of connection to the network.

Here is how BLoC handles this safely and correctly:

The Event: The user clicks "Clock In" on the UI. The UI doesn't make any decisions – all it does is emit the ClockInRequested event to the AttendanceBloc.

The Logic: AttendanceBloc gets the event and reacts. It triggers loading state, confirms the GPS coordinates through validation against the backend and executes the logic.

The State: In case of success, BLoC returns Attendance Success state. In case of a network connection failure, it returns AttendanceOfflineCached state. The UI only listens for these events and displays a green tick or an alert icon accordingly.

With the help of BLoC, our UI code doesn't have any logic at all.

By isolating business logic, our UI designers and backend engineers can work in parallel without code conflicts..
By isolating business logic, our UI designers and backend engineers can work in parallel without code conflicts..

Flutter Architecture that is Unbreakable

There is no place for memory leakages, freezes, and lost transactions when talking about enterprise software. The use of Provider in order to inject dependencies together with BLoC for reactive business logic helps us to create super-fast Flutter applications which are structurally perfect.

When we build you a custom ecosystem, then we guarantee that the mobile and web frontends are as robust as Java servers supporting them.

Do you have an enterprise application which crashes and has "spaghetti code"?

Get in touch with Isaii Technologies today. Let's schedule a technical review and see how you could dramatically increase your software performance and stability by re-architecting your frontends with Flutter and BLoC.

Next step

Interested in working together?

Tell us about your product or idea — we'd love to hear from you.