DEV Community: Dhruvil Patel

Provider — Manage your state efficiently in Flutter.

Dhruvil Patel — Thu, 23 Sep 2021 19:03:31 +0000

Understanding basic state management concept:

Before diving deep into the Provider package, let’s understand what state management is.
For better understanding, we’ll take a simple shopping app for reference.
In the above image, we can see that there is an app bar, a drawer, a cart, a favorites section, an orders section, and products.

Firstly, let’s decrypt the above image.

At the very top, there’s MyApp class which is the entry point of our app. Then it’s divided into 4 paths which lead to separate classes and functionality homepage, cart, favorites, orders. Further away, the homepage extends to provide us the app bar and access to product items.
Now, if we add a particular product as a favorite or as a cart item then we need to call setState() and update the UI of the Favorites screen or the cart screen respectively. Not to forget about passing the data along when clicking on favorites or the cart icons. By the data we passed, we can now display the products which were marked as favorite or added to the cart. But sometimes it becomes janky/messy while managing state, passing data, updating the UI, etc. all at once.
In short, all our data should be in the topmost widget/class (in this case MyApp), and bypassing it through arguments from widget to widget becomes kind of messy. Also, performant issues can arrive as if any smaller widget needs data, the whole parent class will change its state. So to prevent it, we use the Provider package.

Provider Package intro:

Implementation of the Provider package is pretty simple. Firstly, select the class of which, the data should be shared among the whole app. Then simply add ChangeNotifier class in mixin form with the ‘with’ keyword.

Quick tip:
In the case of inheritance, we instance the whole class into another class. While if we add a mixin to a class, it is just instance properties and methods of the class added.

As shown in the above image, YourClassName mixes with ChangeNotifier class. It is a special class provided by the Provider package.
Now, we can also see notifyListeners() method which comes with ChangeNotifier class. What this function does is that if there is some change in data in the class where ChangeNotifier is mixed(in this case YourClassName), it will call the method and update the data and reflect it on the UI. Taking in mind the example of our e-commerce app, let’s understand this method.
Let’s say there is a class named Products. In that, there are several methods like markAsFavorite(), addToCart(), etc. Now, the products must be a map of properties of each product like price, description, title, id, isFavorite, etc.
And when we call markAsFavorite() method, a new map will be formed containing only those products marked as favorite. This whole logic will be in this method and at last, there will be notifyListeners() which will tell the app state to change its data accordingly. This data can be used to render only those products which are marked favorite.

This was in class. But, how do we implement it in our widgets? Well, as mentioned in the above image, first, we declare a variable and assign the data to it by fetching it through the provider. Its syntax is similar to that of media query if you've used it in flutter. Likewise, it uses context to get the location from where the data is stored.
Since it’s of a generic type, we have to provide what type of value/data we want. Like in Row/Column widget we mention . Moving ahead, we can provide our class name in which the data is stored and the same data which we want to retrieve. And just like enums in the dart, we can access a specific part of data as shown in the image.
Now, you may wonder that what is this listen: false mentioned in the below image even though the syntax is the same as above.

The difference is that: If we mention listening to false, it will not re-run every time some data is changed. This is useful when you just wanna display or store the data in the app. As it won’t require rebuilding the whole app, it will be beneficial to performance.

Now, time to understand one of the very main concepts of implementing the provider package. As mentioned earlier, we need to provide the providers carrying data at the topmost level of our app. So it can be easily passed down through the whole app.
As shown in the image above, you can wrap your MaterialApp or entry widget inside another class provided by the provider package. The ChangeNotifierProvider class, which will have all the providers you need pointing to the respective class mixed with ChangeNotifier. This was the case for a single provider throughout the app.
There’s also a scenario where you’ll see ChangeNotifierProvider.value as in the below image.

The simple justification is that when you first initialize the class, it is better to use create method. After that, when every time you call ChangeNotifierProvider, you just need to call its value rather than the whole function which is already initialized in the main file.
Moreover, in many cases, you may have more than one provider in your app. The below-mentioned method would be the way to execute it.

