Prerequisite— Basics of state management in Flutter.
Flutter framework has grown a lot since it has come into this world. There are a lot of options for everything in Flutter and the options are growing and growing. APIs are a vital part of any real-world application as the mobile apps can be connected to the internet or back-end through APIs.
Handling the APIs especially the real-time APIs can be really painful as the data changes a lot with time. And if the app is really complex then it will surely be using any state management strategy. So, with every state management strategy, handling the APIs may also differ. State management can be really painful in any development framework if not taken care of. There are multiple options for state management in Flutter like Providers, BLoC, Redux, MobX, etc.
Huh! it seems confusing while Choosing a perfect state management solution but it really depends upon your taste and convenience.
MobX is an effective state management strategy that provides hassle-free and reactive state management for Flutter and Dart applications. MobX was first introduced in the native web then it’s Dart version came into existence after the evolution of Flutter as a grown framework.
MobX — An Introduction
MobX works in a cyclic-process in which there are 3 key components:
- Observable — An object or anything which can be observed for changes. Observables represent the reactive-state of the system.
- Action — These are the methods by which we mutate the observables. Instead of mutating them directly, we can use actions that will add semantic meaning to the observables.
- Reaction — These are the observables of the system which will observe the Observables and will be notified when the observables are changed.
Now, after a brief intro about MobX let us dive straight into the code. For this article, I have used 2 APIs, viz. https://jsonplaceholder.typicode.com/posts for posts and https://reqres.in/api/users?page=1 for users.
For the purpose of this article I will be using the following packages:
First of all, we will be creating the data models as per our requirement. In this case, we are using two kinds of data, one is the user data and the other is the list of posts. For that, we will be creating separate classes.
Here is the code for both the classes:
For MobX state management we are required to create a central store for our application and this store will contain the business logic related to our application. In best practices, it is suggested to create a single store for each model i.e. for each kind of data. We will be building two stores, one for the user data and the other for the posts that we are going to retrieve from the API.
Here’s the code for the user store.
In the above code, we are creating a store in Flutter for our user data model. In our store, there’s an observable annotation that refers to an ObservableFuture object and that will be observed by our components and widgets throughout the app. Along with that, there’s an action annotation that is used to perform a specific action on the observable and we are fetching the users from our network service(discussed later) in this particular action.
In order to work will stores in MobX, we are required to run an external command into the terminal which will build the store for us. The command for that is:
flutter packages pub run build_runner build
As we have created a store for the user, so I would like to suggest you create a store for the post on your own which will be similar to the previous one and obviously you can try my solution as well which is given below:
Now, after the data models and stores in place, we are required to define the network service that we are using for fetching the data into the store. We can also define the network service within the store and even within the action, but taking separation of concerns into consideration it is advised to separate the business logic and helping components in order to get loosely coupled software engineering practices. This will help in complex projects :)
Now, till here we are ready with our data and the only left part is the UI. So, let us build the UI for our application. Here’s is my implementation of UI. Feel free to give your own UI :)
The above is the UI for the home page. Here, we are having two tabs and each tab will contain the post and the user list respectively.
In the code above, an Observer widget is used for building the UI. This Observer widget will be notified whenever there is a change in the observable as this is the reaction part of the MobX lifecycle.
Now, this completes our first tab of the home page, i.e. the list of posts page. We are having another tab which will display the list of users as well. I would like to suggest you try the UI by yourself by referring to the above code. It is simple and you can always check my solution which is given below.
This completes the app that we were supposed to build and this app can be extended and evolved up to a great extent. This was a kind of a demo app that will not be a complete application though but still, this will give you a kickstart of using APIs handling with MobX state management.
Here are some of the screenshots of the Application:
Ohh! You’re still here. Thanks for reading this article with patience and I appreciate your passion for the topic. I have tried my best to serve this article. Also, the app built in this article is a minimal one and this technique of handling the API calls can be used in other big projects as well. Lastly, I would like to request you to please share your views regarding this article and help me improve this more and more. And if you liked this article then please clap on this and share it with your network.
The code for this article is available in the GitHub repo: https://github.com/ritesh-sharma33/Mobx-Api-Handling
Thanks a lot and Keep Fluttering :)