flutter中shared_preferences和sqflite的選用問題？

sqflite適用于需要排序，篩查數(shù)據(jù)的需求，是一個完整的數(shù)據(jù)庫。

創(chuàng)新互聯(lián)是一家專業(yè)的網(wǎng)站制作公司,提供的服務(wù)包括：成都品牌網(wǎng)站建設(shè),網(wǎng)站設(shè)計(jì),網(wǎng)頁設(shè)計(jì),我們是一家專業(yè)網(wǎng)絡(luò)公司,做網(wǎng)站，我們是認(rèn)真的。我們是成都網(wǎng)站制作,成都網(wǎng)站建設(shè)的先行者，一切以客戶的利益為設(shè)計(jì)方向，能夠?yàn)椴煌袠I(yè)的客戶提供全面、長期、深入的網(wǎng)絡(luò)解決方案。 創(chuàng)新互聯(lián)根據(jù)客戶的具體需求，提供從策劃、創(chuàng)意、制作、執(zhí)行等服務(wù)。

SP就是一個簡單的緩存，都是存在一個文檔里的，無法排序查詢和單獨(dú)更新數(shù)組的單個對象。

不過Flutter的SP并不好用，緩存的需求建議你使用local_cache_sync這個庫，比較易于使用。

[Flutter Package]類iOS使用方法的SectionTableView

此控件的package我已經(jīng)托管到了 pub倉庫

如果你被墻住了，也可以看 國內(nèi)鏡像

使用方式就是在你的flutter pubspec.yaml中添加依賴：

然后flutter packages get更新依賴即可

最近寫demo時(shí)發(fā)現(xiàn)Flutter自帶的ListView widget很簡陋，沒有分隔線，沒有section/row之分，也沒有sectionHeader，如果要實(shí)現(xiàn)一個有分割線，有section區(qū)分，有section header的ListView，耦合會非常嚴(yán)重：

在 上沒有找到封裝好的這種TableView，于是乎決定自己寫一個，命名為SectionTableView

本人是iOS開發(fā)，所以習(xí)慣了iOS上的UITableView的調(diào)用風(fēng)格，所以在實(shí)現(xiàn)flutter的SectionTableView時(shí)，決定實(shí)現(xiàn)如下功能

為了實(shí)現(xiàn)這些功能，并且方便后期增加滾動功能，上下拉刷新功能，使用了StatefulWidget作為父類：

接著在對應(yīng)的_SectionTableViewState中的build方法中，返回ListView：

熟悉flutter ListView的同學(xué)知道，ListView的builder類方法，有一個itemBuilder回調(diào)函數(shù)，參數(shù)是當(dāng)前的上下文，和將要渲染的行索引index，index對應(yīng)想要獲取的某一行控件(cell或者叫ListItem)，返回非空的組件就證明這個index有值，返回null就表示列表到盡頭了。

我們需要做的就是對index進(jìn)行映射，判斷當(dāng)前index對應(yīng)的控件，應(yīng)該是列表里的section header，還是分隔線devider，還是某一行的真正內(nèi)容cell。

出于性能的考慮，不可能每次調(diào)用 _buildCell的時(shí)候，都計(jì)算一遍index對應(yīng)的section和row的位置，所以定義了一個類成員變量indexPathSearch，是數(shù)組，數(shù)組長度就是ListView所有的行，當(dāng) _buildCell 的參數(shù)index大于等于indexPathSearch的長度的時(shí)候，就返回null，表示列表內(nèi)容到此為止了。

indexPathSearch里每一個元素，就是index對應(yīng)的section和row（稱為indexPath），index指向?qū)嶋H行(cell)的時(shí)候，section和row都是大于等于0的，當(dāng)section大于等于0，row==-1的時(shí)候，表示這里是一個section header，當(dāng)兩者都等于-1的時(shí)候，表示這里是一個分割線：

計(jì)算好了index到indexPath的映射，剩下的就好說了，在_buildCell中，提取indexPath并判斷indexPath的內(nèi)容，返回對應(yīng)的控件：

這是我的第一個flutter package，目前還很簡陋，flutter目前尚且如此，所以大家一起改善它，

下一步將優(yōu)化如下內(nèi)容：

如果大家喜歡，請多多star我的 項(xiàng)目GitHub

flutter 藍(lán)牙ble(blue tooth),同時(shí)連接多臺/多個設(shè)備

于是就有了寫作本文的動力，--------解決同時(shí)連接多臺藍(lán)牙設(shè)備!!!

flutter_blue 適合于單臺的藍(lán)牙設(shè)備，使用起來簡單

flutter_reactive_ble 適合于單臺的藍(lán)牙設(shè)備，多臺藍(lán)牙設(shè)備也可以用

flutter_ble_lib 適合于單臺的藍(lán)牙設(shè)備，多臺藍(lán)牙設(shè)備也可以用，可以在模擬器上進(jìn)行調(diào)試藍(lán)牙

感覺后2個第三方庫都可以使用，本人先入為主使用了flutter_reactive_ble，所以本文以flutter_reactive_ble為基礎(chǔ)進(jìn)行介紹