MultiProvider:

Yes, there is a MultiProvider class. It basically consists of the list of providers and again same rules apply here. If you’re setting up the class for the very first time, you’ll need to use create method.

Consumer:

Last but not the least, this will be the final topic covered in this blog post.

Consumer as from the syntax can be seen that is very much like Provider. And indeed it is. But it has its own benefit. Let’s see how.
So, there are many circumstances when we just need data for a specific child widget and not for main or bigger widgets. Hence it doesn’t make sense to use the provider in that child’s parent widget.
The reason is very simple. It will just rerun the whole parent widget unnecessarily whenever there is a change in its child widget.
To sum it up, Consumer will only rebuild the widget it is attached to. In this case, the IconButton widget. So, this was all about the Provider package and its implementation.

Here are some links to documentation regarding the Provider package:

Provider package documentation
State management docs at flutter.dev

Navigation made easy with Flutter

Dhruvil Patel — Fri, 06 Aug 2021 18:48:11 +0000

Flutter is a framework for the dart programming language used for building cross-platform mobile apps and even web pages. Flutter converts code into the native language (Kotlin/Java, Swift for apps and HTML, CSS JS for web).

Although, which app or website is better without navigation amongst screens or pages respectively unless you have single-page applications.

Let's understand how Flutter provides such ease in navigation.

Concept:

Flutter implements the concept of Stack datatype in making navigation possible.
In normal terms, Stack is a pile of objects referring to the concept of LIFO(Last In First Out). For example, the stack of books, the stack of money, etc.
In Flutter's case, there is a stack of screens. Scaffolds or any custom widget which represents a screen.

Note: Stack widget and stack referred here are two different cases.
Here, a stack is referred to as datatype not Stack.

Methods of navigating:

Push()

In the above code snippet, Navigator class provides method push which does the same function as in datatype. It pushes the screen on the top of the screen which is currently been rendered.
Navigator accepts context to locate the position of the current Scaffold(Screen) in the widget tree.
Then after, We pass another so-called method in push(). Moreover, MaterialPageRoute is not mandatory. You can also provide CupertinoPageRoute which will differ in transition effect only.
To check out more about them: CupertinoPageRoute MaterialPageRoute
It accepts builder argument to build the screen to which you will navigate.
The following screen can be provided by arrow function or normal function as shown in snippet.

PushNamed()

It has the same functionality as push() do but rather than navigating dynamically, it accepts routes provided and accordingly proceeds.
Similarly, it starts with Navigator.of(context) , and then we implement pushNamed method. It accepts the route name as its argument which will tell Flutter where to navigate. > Important points to note: * It is good to set a static route name so that it can be used not only in that particular file but also in the file where you set functions of navigation according to these route names. * For example: * In the above snippet, routes argument is passed which is available in MaterialApp which is the entry widget of your app. It consists of all the routes available or mentioned in your widgets.

To add the route we need to provide the route name by the way mentioned in the snippet. The class enum in which your route is and calling it like it's property

For e.g, Alignment.center
Then we provide value to route name in the form of arrow function of context, and the screen or rather the class constructor which should be rendered after navigation.
Other than route name, we can also see the arguments parameter. It is simply the arguments you want to pass to the page we will be going to. For e.g, there is a shopping app and you want to navigate to the details of a product by clicking on it then you can pass the id of it and it will render all the details of the product of id passed as an argument.
To accept the argument, the following method can be used:

Note that you need to provide the data type in which your arguments will be passed on. Then you can simply access it by

routeArgs['id']

Pop()

From above snippet, it clearly tells that pop process is simple. However, we can see that an Id argument is passed in it. What is it?
It is the parameter that is passed back reverse to the page it goes to.
For e.g, if SecondPage pops and Flutter renders FirstPage back then the Id argument will be passed to FirstPage and we can perform various methods with it.
Where we pushed the page we came from, we can add then method following push and receive the data.

