Flutter_定义控件StatefulWidgets和StatelessWidget

Stateful（有状态） 和 stateless（无状态） widgets

创新互联专注为客户提供全方位的互联网综合服务，包含不限于网站建设、做网站、尼河口网络推广、小程序设计、尼河口网络营销、尼河口企业策划、尼河口品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；创新互联为所有大学生创业者提供尼河口建站搭建服务，24小时服务热线：028-86922220，官方网址：www.cdcxhl.com

stateless widget 没有内部状态. Icon、 IconButton, 和Text 都是无状态widget, 他们都是 StatelessWidget的子类。

stateful widget 是动态的. 用户可以和其交互 (例如输入一个表单、 或者移动一个slider滑块),或者可以随时间改变 (也许是数据改变导致的UI更新). Checkbox, Radio, Slider, InkWell, Form, and TextField 都是 stateful widgets, 他们都是 StatefulWidget的子类。

StatefulWidget类

具有可变状态的小部件。

状态是（1）在构建窗口小部件时可以同步读取的信息，以及（2）在窗口小部件的生命周期内可能会更改的信息。这是小工具实施者的责任，以确保国家的及时通知当这种状态的改变，使用State.setState。

有状态窗口小部件是一个窗口小部件，它通过构建一个更具体地描述用户界面的其他窗口小部件来描述用户界面的一部分。构建过程以递归方式继续，直到用户界面的描述完全具体（例如，完全由RenderObjectWidget组成，其描述具体的RenderObject）。

当您描述的用户界面部分可以动态更改时（例如由于具有内部时钟驱动状态或依赖于某些系统状态），状态窗口小部件非常有用。对于仅依赖于对象本身中的配置信息以及窗口小部件膨胀的 BuildContext的组合，请考虑使用 StatelessWidget。

StatefulWidget实例本身是不可变的，并且将它们的可变状态存储在由createState方法创建的单独State对象中 ，或者存储在State订阅的对象中，例如Stream或ChangeNotifier对象，其引用存储在StatefulWidget的最终字段中本身。

框架在膨胀StatefulWidget时 调用createState，这意味着如果该窗口小部件已插入到多个位置的树中，则多个State对象可能与同一StatefulWidget关联。同样，如果StatefulWidget从树中移除，后来在树再次插入时，框架将调用createState再创建一个新的国家目标，简化的生命周期状态的对象。

如果StatefulWidget的创建者使用GlobalKey作为其 键，则StatefulWidget在从树中的一个位置移动到另一个位置时保持相同的State对象。由于具有GlobalKey的窗口小部件可以在树中的至多一个位置使用，因此使用GlobalKey的窗口小部件最多只有一个关联元素。当通过将与该窗口小部件关联的（唯一）子树从旧位置移植到新位置（而不是在该位置重新创建子树）时，框架利用此属性将全局键从树中的一个位置移动到另一个位置时利用此属性。新的位置）。与StatefulWidget关联的State对象与子树的其余部分一起被移植，这意味着State对象在新位置被重用（而不是被重新创建）。但是，为了有资格进行嫁接，必须将窗口小部件插入到从旧位置移除它的同一动画帧中的新位置。

StatefulWidget有两个主要类别。

首先是其中一个分配资源State.initState并在他们的处置State.dispose，但不依赖于InheritedWidget S或致电State.setState。这些小部件通常在应用程序或页面的根目录中使用，并通过ChangeNotifier， Stream或其他此类对象与子小部件进行通信。遵循这种模式的有状态小部件相对便宜（就CPU和GPU周期而言），因为它们构建一次然后永不更新。因此，它们可能有一些复杂和深刻的构建方法。

第二类是使用State.setState或依赖于 InheritedWidget的小部件。这些通常会在应用程序的生命周期内重建多次，因此最小化重建此类窗口小部件的影响非常重要。（他们也可以使用State.initState或 State.didChangeDependencies并分配资源，但重要的是他们重建。）

可以使用几种技术来最小化重建有状态窗口小部件的影响：

StatelessWidget类

一个不需要可变状态的小部件。

无状态窗口小部件是一个窗口小部件，它通过构建一个更具体地描述用户界面的其他窗口小部件来描述用户界面的一部分。构建过程以递归方式继续，直到用户界面的描述完全具体（例如，完全由RenderObjectWidget组成，其描述具体的RenderObject）。

当您描述的用户界面部分不依赖于对象本身的配置信息以及窗口小部件膨胀的BuildContext时，无状态窗口小部件非常有用。对于可以动态更改的组合，例如由于具有内部时钟驱动状态或依赖于某些系统状态，请考虑使用StatefulWidget。

