Categories
未分类

RxJava源码分析(一):Observable的几种创建方式

相信写Android的,写Java的人应该都听说过RxJava这个革命性的东西了,很多人也了解这个东西怎么使用。网上也有很多优秀的介绍性的文章,如果你还不了解这个东西,或者是不熟悉它的用法的话,我会建议先看这个系列的文章,然后再看这篇。尤其是后者绝对强烈推荐,其实我个人对RxJava的看法,刚开始只是觉得这个东西写起来语法非常简洁,非常优雅,可以在很大程度上面减少一些外部变量的使用,非常Functional。但是等到我看了那篇文章以后,我才发现,我只是发挥了RxJava不到一成的功力,获得了它不到一成的优点。它还有那么强大的力量,隐藏在冰山水下。另外,国内也有广受好评的扔物线写的给Android开发者的RxJava详解。这些足够让你对RxJava有一个比较深入的了解,此外,扔物线的文章也有一定程度的原理讲解和源码分析,可谓真正的深入浅出。 Anyway,这里我们就不介绍RxJava的用法和特点了,我们简单看看它的源代码。 先看第一部分,Observable的创建。现在大部分介绍RxJava的文章、尤其是介绍RxJava在Android上面的使用的文章,都往往会结合第三方的library,比如Retrofit。里面介绍Observable的使用方式是通过Retrofit的返回结果来获得一个Observable,再操作这个Observable。这容易给我们一种错觉,就好像我们自己从来不用,也不能创建Observable一样。然后其实不是这样的,我们完全可以自己创建Observable。常见的创建Observable的方式有以下几种: Observable.just(…) 比如: Observable.just("xiaochuang"); //Create an Observable that has only one item: "xiaochuang" Observable.just("xiaochuang", "handsome"); //Create an Observable that has 2 items: "xiaochuang" and "handsome" Observable.just("xiaochuang", "is", "handsome"); //Create an Observable that has 3 items: "xiaochuang", "is" and "handsome" //…you can pass in up to 10 items Observable.from(an_array_or_iterable); 比如: Observable.from(new String[]{"xiaochuang", "is", "handsome"}); […]

Categories
未分类

《Working Effectively with Legacy Code》阅读分享(一)

端午节开始看这本编程领域经典的书《Working Effectively with Legacy Code》,中文版叫《修改代码的艺术》。英文原版豆瓣评分9分,中文版8.2分。Amazon.com评分9.2分。 从评分上看,这是一本质量非常不错的书。中文版的书名翻译虽然少了点感觉,多了点俗气——现在书名动不动什么什么艺术,什么什么之道,甚至什么什么之禅,真是让人不知道该作何感想。但应该说,这个书名翻译得还是很准确的。因为这本书讲的就是如何修改代码! 书的开篇讲了修改代码的四种原因: Adding a feature Fixing a bug Improving the design Optimising resource usage 对于前两种原因来说,改代码自然是理直气壮,没什么可以商量的余地。然而,对于后两种原因,通常就不是那么肯定了,甚至还有种policy叫做“If it’s not broke, don’t fix it”。这种policy之所以会出现,自然是有它的原因的。最大的原因,往往不是因为改代码需要时间,而是因为更改是有风险的,这种风险就是,你不知道你的更改是不是对的,更要命的是,你不知道你的更改会影响到其它的什么地方,会后带来什么后果。出于这种恐惧的心理,我们往往倾向于不到非不得已,就不去改代码。而这里所说的非不得已,就是添加feature和fix bugs。 然而遗憾的是,这种policy被一次又一次的证明,是行不通的,因为很快你会发现,你的每个类会写得越来越大,每个方法越来越长,结构越来越复杂,越来越难以理解,每次加一个新feature,fix一个bug都越来越困难。于是到了某个点,所有东西都必须推倒重写。这种事情在历史上发生了一次又一次。那怕不会到那一步,烂代码和烂结构也会严重的拖后正常的工作进程。 这种结局是应该被避免的,也是可以被避免的,怎么避免?那就是不要只顾着add feature和fix bugs,也要及时的“Improve the design”,也就是传说中的重构。但是话说回来,重构就会有上面提到的那些风险,说得更具体点,我们需要解决好以下三个问题: What changes do we have to make? How will we know that we’ve done them correctly? How will we know that we […]

Categories
未分类

关于安卓单元测试,你需要知道的一切