Other push/pop methods:

pushReplacement() / pushNamedReplacement: It is also an important. What Flutter did till now was keep adding screens on top of each other every time we navigate. It would lead to memory leaks in the future. The above method just replaces the screen with a new one.
pushAndRemoveUntil() / pushNamedAndRemoveUntil(): It will push the page and remove all other routes as soon as the condition provided it met.
popAndPushNamed(): It will dispose of the current page and push another page according to the route provided.
popUntil(): It will repeatedly pop pages until the condition is met.
canPop(): It will check if the page can be popped. For e.g, if there isn't any page to go back to.
restorablePopAndPushNamed(): It will pop the current route of the navigator and push a named route in its place.
maybePop(): It checks for the willPop() method and return result accordingly. Head here to find out more => maybePop.

Thus, there can be many ways to navigate between pages and optimization.

How Flutter handles everything behind the scenes?

Dhruvil Patel — Mon, 26 Jul 2021 18:11:35 +0000

Flutter is a cross-platform UI framework for dart which provides features to develop mobile apps. Elegant and astonishing apps can be built with Flutter.

Flutter renders the code written to the screen of the device in the form of widgets. It can be a desktop, a mobile, etc. Device screens are the canvas for our app on which Flutter paints the widgets and sums up to a fully-fledged app.

But that's not only what Flutter does. But just displaying widgets is not the only thing Flutter does. Behind the beautiful UI, there lies the logic of how the app will work.

In this post, we're going to explore the understanding of how Flutter manages to provide such amazing apps.

Image Elaboration :

Widget Tree :

Widget tree holds the configurations about the widget which are created when the app runs for the very first time.
For example, the container widget in the widget tree holds the configurations like background color, box-shadow, border radius, etc.
Every widget in the widget tree holds some information or properties about the particular widget.

Element Tree :

Each widget present in the widget tree is linked to the respective element.
Elements are just like empty widgets referring to their associated widget.
For example, in the image above, the container is linked to the container element, column -> column element, etc.
These elements perform the major role of connecting widgets from widget tree to rendered widget from render tree.
These elements provide a reference to configurations of widgets present in the widget tree.

Render Tree:

The configurations of the widget which are pointed by element object are passed onto rendered widget which then accordingly to those properties render the widget on the screen.

Exclusive case of Stateful Widget:

As per the image, we can see that there is some variation in the linkage between the stateful widget and its corresponding element.

The element is connected to the widget as well as the state. Now, what exactly is a state.

Whenever we create a stateful widget it creates two classes, namely User-defined class which extends StatelessWidget and another class which extends State class.
The other class we're talking about is created in the initial class with the help of the createState() method. This then rebuilds the widget according to the changes in state.

In this case, the scenario differs. It depends on the current state of the widget. Let's dive deep into it.

Initially, the element represents the widget and renders it on the screen according to its configurations.
But whenever the setState method is called it not rebuilds the whole widget tree which would make your app less performant but replaces the widget with a new one containing the configurations provided in the setState method.
For example, if there is a container with background color equals to red then it is stored as a value in widget configurations in widget tree which is then passed to rendering widget by container element which holds the reference to container and finally we see a red container on our screens.
But when we call setState suppose to change its background color to blue, then the new container widget with background = blue will replace the one with background = red.
Now the question arrives that what will happen to container element referring to the container with bg = red. Well, upon calling setState, it relocates its reference to a new widget that replaced the older one. However, the state object will not change. Just its properties will change which will be assigned to the new widget.
After all these processes, the element which refers to the new widget will inform the rendered widget about the changes and it will reflect on the screen.
Thus, Flutter not rebuilds the hold widget but only changes its reference to the updated widget. This will not lead to performance issues.

So, this was all about behind the scenes and how flutter manages all the rendering and updating of widgets.

