Shulou(Shulou.com)06/02 Report--

This article mainly explains "what is the method of state management of FlutterDojo design". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the method of state management of FlutterDojo design".

Provider is used in the list

In the previous explanation, most of our scenes are in the ordinary Box layout. I believe you are very clear about the use of Provider. Let's take a look at the use scenarios in List. I believe that for many App, the list should be the core UI of most pages. So, how to use Provider in the "drop-down refresh", "pull-up load more" and "Item click to modify status" scenarios of the list? The official Demo does not give very good advice, and the official Provider is demonstrated in a static list, which does not involve list changes, so I will discuss with you how to use it in the list.

Of course, this is just my exploration. I hope readers can come up with a better plan.

First, create the Demo interface for this example.

To simplify Demo and allow readers to focus on the use of Provider, instead of using drop-down refresh and pull-up loading frameworks, they are simulated by two Button, and each Item provides a CheckBox to demonstrate the refresh of a single Item.

In order to restore the scene as much as possible, the acquisition of Mock data is also provided here, as shown below.

Class ItemModel {

String title

Bool isCheck

Int likeCount

ItemModel (this.title, this.isCheck, this.likeCount)

}

Class DataModel {

List dataList = List ()

Future getData (int pageIndex) async {

List items = await api.getListDataOfIndex (pageIndex)

DataList.addAll (items)

Return dataList

}

}

Class API {

Future getListDataOfIndex (int pageIndex) async {

List data = List ()

Await Future.delayed (Duration (seconds: 3))

List.generate (

ten,

(index) = > (data.add (ItemModel ('Title $index @ Page $pageIndex', false, Random () .nextInt (20) + 1))

);

Return data

}

}

Var api = API ()

For other UI code, you can refer to the source code of Dojo, as shown below.

Flutter_dojo/category/backend/providerstate4widget.dart uses Setstate

First of all, let's look at the most basic way. The principle of updating data through setState is to refresh the UI using setState after the Future is completed. The core code is as follows.

Get the data.

Data.getData (pageIndex) .then ((value) {

SetState (() = > data.dataList = value)

});

Refresh selected.

Checkbox (

Value: itemModel.isCheck

OnChanged: (flag) {

SetState () {

Var isCheck = itemModel.isCheck

If (isCheck) {

CheckedCount--

} else {

CheckedCount++

}

Return itemModel.isCheck =! isCheck

});

})

Drop-down refresh and pull-up load.

RaisedButton (

OnPressed: () {

SetState () = > data.dataList.clear ()

Data.getData (0) .then ((value) {

SetState (() = > data.dataList = value)

});

}

Child: Text ('Refresh')

),

RaisedButton (

OnPressed: () {

Data.getData (+ + pageIndex) .then ((value) {

SetState (() = > data.dataList = value)

});

}

Child: Text ('Load More')

),

Text ('Checked Count $checkedCount')

There is nothing wrong with this approach, especially when List occupies the entire UI interface, which is the simplest and less efficient. Only when the page is more complex, you need to consider using Provider to reduce the efficiency problems caused by refresh.

Let's consider how to transform the entire Demo through Selector to complete the functions of refreshing data, loading more data, and displaying the number of Checked.

Revamping Model

Model is the data processing object of Provider, which encapsulates the data model and data processing operations. The transformation here is basically the same as the Model using Provider explained earlier, and the code is shown below.

Class ItemModel {

String title

Bool isCheck

Int likeCount

ItemModel (this.title, this.isCheck, this.likeCount)

}

Class DataModel with ChangeNotifier {

List dataList = List ()

Int checkedCount = 0

Bool shouldListRebuild = true

GetData (int pageIndex) async {

List items = await api.getListDataOfIndex (pageIndex)

ShouldListRebuild = true

DataList.addAll (items)

NotifyListeners ()

}

RefreshData () {

DataList.clear ()

CheckedCount = 0

ShouldListRebuild = true

NotifyListeners ()

}

UpdateChecked (int index, bool isChecked) {

ShouldListRebuild = false

Var item = dataList [index]

If (isChecked) {

CheckedCount++

} else {

CheckedCount--

}

DataList [index] = ItemModel (item.title, isChecked, item.likeCount)

NotifyListeners ()

}

}

Several new functions have been added to get paged data, refresh data, and update the Checked status of Item.

Modify the refresh logic selected by ListItem

In the previous scenario, when we clicked on an Item to make changes, the entire List will be Rebuild, through Selector, you can filter by attributes to filter out the Item that needs to be refreshed.

When the List content is fixed, you don't need to refresh the entire List, you just need to update the changed Item.

In the ItemBuilder of List, we do a Selector filter to filter the ItemModel in dataList. When you click CheckBox in the specified Item, the model is updated, so the shouldRebuild of Selector is judged to be true, so the Item will be updated, while other unclicked Item will not be updated because it has not changed, thus controlling the refresh range of List to the updated Item, as shown below.

Return ListView.builder (

ItemBuilder: (context, index) {

Return Selector (

Selector: (context, value) = > value.dataList [index]

Builder: (BuildContext context, data, Widget child) {

DebugPrint (('Item $index rebuild'))

Return Card (

Child: Padding (

Padding: const EdgeInsets.all (8.0)

Child: Row (

Children: [

Checkbox (

Value: data.isCheck

OnChanged: (flag) {

DataModel.updateChecked (index,! data.isCheck)

})

Text (data.title)

Spacer ()

Icon (Icons.favorite)

ConstrainedBox (

Constraints: BoxConstraints (minWidth: 30)

Child: Center (child: Text (data.likeCount.toString ()

),

]

),

),

);

}

);

}

ItemCount: dataModel.dataList.length

);

The refresh control of Item is actually relatively simple, and it is also a general solution for Selector, but the usage scenario of Selector is List with fixed data. If the data of List will change, there will be problems with the use of Selector. For example, most of our List usage scenarios of APP include two processes: refreshing data and loading paging data, so the data source of List is changing all the time. When the home page data is loaded, it may also need to display a Loading interface. Therefore, in these scenarios, the whole List must need Rebuild. A Selector is powerless, but we can add another Selector to control whether the List needs to be refreshed, so that we can finely control the refresh range of the List in different scenarios.

Refresh the entire List when the list data is not fixed. When the list data is fixed, only refresh the updated Item.

With this in mind, you can understand why a shouldListRebuild variable is needed in the previous Model, and the rest of the code is shown below.

Expanded (

Child: Selector (

ShouldRebuild: (pre, next) = > pre.shouldListRebuild

Selector: (context, dataModel) = > dataModel

Builder: (BuildContext context, DataModel dataModel, Widget child) {

If (dataModel.dataList.length > 0) {

Return ListView.builder (

ItemBuilder: (context, index) {

Return Selector (

Selector: (context, value) = > value.dataList [index]

Builder: (BuildContext context, data, Widget child)

A trick here is Selector, here only with the help of Selector's shouldRebuild function, so there is no data filtering, the complete code, please refer to the implementation in Dojo.

Flutter_dojo/category/backend/providerstate4widget.dart

The actual operation is to refresh and load paging data, let shouldRebuild be true, and when only modify Item data, let shouldRebuild be false, thus completely control the refresh range of List.

Thank you for your reading, the above is the content of "what is the method of state management of FlutterDojo design". After the study of this article, I believe you have a deeper understanding of what the method of state management of FlutterDojo design is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.