无状态窗口小部件的构建方法通常仅在以下三种情况下调用：第一次将窗口小部件插入树中，窗口小部件的父窗口更改其配置时，以及何时依赖于更改的InheritedWidget。

如果窗口小部件的父级将定期更改窗口小部件的配置，或者它依赖于经常更改的继承窗口小部件，则优化构建方法的性能以保持流畅的呈现性能非常重要。

可以使用几种技术来最小化重建无状态窗口小部件的影响：

做混合的话Uniapp和Flutter我应该学哪个啊？

Uniapp目前比较成熟，而且用的是Vue语法，学习成本比较低，而且行业里面用的也比较广泛，而Flutter的话，学习成本略高，因为要学习新的语言，还有就是目前生态不是特别完备，等他再发展发展吧。黑马程序员官网有成套免费视频哦，有什么不懂的可以直接过去学习。您的采纳是对我成长的鞭策

flutter如何自定义一个controller

最近在写一个flutter-ui库，类似于antd一样的ui库，google了很久，都没有发现一个类似antd这种国人喜欢用的ui库，大部分都是国外的那种material ui,因为公司多个flutter项目都需要用，每次都是写好几遍，而且还很难维护所以才有了这个打算，第一个要写的ui组件就是日历组件，日历的ui以及数据，都已经写完了，目前正好需要给日历写控制器，所以才有了这篇文章

在无状态组件当中，组件的ui由传入它的参数决定的，组件本身的不需要管理状态。而有状态组件会有多种状态，而它的状态是可以通过外部控制器来控制的。比如TextField，创建一个controller可以给TextField赋值初始值，也可以通过controller来获取到变化之后的value值，而这个控制器就是controller。可以用来控制一个有状态组件的行为以及状态的一个类

为什么要用controller呢，起初我也没想明白为什么要用，因为传参数也可以解决类似的问题啊，就拿TextField来说，

但后来我发现，很多组件内部的行为是没办法通过传参数来控制的，尤其是在特殊的组件生命周期中，没办法实现，而通过controller，可以很好的解决这个问题，我自己感觉，controller的用处就是提供给外部操作当前组件的能力，包括组件的各种状态，以及组件的各种行为，这里举个栗子????

综上，个人理解controller的作用就是暴露组件内部的行为，属性给父元素，使父元素可以很方便使用子元素提供的参数，而不需要去实现监听事件来获取

回到正题，那么如何实现一个自己的controller呢，对我而言，不会就抄，抄谁的呢，当然是超官方的！读官方的源码，看它如何实现，然后我们加以模仿，不就是自己的了。窃书不能算偷……窃书！……读书人的事，能算偷么？

这里借鉴了ScrollController的源码，首先分析下源码，以下是ScrollerController的源码，我把看不懂的英文注释删掉了...本菜????看不懂就删

看了看好像也没多少东西，注意当前类的定义

是继承了ChangeNotifier类，看着这个类顿时觉得好眼熟有没有，对了，不就是我们平时写provider用的那个东东嘛，查阅了官方文档，具体是这么解释的

用我这渣渣英语翻译大概的意思就是，一个类，它可以被继承，它可以被混合并且它提供了使用VoidCallback进行通知的 notification Api

盲猜和provider用法差不多，都是观察者模式模式，父组件可以订阅该controller的更改，当该controller通知其他监听器的时候，监听器的回调函数将被执行，上面ScrollController中的attach中正好也使用了notification方法来通知监听者，具体滚动执行的过程没有看到，但是大致了解了controller的工作原理

好了，知道原理了，开搞

首先得思考，这个controller会提供什么，按照我当前给日历组件的设计，目前会给外部提供当前日历所有的行为事件以及最终的值

目前我写的controller很简单，只需要给外部父容器提供上一个月，下一个月的方法可以使用就可以，所以我的控制器很简单，只有两个方法，并且方法执行完成之后进行消息通知，通知到各个订阅者，也就是这里的日期组件 在日期组件的 initState方法中，对controller进行监听，从而改变ui

最外层父容器是这样的，当前demo用setState临时刷新ui

看起来还不错，还有一些ui上的交互需要后续去调整

未完待续...

最近入了flutter的坑，就想着做一行爱一行，也不能把自己的头衔写死了就只做前端，只写页面。flutter写起来也蛮舒服的，加油，打工人！

Flutter iOS 苹果IAP(内购)实现步骤及问题总结(全网最全)