先聲明4個全局變量，后面會用到

開始掃描

如果掃描過程，不使用過濾條件，withServices這個參數(shù)可以給個空數(shù)組

停止掃描如下

連接設(shè)備

斷開設(shè)備,

每連接成功一個設(shè)備后，就會產(chǎn)生一個_connectionStreamSubscription，對應(yīng)設(shè)備的斷開，就用對應(yīng)的StreamSubscription去斷開， 可以用一個HashMap，去記錄 連接成功的設(shè)備 與 StreamSubscription 的對應(yīng)關(guān)系

去掃描服務(wù)，并過濾服務(wù)，掃描結(jié)果服務(wù)里面是包含有特征的數(shù)組,如： serviceId:[fff0,fff1,fff2,fff3,...]

去監(jiān)聽上報(bào)來的數(shù)據(jù),參數(shù)來自前面掃描到的結(jié)果serviceId--服務(wù)ID, characteristicId--特征ID，deviceId--設(shè)備ID

后面就是各位看官根據(jù)自己的需求去做邏輯處理啦。

對設(shè)備設(shè)置命令，發(fā)送請求(寫操作),list為整形數(shù)據(jù)，要寫的數(shù)據(jù)

讀取設(shè)備的信息（讀操作）

flutter 多臺藍(lán)牙設(shè)備同時(shí)連接的分享就到這里嘍，小伴們,覺得有點(diǎn)用的話，或者已經(jīng)看到這里面來的請點(diǎn)個贊吧~~ 后續(xù)分享更多有關(guān)flutter的文章。如果有疑問的話，請?jiān)谙路搅粞詞

過一段時(shí)間后,我在項(xiàng)目把這個藍(lán)牙庫用起來了,基本能滿足日常需求.效果如下:

flutter 字符串 與 整形數(shù)組 互相轉(zhuǎn)換 （字符與ASCII值互轉(zhuǎn)）

整形數(shù)組Listint轉(zhuǎn)為字符串

字符串轉(zhuǎn)整形數(shù)組Listint

字符 -------ASCII值

A --------65

B --------66

C --------67

D --------68

Flutter CustomScrollView 自定義滑動效果

基本和AppBar一樣,只是他只能在CustomScrollView中使用,應(yīng)該很常見,滑動的時(shí)候固定appbar,就需要用到他.

大部分和appbar一樣,主要說下重要的幾個:

是否將導(dǎo)航欄部分固定在appbar的位置.這個需求在實(shí)際中很常用. 看看效果圖.

當(dāng) pinned = false:

可以看到appbar并沒有固定在最上面,而是根據(jù)內(nèi)容劃出了界面.

當(dāng) pinned = true :

這個應(yīng)該是需求中經(jīng)常用到的效果了.

當(dāng)floating = false :

當(dāng)floating = true:

仔細(xì)看 ，區(qū)別是在列表整體向下滑動時(shí),appbar開始顯示的位置不同.

當(dāng)為false時(shí) ,向下滑動時(shí),會先降列表內(nèi)容滑動頂部,然后appbar會跟著列表滑動顯示出來.如上圖

當(dāng)為true時(shí), 向下滑動時(shí),appbar會先跟著列表滑動顯示出來. 然后繼續(xù)列表的滑動. 如上圖

不能單獨(dú)使用要配合 ****floating 和 ****pinned

具體效果看官網(wǎng)地址

是否展開,默認(rèn)false,直接看值為true的效果圖,就明白了.

可以再里面添加擴(kuò)展的內(nèi)容:

通過測試發(fā)現(xiàn) **后面不是 FlexibleSpaceBar 的話, stretch = true 無效. **

和Padding一樣.子控件是 sliver 類型...

上圖中在padding中添加了一個背景色為青色的容器widget

里面可以設(shè)置不是 sliver 類型的widget。如上圖中的 padding中添加的 container

就兩個協(xié)議,一個是布局協(xié)議一個展示協(xié)議.基本和GridView一樣.也有count和extext... 不設(shè)置個數(shù)默認(rèn)無數(shù)個

SliverChildListDelegate 這種方式前提是知道cell個數(shù)，比較少，好搭建

SliverChildBuilderDelegate 這種方式，可以根據(jù)數(shù)組去創(chuàng)建，不知道cell個數(shù)

和listview差不多.也是協(xié)議 不設(shè)置個數(shù)默認(rèn)無數(shù)個

關(guān)于flutter NestedScrollView導(dǎo)致其body的tabbarview的多個list同步滾動的解決方案

講道理我起的好長的名字啊，不過文如上題，搜索到這里的兄弟應(yīng)該都知道我說的是啥情況，正好

～～

我這個方案可能有點(diǎn)笨拙TT，不過自測有效，有其它想法的老哥希望可以幫忙指點(diǎn)一下～

下面進(jìn)入正題

點(diǎn)進(jìn)源碼里面看，可以發(fā)現(xiàn)他直接繼承了StatelessWidget，那我們就直接看看build方法

