E-Commerce app utilizing Flutter– Part 4: Scoped Design

Building the Flutter E-Commerce app using ScopedModel

In this part, we’ll be utilizing ScopedModel to handle our app’s state. As discussed in the documents of the ScopedModel:

ScopedModel is a set of utilities that permit you to quickly pass an information Design from a parent Widget down to it’s descendants. In addition, it likewise re-renders all the children who use the model when the model is updated.To start using Scoped Design

, we require to include its dependency in our pubspec.yaml file: Then we produce our ProductScopedModel class that extends Model from the bundle scoped_model: This where we'll define all our approaches associated with the items. The code for the very same can be discovered here. We'll also move are remote information fetching to this class from the ProductsListPage class. The approaches defined over here are: The _ getProductsByCategory()approach and the parseProductsFromReponse()approach are the exact same as we had earlier other than that the parseProductsFromReponse ()technique doesn't return a List now however calls notifyListeners ()rather

. We likewise have a bool variable called _ isLoading that is toggled to signify if our app has completed fetching & parsing the remote data.notifyListeners( )This approach is the core of ScopedModel. This technique rebuilds the ScopedModelDescendant widget every time the design modifications. For this reason, we do not have to call setState anymore. Every time the information in our model changes, we call notifyListeners( )in that technique as revealed above in the parseProductsFromResponse()technique. This would restore our ScopedModelDescendant widget immediately. "Where is ScopedModelDescendant?"First, we produce a ScopedModel widget. This will supply the design to the kids that request it. We simply wrap our Scaffold widget with the ScopedModel widget inside the construct ()approach of our ProductsListPage (): We merely covered our Scaffold in a ScopedModel widget and supplied a model i.e. ProductScopedModel() to it . Keep in mind that we created our design outside our ScopedModel widget so that we can invoke our preliminary API call utilizing the design. Next, we create a ScopedModelDescendant.

This widget will get the ProductScopedModel from the closest ScopedModel . It will hand that model to our home builder approach, and rebuild any time the ProductScopedModel changes (i.e. after we notifyListeners in the Model) . We have actually separated out our ProductsListPageBody into a separate widget so that we return a ScopedModelDescendant widget from its construct () method: Here, we display a CircularProgressIndicator widget till the time our design's isLoading getter returns real. It would return false when all remote information has been brought and parsed. That's when model.isLoading would end up being incorrect and we 'd have the ability to conjure up the _ buildListView()

method.Since we're being notified when our design modifications, thanks to the notifyChanges()approach, we do not need to utilize the FutureBuilder widget which would upgrade itself as quickly as notifyListeners() gets called in our design: 2 crucial things to keep in mind here: If the model returns an empty item count, we show a Text widget with the message No items offered, for this reason informing the user about the same.We no longer have a hardcoded itemCount for the ListView.builder. Our itemCount is model.getProductsCount ()+1. The +1 is for the SORT

and REFINE Container at the top. Likewise, note that we've eliminated the SizedBox at thebottom and changed that with a Cushioning widget.Now we have a completely practical list of products. Tapping on any among them would take us to that item's information page.We can improve this by adding pagination to our list of items so that more products are fetched from our remote information as the user scrolls down in the list.Adding support for pagination: Our app loads 6 products at a time and as quickly as the list is scrolled to the Sixth product, the next 6 are fetched.We include an if statement prior to we look for other indices in the list to see if we have actually scrolled till the end of the available items. If we have, we examine whether there are more products to be fetched using. If we do have more products, we increment the pageIndex, fetch the next 6 items as well as display a CircularProgressIndicator. We have a variable called currentProductCount, which we initialise to 0 for every

1. new API call. Next, we increment this variable each time we effectively parse an item in the forEach technique. If we parse lessthan 6 items, that indicates that we've got no more products on this page and thus we can stop making API requires bring more products. That 's when we toggle our bool to false which is then informed to the ScopedModelDescendant in our ProductsListPage( )and for this reason this technique to bring remote data again is not invoked.And there we have it, our app works on both Android and iOS and a user can easily utilize it to place orders in real-time!

The whole code for Part 4 can be found here. The complete source code for this tutorial can be found here.