Developing complex apps that meet user expectations while consuming a fragmented API can be a challenge these days.
Let’s look at the following challenges we might face while working on real-world applications.
You may work on an app that has various features that need to communicate with each other. …
Although building forms in Flutter may seem like an easy task, separating the business logic from the UI layer can be a challenge. The separation of concerns makes your app more scalable and maintainable and most importantly the business (validation) logic becomes unit-testable, so let’s see how we can achieve this by using rx_bloc and flutter_rx_bloc. If you are new to rx_bloc, check out Introducing rx_bloc ecosystem. As usual, we will be using our lovely puppies sample.
The flutter_rx_bloc is a Flutter package that exposes your reactive BloCs to the UI Layer. In the previous article, Introducing rx_bloc: Part 2 (I recommend that you read it quickly before continuing with this article if you haven’t already), you learned how you can implement the business layer of the Counter sample and in this article, we’ll see how we can bind it to the UI Layer
Let’s start with what flutter_rx_bloc offers and how it can help us.
The rx_bloc is a Dart package that helps to implement the BLoC (Business Logic Component) Design Pattern using the power of the reactive streams. In the previous article, introducing rx_bloc ecosystem: Part 1 (I recommend that you read it quickly before continuing with this article if you haven’t already), you learned what motivated us to build this package …now it is time to see how it works in action.
By definition, the BloC layer should contain only the business logic of your app. …
State management is and will continue to be one of the hottest topics in the Flutter community. Even though Flutter comes with built-in Stateful Widgets, this is not enough for building an app that follows the SOLID principles. If you want the app you are building to be robust, scalable, and maintainable, you need to somehow separate the data layer from the business layer and then the business layer from the UI layer, right?
As developers, we always aim to write concise, maintainable, and scalable code. When the project grows, new developers are joining the team, it becomes more and more difficult to stay close to the state of the art. In order to make our lives easier we strive to apply the best practices, but what happens if you need to work on the same project on both dominating mobile OS (Android & iOS)? What if in those you have a completely different code base, in terms of architectural design patterns, used programming paradigm, etc?
We at Prime Holding also faced the above-mentioned…