EventBus

01 前言 当我们进行项目开发的时候，往往是需要应用程序的各组件、组件与后台线程间进行通信，比如在子线程中进行请求数据，当数据请求完毕后通过Handler或者是广播通知UI，而两个Fragment之家可以通过Listener进行通信等等。当我们的项目越来越复杂，使用Intent、Handler、Broadcast进行模块间通信、模块与后台线程进行通信时，代码量大，而且高度耦合。现在就让我们来学习一下EventBus 3.0吧。 02 什么是EventBus EventBus源码详解 EventBus Github地址 进入官网，看看人家是怎么解释的： simplifies the communication between components decouples event senders and receivers performs well with Activities, Fragments, and background threads avoids complex and error-prone dependencies and life cycle issues makes your code simpler is fast is tiny (~50k jar) is proven in practice by apps with 100,000,000+

VUE中组件之间传值，总结来讲有三种情况，分别是：父组件对子组件、子组件对父组件以及兄弟组件之间传值以及调用。 一、父组件==>子组件 1.父组件传值给子组件 ，通过类似于属性绑定的方式，将需要传入子组件中的数据，绑定在子组件上，子组件通过props接收传入进来的数据。 父组件中内容 //在teamplate中调用此组件 < spList :keyword = "keyword" :activename = "active" >< /spList > //引入子组件 import spList from "../../components/sp_list.vue" ; components: { spList }, data () { return { active: "2" , keyword: '' , }; }, 子组件中内容 props: { keyword: String , activename: String , }, //或者 props: { "keyword" , "activename" }, 2.父组件调用子组件中的方法或数据 ，VUE官网中的描述：ref 被用来给元素或子组件注册引用信息。引用信息将会注册在父组件的 $refs 对象上。如果在普通的 DOM 元素上使用，引用指向的就是 DOM 元素；如果用在子组件上，引用就指向组件实例。 父组件中内容 /

在使用ApplicationEvent和Listener快速实现业务解耦中提到了用Spring提供的观察者设计模式完成系统内部逻辑解耦。本文将介绍Google-Guava中的一种消息发布-订阅类库——EventBus。 EventBus 是Google.Guava提供的消息发布-订阅类库，它实现了观察者设计模式，消息通知负责人通过EventBus去注册/注销观察者，最后由消息通知负责人给观察者发布消息。 前提：在pom.xml中引入guava包 < dependency > < groupId > com . google . guava < / groupId > < artifactId > guava < / artifactId > < version > 27.0 - jre < / version > < / dependency > 新建类: 相当于注册中心:注册执行都是通过这个类: import com . google . common . eventbus . EventBus ; public class EventBusCenter { private static EventBus eventBus = new EventBus ( ) ; private EventBusCenter ( ) { } public static EventBus

GitHub上最火的40个Android开源项目（一） GitHub上最火的40个Android开源项目（二） GitHub上最火的74个Android开源项目（三） GitHub上最火的40个iOS开源项目（一） GitHub上最火的40个iOS开源项目（二） 此前，推出的GitHub平台上“最受欢迎的开源项目”系列文章引发了许多读者的热议，在“GitHub上最火的40个Android开源项目 （一） 、 （二） 中，我们也相继盘点了40个GitHub上最受欢迎的Android开源项目。对于GitHub上如此众多的项目，有人不断Mark，有人分享自己的经验，有人心生“看得眼花缭乱，果然是需要终身学习的时代”的感慨，不管怎么样，如果能让你真的有所学习有所收获，我们的目的也就达到了。 今天我们将继续介绍GitHub上另外34个非常受欢迎的Android开源项目，在这些项目中，你又在用或用过哪些呢？ 41. android-swipelistview SwipeListView是一个Android List View实现，实现了自定义ListView单元格，可通过滑动来显示扩展面板。开发者可直接登陆Google Play下载安装其 Demo应用 。 42. greenDAO

EventBus: 创建EventBus实例： EventBus eventBus = new EventBus(); //或者 EventBus eventBus = new EventBus(TradeAccountEvent.class.getName());//带标识符,用于日志记录 订阅事件： 模拟一个交易过程。 事件类： /** * 事件类 */ public class TradeAccountEvent { private double amount; private Date tradeExecutionTime; private TradeType tradeType; private TradeAccount tradeAccount; public TradeAccountEvent(TradeAccount account, double amount, Date tradeExecutionTime, TradeType tradeType) { this.amount = amount; this.tradeExecutionTime = tradeExecutionTime; this.tradeAccount = account; this.tradeType = tradeType; } } /** * 购买事件 */ public class

废话很多的前言 EventBus,也即事件总线。在 wiki 上有关于Event Monitor的一个说法： Event monitoring makes use of a logical bus to transport event occurrences from sources to subscribers, where event sources signal event occurrences to all event subscribers and event subscribers receive event occurrences. 事件监听器通过逻辑总线来将发生的事件从发生源传输到订阅者。事件发生源在事件发生的时候能够发出信号给所有订阅者，订阅者则能够接收到发生的事件。 个人猜测事件总线这种说法源至于计算机内常用的几个总线结构【比如CPU总线，IO总线等】。他们有一个共同的特定就是负责传递某种 object 到指定的地方。比如数据总线负责的是CPU到RAM，地址总线负责的是RAM到RAM传递数据。 这条词条的分类是在操作系统这个目录下，这也可以理解成是在操作系统较早地使用了这种模式。 在Java内置的包中也有一种EventBus,但它是基于接口的。Google在Guava中实现了一套自己的 EventBus ,Google实现的总线库更具可读性

在常用的三层架构中，通常都是通过数据访问层来修改或者查询数据，一般修改和查询使用的是相同的实体。在一些业务逻辑简单的系统中可能没有什么问题，但是随着系统逻辑变得复杂，用户增多，这种设计就会出现一些性能问题。虽然在DB上可以做一些读写分离的设计，但在业务上如果在读写方面混合在一起的话，仍然会出现一些问题。 本文介绍了命令查询职责分离模式(Command Query Responsibility Segregation，CQRS)，该模式从业务上分离修改 (Command，增，删，改，会对系统状态进行修改)和查询（Query，查，不会对系统状态进行修改)的行为。从而使得逻辑更加清晰，便于对不同部分进行针对性的优化。文章首先简要介绍了传统的CRUD方式存在的问题，接着介绍了CQRS模式，最后以一个简单的在线日记系统演示了如何实现CQRS模式。要谈到读写操作，首先我们来看传统的CRUD的问题。 一 CRUD方式的问题 在以前的管理系统中，命令(Command，通常用来更新数据，操作DB)和查询(Query)通常使用的是在数据访问层中Repository中的实体对象(这些对象是对DB中表的映射)，这些实体有可能是SQLServer中的一行数据或者多个表。 通常对DB执行的增，删，改，查（CRUD）都是针对的系统的实体对象。如通过数据访问层获取数据，然后通过数据传输对象DTO传给表现层。或者