可以看到，這里直接返回一個scrollable或者一個子節(jié)點(diǎn)是scrollable的InheritedWidget

scrollable是一個StatefulWidget，那我們就看看它的state

首先scrollable持有一個scrollposition對象，是通過其scrollcontroller構(gòu)建的

在其state的setCanDrag方法中，對其拖動設(shè)置了一系列的監(jiān)聽

這里就可以看出來，當(dāng)拖動觸發(fā)時(shí)，就會通過當(dāng)前scrollable的position生成一個Drag/Hold對象，并調(diào)用相應(yīng)的方法 這個position有幾個子類，我們先隨便看一個實(shí)現(xiàn)

可以看到生成了一個ScrollDragController對象，當(dāng)手勢拖動而調(diào)用這個對象的update方法時(shí)

可以看到直接調(diào)用其委托對象的applyUserOffset方法進(jìn)行偏移，而這個委托對象根據(jù)剛才的drag方法可以得知正是我們scrollable中的position

最后，由position通知其scrollcontext，也就是之前的scrollable進(jìn)行滑動

具體的滑動流程這里就不細(xì)說了，我們只是要知道這個事件是怎么傳遞的就好了，有興趣的老哥可以自行分析

NestedScrollView是一個statefulwidget，那我們就先看看它的build方法

先忽略其他奇奇怪怪的方法，我們發(fā)現(xiàn)在我們body的外面，包裹了一層PrimaryScrollController，同時(shí)它還持有innerController，這個innerController暫時(shí)先不管它是啥

還記不記得在最開始ScrollView的build方法中，生成Scrollable的時(shí)候，我們已經(jīng)見過這個PrimaryScrollController了，再回顧一下

再看看PrimaryScrollController.of(context)

可以看到，在生成scrollable的時(shí)候，在primary = true的情況下是會向上查找的，看看有沒有PrimaryScrollController，如果有的話，scrollable使用的controller實(shí)際就是nestedscrollview中的innerController了

而之前看過了，scrollable中的position就是scrollcontroller來生成的，那么在這種情況下：

實(shí)際上是生成了_NestedScrollPosition并返回給了body中的scrollable

構(gòu)造方法中有一個參數(shù)coordinator 暫時(shí)先不管

好了，下面我們在回頭看剛才NestedScrollView的build方法，實(shí)際上是生成了一個_NestedScrollViewCustomScrollView，繼承自大名鼎鼎的CustomScrollView，它當(dāng)然也是scrollview啦，而我們傳給它的controller也是一個_NestedScrollController，不過叫做_outerController，和body中的不是同一個罷了，那么自然這個父scrollview的position也是_NestedScrollPosition。

下面我們按照之前的邏輯，當(dāng)拖動開始時(shí)，就會調(diào)用position.drag方法

可以看到，實(shí)際上吧方法交給了我們之前多次見到的coordinator來完成，那我們就簡單看一下吧

這里可以看到，他把返回的ScrollDragController的委托者設(shè)成了自己

那么自然在拖動的時(shí)候，調(diào)用的就是coordinator的applyUseroffset方法了 我們分析一下

可以看到，在需要子列表滾動時(shí)，是對innerPositions中的所有position調(diào)用滑動方法的

而這innerPositions中的position是怎么來的呢？跟蹤一下可以發(fā)現(xiàn)是在調(diào)用NestedScrollController的attach時(shí)添加進(jìn)來的，如下

因?yàn)橹拔覀兛吹竭^，子scrollable中的controller就是這個NestedScrollController，所以在updateopsition時(shí)會把舊的detach調(diào)，把新生成的position attach進(jìn)來

另外，在dispose中也會detach

由此我們就知道啦，因?yàn)殚_啟了緩存后就不會調(diào)用劃出屏幕的頁面的dispose，自然所有子scrollable的position都存在nestedScrollController里面了，當(dāng)發(fā)生滑動時(shí)，遍歷調(diào)用positions數(shù)組，就導(dǎo)致屏幕外的列表也跟著滑動了～

既然開啟了緩存，手動dispose肯定是沒啥意義的，實(shí)際上我們只要在頁面切換過后把未顯示的position 給detach掉就好了。

然鵝，因?yàn)閒lutter不支持反射，子布局傳遞的position我們拿不到，nestedScrollController我們也不能直接拿到=。=

不過有一個對象我們之前見到過，scrollable就是通過他獲取controller的，而position則是傳給了獲取到的controller 就是PrimaryScrollController了，所以我打算在中間第三者插足，對傳遞Position的PrimaryScrollController進(jìn)行Hook

在使用的時(shí)候把子列表添加進(jìn)去，并設(shè)置對應(yīng)的GlobalKey。

然后監(jiān)聽Tab切換

以上是我的方案，有問題的話還希望老哥幫忙指正，也希望有其他思路的老哥指點(diǎn)一下～～

上一下Github項(xiàng)目地址 用Flutter寫的WanAndroid 其中用到了這個方案

= =

3