点击 “协议、税务和银行业务”

内购用的是付费应用程序，先签署《付费应用程序协议》，同意后状态变更为“用户信息待处理”，等待审核。

状态更改完毕后，点击“开始设置税务、银行业务和联系信息”。

（1）添加银行账户,按照要求填写相关内容即可。

（2）选择报税表，并填写。所有与 Apple 有商业合作者必选都是美国，若有其他需求，可以多选。

继续填写，首先认证公司基本信息，选择所有人类型，确认无误后认证条款处打对勾

Part I 部分，继续核对公司相关信息，选填内容可不填。

Part III 部分，签署税务条约，设置利益限制条款的种类，选填内容可不填。此部分如果需要可勾选上下图勾选框，不需要可不勾选，我们这个项目没有用到part III 部分,所以没有勾选。

Part XXX 部分，确认之前填写的信息，勾选完毕后，提交

（3）填写联系信息，共5个。高级管理、财务、技术、法务、营销。只需要提供5个人的基本信息即可。

只可使用一次的产品，使用之后即失效，必须再次购买。

示例： 钓鱼 App 中的鱼食。

只需购买一次，不会过期或随着使用而减少的产品。

示例： 游戏 App 的赛道。

允许用户在固定时间段内购买动态内容的产品。除非用户选择取消，否则此类订阅会自动续期。

示例： 每月订阅提供流媒体服务的 App。

允许用户购买有时限性服务的产品。此 App 内购买项目的内容可以是静态的。此类订阅不会自动续期。

示例： 为期一年的已归档文章目录订阅。

App 内购买项目的截屏，即所售项目的示意图。例如，如果 App 内购买项目是一本图书，您可以提交图书的截屏。您也可以提交购买页的截屏。该截屏仅用于 Apple 审核，不会在 App Store 中显示。

截屏要求如下：

iOS 至少需要 640 x 920 像素

Apple tvOS 需要 1920 x 1080 像素

macOS 需要 1280 x 800 像素

App 审核图像上传后，可以替换，但无法移除。当您的 App 内购买项目处于审核中时，您无法更新截屏。

沙箱账号是不能直接在App Store进行登录的，只能在点击了购买商品之后，在弹出的登录框进行登录 。

验证是否已登录沙箱测试账号：

设置--iTunes Store与App Store，页面拉到最底部，会看到沙箱账户项会列出你已登录的沙箱测试账号！

操作方法一：打开App Store应用首页滑到最下方--选中AppleID--注销

操作方法二：设置--iTunes Store与App Store--选中AppleID--注销

checks if the client can make payments(检测App是否能支付)

getAvailablePurchases

Get all non-consumed purchases 获取未消费的商品

打印信息查询；

原因：

没有先执行getProducts，直接执行requestPurchase方法,要先拉取商品列表，再执行购买操作.

问题描述；

1.漏单必须要处理，玩家花RMB购买的东西却丢失了，是绝对不能容忍的。所谓的漏单就是玩家已经正常付费，却没有拿到该拿的道具。

解决：只要购买成功，便将购买记录(receipt等账单信息)保存下来，然后将账单信息传送给我们游戏服务器，游戏服务器获得账单后，和苹果服务器验证，账单有效的话，回馈给游戏服务器处理，游戏服务器处理后，返回给游戏客户端处理，处理完毕，将本地保存的购买记录删除。

官方文档：向苹果校验支付凭证

21000 App Store无法读取你提供的JSON数据

21002 收据数据不符合格式

21003 收据无法被验证

21004 你提供的共享密钥和账户的共享密钥不一致

21005 收据服务器当前不可用

21006 收据是有效的，但订阅服务已经过期。当收到这个信息时，解码后的收据信息也包含在返回内容中

21007 收据信息是测试用（sandbox），但却被发送到产品环境中验证 【请求sandbox校验支付凭证】

21008 收据信息是产品环境中使用，但却被发送到测试环境中验证

消耗类型： 例如：金币、道具等。

非续订订阅： non-renewable subscription 例如：VIP

您的首个 App 内购买项目必须以新的 App 版本提交。请创建您的 App 内购买项目，然后前往 App 的“App Store”页，从“App 内购买项目”中进行选择，点按“提交”。 了解更多

在上传二进制文件并提交首个 App 内购买项目以供审核后，您可以使用下表提交其他 App 内购买项目。

唐巧-iOS应用内付费(IAP)开发步骤列表

未完~待续

当使用内购购买过商品之后没有把这个交易关闭，所以再次去购买商品后就会调用以前已经购买成功的交易去购买因为已经购买过，才会有这个提示

