AndroidX 测试坑点详解(二)—— VectorDrawable 和 tint 问题解析
上篇文章我们说到如果你的 VectorDrawable 如果采用一个带 <selector>
的颜色进行着色,那么就需要在测试代码中对 Drawable 进行重新着色,而不是直接比较。
本篇文章就来着重说说其中的原理。
最近在迁移到 AndroidX 之后一直折腾 TDD 的事情,也遇到了大的小的不少坑点;
鉴于 AndroidX 在测试方面还没有太多的文档,就写一篇博文来总结一下折腾的经验,也给后来人做一些参考。
之前又稍微折腾着想尝试一下 TDD,并在每次构建的时候加入测试环节,当测试不通过就不允许 build。
当一切都配置好,点下 build App 的时候,却出现了 There were failing tests.
。
我心想,不会啊,现在我就根本没写几个测试用例,为什么会通不过?
于是,就开始了艰难的调试过程
如果你开发过稍微有点体量的 Android App,都会因为越来越多的 Gradle 依赖而头疼。
一个 App 的编译依赖少则十几项,多则几十项,如果再加上多 module,那么依赖的统一管理就很重要了。
但是,如何高效统一管理,则是一个难题。今天就来说说如何使用 buildSrcVersions 轻松管理 gradle 依赖。
之前学算法分析的时候只知道通过数语句来计算算法的复杂度,而对于递归算法没有很好的方法;
由于递归算法通常采用分治思路,每递归一次,子问题在增多,但是子问题的规模在减少,所以如何去计算这种递归类算法的复杂度呢?
斯坦福的教授提供了一种使用 递归树 的方法。
GPG 相信很多人都折腾过,Yubikey 也有很多人买过;
但是好像只有老外折腾过 Yubikey + GPG 的;
最近刚折腾完毕,因为自己不慎还把一个老钥匙搞丢了,现在只能随它去了;
这里就写写我折腾过程中遇到的坑,前车之鉴,后事之师。
最近,鉴于性能考量,我从 MathJax 迁移到了 Katex,但是随之而来出现了一个问题,就是脚注里面的数学公式没办法渲染出来。
本文着重介绍一下如何解决 Travis CI 在进行自动集成的时候,总是会更新旧博客的问题。
之前有想过要把这篇文章合并到上一篇里面,不过这个问题比较隐蔽,而且较难解决,最后还是新开一篇文章来详细讲一下该怎么做,防止以后有人再被这个问题困扰。
这个想法是我在折腾 Hexo Next 6.0 的时候发现的,有位仁兄在 Next 的新 repo 问如何处理 CI 问题,受到他的启发,我就开始折腾使用 Travis CI 进行博客的自动部署了。
Solidity 是运行于以太坊(Ethereum) 区块链上的智能合约语言,它是图灵完备的,意味着可以用它写一些任意复杂度的程序并运行于区块链中。