代码 添加依赖： implementation 'org.greenrobot:eventbus:3.0.0' 1 注册并声明订阅者，然后发布事件最后解除注册 @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); button = findViewById(R.id.bt); button.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { // 发送信息 EventBus.getDefault().postSticky(new MessageEvent("职业大坑",17,true)); } }); EventBus.getDefault().register(this); } @Subscribe(threadMode = ThreadMode.MAIN) public void show(MessageEvent event){ Toast.makeText(this, ""+event.getName()+":"+event

导入依赖： implementation 'com.squareup:otto:1.3.8' 1 定义一个类继承Bus，并且设置单列模式 注册和声明订阅者发送事件，最后解除注册与EventBus相同 EventBus与Otto的区别 Otto需要写一个类去继承Bus Otto需要写单列模式 --------------------- 来源： https://www.cnblogs.com/ly570/p/11329164.html

（如果对SPA概念不清楚的同学可以先自行了解相关概念） 平时喜欢做点小页面来玩玩，并且一直采用单页面应用（Single Page Application）的方式来进行开发。这种开发方式是在之前一年做的一个创业项目的经验和思考，一直想写篇博客来总结一下。 个人认为单页面应用的优势相当明显： 前后端职责分离，架构清晰：前端进行交互逻辑，后端负责数据处理。 前后端单独开发、单独测试。 良好的交互体验，前端进行的是局部渲染。避免了不必要的跳转和重复渲染。 当然，SPA也有它自身的缺点，例如不利于搜索引擎优化等等，这些问题也有其相应的解决方案。 下面要介绍的这种方式可以说是一种模式或者工作流，和前端使用什么框架无关，也和后端使用什么语言、数据库无关。不能说是The Best Practice，我相信经过更多人的讨论和思考会有A Better Practice。:) 概览 下图展示了这种模式的整个前后端及各自的主要组成： 看起来有点复杂，接下来会仔细地对上面每一个部分进行解释。看完本文，就应该能理解上图中的各部件之间的交互流程。 前端架构 把上图的前端部分单独抽出来进行研究： 前端中大致分为四种类型的模块： components：前端UI组件 services：前端数据缓存和操作层 databus：封装一系列Ajax操作，和后端进行数据交互的部件 common/utils：以上组件的共用部件