原因：添加内购项目时，信息填写不完整，app审核图像未上传

处理方法：上传app审核图片( 合适的尺寸 )，点击提交，状态改为正在准备审核中。

这个是内购选择类型不匹配原因导致。

购买成功之后，Apple会返回以下四个数据给应用

Reference

Review the updated Paid Applications Schedule.

游客身份解决方案：即不登录也要能购买

1）服务器端做一个苹果审核机制，审核期间游客身份可以进行一切行为，一旦审核通过，修改服务端即可达到强制用户登录进行内购买的目的（这个有点。。。）

2）游客可以进行内购买，购买时以设备UUID为准，生成一个游客账号，将购买信息保存在服务器和本地，当用户登录正式账户后判断此设备是否进行过内购，有的话提示用户将游客身份购买的权益与现有账号绑定，如果绑定，游客权益则迁移到正式账户，如果不迁移，则游客身份和正是账户是两个独立账户，正式账户不享有游客身份的权益（我用的这个）

内购游客模式解决方案

iOS内购规则

flutter provider的理解

provider 是flutter 中的状态管理 开源库;

存储的数据对象 必须extends ChangeNotifier；下层widget 通过 Provider.of(context) 函数 获取model对象 ,并且可以建立依赖关系；当数据对象发生变化时，依赖的widget 会重新build，像不像InheritedWidget Provider 没错 下层widget就是 封装了InheritedWidget

主要 通过 Provider.ofT(context) 函数，来获取；

推荐使用 Provider.of而不是 Consumer,因为 listen默认为true,也就是说 默认 依赖于 持有数据model的widget 对应的element;

数据类 可继承的 ChangeNotifier,本身和privider框架 没有关系；

ChangeNotifier 是 flutter框架 提供的工具类， 用来实现一对多的订阅通知功能。

Flutter了解之手势

描述了屏幕上指针（触摸、鼠标、触控笔）的位置和移动。

Flutter中可以使用Listener(功能性组件)来监听原始触摸事件

例1

例2

例3

忽略PointerEvent

手势: 描述由一个或多个指针移动组成的语义动作，如拖动、缩放、双击等。

Material大多数widget已经对tap或手势做出了响应。 例如 IconButton和 FlatButton 响应单击，ListView响应滑动事件触发滚动。

用于手势识别的功能性组件，通过它可以来识别各种手势。

例（单击）

例（添加Material触摸水波效果 InkWell组件）

例（滑动关闭 Dismissable组件）

例（单击、双击、长按）

例（滑动）

例（扫动---单一方向）

例（缩放）

GestureRecognizer是一个抽象类。

一种手势的识别器对应一个GestureRecognizer的子类。

例

由于手势竞争最终只有一个胜出者，所以，当有多个手势识别器时，可能会产生冲突。

例

例

在APP中经常会需要一个广播机制，用以跨页面通知。比如一个需要登录的APP中，页面会关注用户登录或注销事件，来进行一些状态更新。

这时候，一个事件总线便会非常有用，事件总线通常实现了订阅者模式，订阅者模式包含发布者和订阅者两种角色，可以通过事件总线来触发事件和监听事件。

对于一些简单的应用，事件总线是足以满足业务需求的，如果决定使用状态管理包的话，一定要想清楚APP是否真的有必要使用它，防止“化简为繁”、过度设计。

例

在widget树中，每一个节点都可以分发通知，通知会沿着当前节点向上传递，所有父节点都可以通过NotificationListener来监听通知。

Flutter中将这种由子向父的传递通知的机制称为通知冒泡（Notification Bubbling）。

通知冒泡和用户触摸事件冒泡是相似的，但有一点不同：通知冒泡可以中止，但用户触摸事件不行。

通知冒泡和Web开发中浏览器事件冒泡原理是相似的，都是事件从出发源逐层向上传递，可以在上层节点任意位置来监听通知/事件，也可以终止冒泡过程，终止冒泡后，通知将不会再向上传递。

Flutter的UI框架实现中，除了在可滚动组件在滚动过程中会发出ScrollNotification之外，还有一些其它的通知，如SizeChangedLayoutNotification、KeepAliveNotification 、LayoutChangedNotification等，Flutter正是通过这种通知机制来使父元素可以在一些特定时机来做一些事情。

例

例

例

阻止冒泡

通知冒泡原理

标题名称：flutter订阅者,flutterguan方文档
标题路径：http://ybzwz.com/article/dsehooh.html