Understanding syntax of Stateless and Stateful widgets.

Dhruvil Patel — Sat, 19 Jun 2021 19:38:38 +0000

#flutter Follow

An open source framework by Google for building beautiful, natively compiled, multi-platform applications from a single codebase.

#beginners Follow

"A journey of a thousand miles begins with a single step." -Chinese Proverb

In a Flutter app, everything is a widget. The whole app is a widget tree formed by combining widgets like Scaffold, Container, AppBar, and many more.
But 2 core widgets are controlling the state of widgets. They are Stateless Widget and Stateful Widget.
So what are these widgets? Let's understand it first before diving straight into the syntax.
Stateless Widgets are those widgets whose state cannot be changed. They are immutable. This explains that if you want to change the color of a container on tap then it's not possible with Stateless Widget. But it can have UI widgets such as Text and icon widgets.
Stateful Widgets on the other hand are the opposite of what we saw previously. Here, not only color but any property or value can be changed of a widget by calling setState method on onTap property. Thus, it's mutable.

As Flutter extensions in your code editor allow you to directly create a Stateless/Stateful Widget, we cannot get the idea of what exactly does the block of code does. So let's understand it.

Stateless Widget:

So the code starts with extending a class called StatelessWidget. Extending means that we are creating a class (Child Class) that will inherit all the methods and properties of StatelessWidget (Parent Class). In this case the class we defined as is MyApp.

Note:- StatelessWidget is a class created by material package by flutter. The package we import in every flutter app package:flutter/material.dart gives us the functionality of the StatelessWidget class.

Before going on to the next step let's understand that:
-> Functions inside a class are called methods and Variables inside a class are called properties of that class.
So now we have a method inside our MyApp class extended from StatelessWidget class.
Let's take an example of a function to clear it out:
Here, we have a function main of type void as it has no return type. It can also accept arguments/parameters. And finally the block of code inside it.
Similarly, we have a function of name build of type Widget as everything is a widget in flutter. Then we have a parameter context of datatype BuildContext.

Note:- It is not mandatory to use context word. we can also use ctx or cntxt. It depends on the person. And whenever we pass an argument or a parameter in a function/method then we need to state its datatype. For e.g, int age, String name.

Here, the build method is called by flutter whenever it needs to render something on the screen. context is an object holding information about our widget and where it is in the widget tree. BuildContext is a type notation for context which is a class provided by flutter.
And lastly the return type. As the method is not a void type, but a Widget type it should return something. In this case, it returns the MaterialApp widget. This widget is also provided by the flutter and it combines our widget tree and renders it to our fully-fledged app.

Stateful Widget:

As we can see there are 2 classes in this case. MyApp and MyAppState. One extends StatefulWidget and other extends State. Similar to StatelessWidget, these two classes are created by flutter itself.
Now, why we have 2 classes? It's because whenever the state of any widget changes, only the main class (MyApp) rebuilds, and another one (MyAppState) remains persistent.
For better understanding, remember MyApp class as widget class and MyAppState class as state class.
Also, State is a generic type class. Generic typed classes are those classes that function in the limit to the datatype mentioned. Here, we give it type MyApp so we can tell flutter that State class is a sub-class of MyApp and will work under it.
This was the first step to connect both the classes. Now we need to implement createState method inside our widget class.

Above image explains how we implemented State class in MyApp class to connect them.
It accepts no parameter but has a type State which is the same class provided by flutter. As it is a generic type class, it accepts StatefulWidget class as its datatype. It returns the child class we created which extends State class, i.e MyAppState class.

Note:- The main difference between these 2 classes is that the data which is inside State class does not change on rebuilding our app. Only the widget changes according to its state. So as mentioned above, Widget class rebuilds not State class.

And to the end, we can see @override keyword in both Stateless as well as Stateful widgets. But what is it?
What it does is that it tells flutter that we are using a method of the superclass and we intend to do use that method deliberately.