Provider在列表中使用
在前面的講解中，咱們大部分的場景都是在普通的Box佈局中，相信你們對Provider的使用已經很是清楚了，下面來看下在List中的使用場景，相信對於不少App來講，列表應該是大部分頁面的核心UI，因此，到底如何在列表的「下拉刷新」、「上拉加載更多」、「Item點擊修改狀態」這幾種場景下來使用Provider呢？官方並無給出很好的建議，官方的Demo也都是在靜態的列表中作的演示，並不涉及到列表的修改，因此下面，我將和你們一塊兒討論下如何在列表中使用Provider。
android
固然，這只是個人探索，但願讀者能給出更好的方案。web
首先，先建立本例的Demo界面。api
爲了簡化Demo，讓讀者專一於Provider的使用，這裏並無使用下拉刷新和上拉加載的框架，而是經過兩個Button來模擬這兩個操做，同時，每一個Item都提供了一個CheckBox，用於演示單個Item的刷新。微信
爲了儘量還原場景，這裏還提供了Mock數據的獲取，代碼以下所示。框架
class ItemModel {
String title;
bool isCheck;
int likeCount;
ItemModel(this.title, this.isCheck, this.likeCount);
}
class DataModel {
List<ItemModel> dataList = List();
Future<List<ItemModel>> getData(int pageIndex) async {
List<ItemModel> items = await api.getListDataOfIndex(pageIndex);
dataList.addAll(items);
return dataList;
}
}
class API {
Future<List<ItemModel>> getListDataOfIndex(int pageIndex) async {
List<ItemModel> data = List();
await Future.delayed(Duration(seconds: 3));
List.generate(
10,
(index) => (data.add(ItemModel('Title $index @Page $pageIndex', false, Random().nextInt(20) + 1))),
);
return data;
}
}
var api = API();
其它的UI代碼，你們能夠參考Dojo的源碼，以下所示。dom
flutter_dojo/category/backend/providerstate4widget.dart
使用Setstate
首先來看下最基本的方式。經過setState來更新數據，其原理就是在Future完成以後，使用setState刷新UI。核心代碼以下所示。async
獲取數據。編輯器
data.getData(pageIndex).then((value) {
setState(() => data.dataList = value);
});
刷新選中。ide
Checkbox(
value: itemModel.isCheck,
onChanged: (flag) {
setState(() {
var isCheck = itemModel.isCheck;
if (isCheck) {
checkedCount--;
} else {
checkedCount++;
}
return itemModel.isCheck = !isCheck;
});
}),
下拉刷新與上拉加載。函數
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'),
這種方式並無什麼問題，特別是當List佔據當整個UI界面時，這樣其實最簡單也不太會影響效率。只有當頁面比較複雜的時候，才須要考慮採用Provider來下降刷新帶來的效率問題。
下面咱們來考慮下如何經過Selector來改造整個Demo，完成數據刷新、數據加載更多、顯示Checked數量幾個功能。
改造Model
Model是Provider的數據處理對象，封裝了數據模型和對數據的處理操做。這裏的改造和前面講解的使用Provider的Model的處理方式基本相同，代碼以下所示。
class ItemModel {
String title;
bool isCheck;
int likeCount;
ItemModel(this.title, this.isCheck, this.likeCount);
}
class DataModel with ChangeNotifier {
List<ItemModel> dataList = List();
int checkedCount = 0;
bool shouldListRebuild = true;
getData(int pageIndex) async {
List<ItemModel> 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();
}
}
新增了幾個函數，分別用於獲取分頁數據，刷新數據，更新Item的Checked狀態。
改造ListItem選中的刷新邏輯
在以前的方案中，當咱們點擊一個Item作修改時，整個List都將Rebuild，經過Selector，能夠根據屬性篩選，過濾出須要刷新的Item。
當List內容固定時，不須要刷新整個List，只須要更新改變的Item。
在List的ItemBuilder中，咱們作一個Selector篩選，篩選內容爲dataList中的ItemModel，當在指定的Item中點擊CheckBox後，model被更新，因此Selector的shouldRebuild被判斷爲true，因此這個Item就會被更新，而其它未點擊的Item則由於沒有改變因此不會被更新，這樣就控制了List的刷新範圍爲被更新的Item，代碼以下所示。
return ListView.builder(
itemBuilder: (context, index) {
return Selector<DataModel, ItemModel>(
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,
);
Item的刷新控制其實比較簡單，也是Selector的通用解決方案，可是Selector的使用場景是固定數據的List。若是List的數據會發生改變，則Selector的使用則會存在問題，舉個例子，咱們大部分APP的List使用場景都包含刷新數據、加載分頁數據這樣兩個過程，因此List的數據源是一直在變化的，當首頁數據加載時，還可能須要展現一個Loading界面，所以，這些場景下，整個List是必定須要Rebuild的，這時候，一個Selector就無能爲力了，可是，咱們能夠再增長一個Selector，用於控制List是否須要刷新，這樣就能夠在不一樣的場景下，精細控制List的刷新範圍。
-
當列表數據不固定時，刷新整個List -
當列表數據固定時，只刷新更新的Item
有了這樣的思路，就能夠理解前面的Model中爲何須要一個shouldListRebuild變量了吧，剩下的代碼以下所示。
Expanded(
child: Selector<DataModel, DataModel>(
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<DataModel, ItemModel>(
selector: (context, value) => value.dataList[index],
builder: (BuildContext context, data, Widget child)
這裏一個技巧是Selector<DataModel, DataModel>，這裏只借助了Selector的shouldRebuild功能，因此並無對數據作篩選，完整的代碼你們請參考Dojo中的實現。
flutter_dojo/category/backend/providerstate4widget.dart
實際上的操做就是在刷新和加載分頁數據這些操做的時候，讓shouldRebuild爲true，而當只修改Item數據的時候，讓shouldRebuild爲false，這樣就完整的控制了List的刷新範圍。
綜上
固然，這樣的處理只針對於對性能極致要求的場景，大部分狀況下，並不太須要考慮的這麼細，對List的Rebuild並不會產生多大的性能開銷，開發者須要針對不一樣的場景採用不一樣的方案，沒有必要太過嚴苛的控制刷新。
更多內容，請訪問 https://xuyisheng.top 點擊閱讀原文，一鍵直達
本文分享自微信公衆號 - Android羣英傳（android_heroes）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。