Within a mobile application, you have different screens that need to be kept up-to-date. To keep these up-to-date, the state manager can be used. In this way, the UI can be updated when the state changes. Just like how the stateful and stateless widget of Flutter works, except those are bound to that specific widget. Because the state can be maintained and listened to across multiple screens, useful information/feedback can be shown to the user. Below is an example of what the flow of a state might look like.

As can be seen in the animation above, it shows how the mobile application is navigated. On the catalog screen, a product is added to the cart. This requires state management because the state of the mobile application is being adjusted. The mobile application needs to know that a product is added to the cart so that the products that are in the cart can be shown on the cart page.

The image below shows a schematic representation of Bloc Provider. It shows how the states are maintained and how they work.

When an event (action) is performed in the UI, the Bloc is called. The Bloc, if necessary, makes a request to an API or performs another action. As a result of this action, the UI may need to be adjusted based on what has come from this action. The Bloc returns the status, also known as the state, to the UI. In the UI, it can be checked whether the state is the same or if the state has changed. If the state has changed, the UI must also be adjusted. As a result, the widget is recreated with the logic of the respective state.

Within the Bloc Provider, there are two possibilities for managing the state via Bloc or via a cubit. For this project, the choice was made to go for the cubit. This is because the cubit itself does more than the Bloc. This means that less code has to be written by oneself.

In the schematic representation above, the naming for Bloc can be replaced by the state. The operation remains the same. So, in the cubit, the logic is handled. Here, the request to a service or the like is also called. While making a request and or logic, the state can change. From the Cubit, the state is called. When calling the state, a signal is sent to the UI that the state has changed. Based on this, the UI can be updated.

An example here is that you have a button on the UI page with which you can retrieve/update the weather. As soon as this is pressed, an event is sent to the cubit (Bloc). In the cubit, for example, the loading state is called. Then the cubit makes a request to the service that then calls an API. This results in a success response and we get the new data of the weather back in the cubit. Now that we have this data, we can update the state of the mobile application by calling a different state in the cubit. When calling this state, we also pass the result, so we can read the new data in the UI. This is briefly how the Bloc state management is applied within the project.

When you, as a developer, should choose to maintain the state depends on exactly what needs to be made. The same applies here as with a stateless or stateful widget as described earlier.