单元测试是个技术活,它有自己的一套知识体系,要做好单元测试,的确是需要学习和不断的在实践中练习的。好消息是,这套知识体系的范围相对来说是有限的,因此,只要耐心的学习和练习一段时间,就可以做好日常大多数的需求。然后国内这大环境和氛围,大家都清楚,大部分时候大家都在赶feature,赶上线,以至于单元测试这件事情,往往被忽略,甚至从来没考虑过,而这一点在移动开发上面则更加严重。这导致的结果就是,网上很难找到比较系统的关于单元测试各个方面的文章。这就让有些童鞋那怕有做单元测试的想法,却不知道从何下手,因此导致一个恶性循环。 出于这点原因,我根据自己的一些经验和想法,写了一个系列的文章,至此为止写了7篇,然而经常发现有朋友对前面的一些概念不是很清楚,从网站或公众号找之前的一些文章又不是很方便,因此整理了这样一篇汇总性的文章,希望能让大家对此有个更整体化的了解,如果某一方面的东西不是很清楚,也能很快找到参考。 以下文章是这个系列文章的总结。 什么是单元测试:介绍了什么是单元测试,里面澄清了一个最常见的误解,同时介绍了有返回值和没有返回值两种不同的函数——对于OO来说,应该叫“方法”,但是中文里面“方法”这个词太容易产生误解了,因此我这里用函数来代替,这就是翻译尴尬的地方。所以很多时候我建议不如直接用英文单词本身,而不是非要硬生生翻译过来。 为什么要做单元测试:对于什么要做单元测试的个人之见。 JUnit单元测试框架的使用:介绍了题目中说的内容,JUnit是最基础的一个单元测试框架。 Mock以及Mockito的使用:mock自古以来就是单元测试不可分割的一部分,这篇介绍了mock的概念和使用。 依赖注入,将mock方便的用起来:为了将mock更方便简洁优雅的用起来,我们需要用到依赖注入。这篇文章介绍了依赖注入的概念和使用。 使用dagger2来做依赖注入,以及在单元测试中的应用:上一篇文章讲了依赖注入,而Dagger2能让我们易如反掌的使用依赖注入的模式,代码的耦合度变得非常低。 Robolectric,在JVM上调用安卓的类:解决在JVM上做单元测试的时候,无法调用和测试安卓的类的问题。 其它的一些文章: Android单元测试在蘑菇街支付金融部门的实践:这个是在InfoQ的移动前线学习分享群里面作的一个分享,首发于”移动开发前线”公众号,也在InfoQ网站上发表过,讲了的单元测试在蘑菇街支付金融部门的实践。 MDay上的分享-关于安卓单元测试的一切:这是在MDay第五季作的一次分享,有PPT和视频,不过视频暂时还没有公开,如果公开了会第一时间更新过来。 安卓单元测试是不是只有这些东西?当然不是,只不过,主要的概念和框架都在这了。剩下的相对来说更多是一些具体的技巧、解决某个具体问题的方法等等。对于这些东西,以后也会有文章介绍,敬请关注。 最后,如果你对安卓单元测试感兴趣,欢迎加入我们的交流群,因为群成员超过100人,没办法扫码加入,请关注下方公众号获取加入方法。 以上,希望能帮助到你。如果觉得有用,请分享一下,以便帮助到其它人。分享是一种美德,这也是我坚持写作的初衷。 (如果提示群满了,请关注一下公众号,在公众号的菜单有加入方法)

Categories
未分类

Android单元测试(七):Robolectric,在JVM上调用安卓的类

今天讲讲Android上做单元测试的最后一个难点,那就是在JVM上无法调用安卓相关的类,不然的话,会报类似于下的错误: java.lang.RuntimeException: Method isEmpty in android.text.TextUtils not mocked. 关于这个话题,其实我以前是写过的,也许今天我回过头来写这个话题,会采用不一样的形式,不一样的心态来写,然而,作为我写过的第一篇关于单元测试的文章,而且看看时间,是去年的6月15号,再过几天,刚好一周年。想想这篇文章是在我刚开始探索,尝试在安卓上面写单元测试的时候,写的一篇文章,如今因为安卓单元测试的原因,我认识了很多同行,甚至不时有人叫我“大牛大神”之类的,虽然知道大家是客气,我也受之有愧,但怎么滴心里也有点虚荣的开心,哈哈哈。。因此现在回过头去看看当时自己写的东西,不禁觉得有点那啥。。。因此,我决定把之前的文章稍作补充和修改,作为这个系列的第七篇。 ———————-以下文字写于去年今天———————– 作为一只本科非计算机专业的程序猿,手动写单元测试是我从来没接触过的东西,甚至在几个月前,我都不知道单元测试是什么东西。倒不是说没听过这个词,也不是不知道它的大概是什么东西——“用来测试一个方法,或者是一小块代码的测试代码”。然而真正是怎么做的?我并没有一个概念,或者说并没有一个感觉。 记得第一份工作在创新工场的时候,听当时的boss说,公司有个神级的程序员,他会写大量的单元测试,甚至50%以上的代码都是单元测试。当时崇拜之极,却仍然觉得写单元测试是很麻烦的一件事情。 扯远了,话说回来,当你接触多了国外的技术博客,视频之后,你会发现,单元测试甚至TDD,在国外是非常流行的事情。很多人甚至说离开了单元测试,他们便没有办法写代码。这些都让我对单元测试的好感度逐渐的上升。然而,真正让我下定决心,一定要研究一下这个东西的,是前段时间看大名鼎鼎的《重构:改善现有代码的艺术》里面的一段话: I’ve found that writing good tests greatly speeds my programming, even if I’m not refactoring. This was a surprise for me, and it is counterintuitive for many programmers… –Martin Fowler 《Refactoring: Improving the Design of Existing Code》 是的,你没看错,他说单元测试可以节约时间,提高开发速度!!!身为一个无可救药的懒癌患者,看了这句话简直就像看到了一道神光似的!既然都可以节省时间,那肯定是要看看的啊! 有趣的是,Martin Fowler在《重构》里面说他最初是因为 Dave Thomas说的一句话,让他走上了单元测试的不归路。而我这几天刚好又在看Dave […]