第一个 UI 控件
尽管我使用 Java 编程已有十年有余,但其实 JavaScript 才是我最早掌握的一门编程语言,虽然 C 语言是大学生的必修课,但我真不敢说在当时我已经掌握了它,在 Web 2.0 的时代,最流行的开发工具便是网页三剑客,Dreamwaver 的所见即所得让很多初学者也能写出一个可以运行的 Web 应用,我便是其中一个。
尽管我使用 Java 编程已有十年有余,但其实 JavaScript 才是我最早掌握的一门编程语言,虽然 C 语言是大学生的必修课,但我真不敢说在当时我已经掌握了它,在 Web 2.0 的时代,最流行的开发工具便是网页三剑客,Dreamwaver 的所见即所得让很多初学者也能写出一个可以运行的 Web 应用,我便是其中一个。
在可测试应用架构设计(一)中有介绍过 Booster 是如何解决 Transformer
在本地单元测试环境和编译环境中的复用问题,在本节中,我们来一起探索如何利用 Booster 提供的 TransformerClassLoader
来解决应用架构的可测试性问题。
Booster 又双叒叕发布了新的版本—— v4.2.0,本次更新内容如下:
TransformerClassLoader
实用类在运行时自动发现 Transformer
并进行字节码注入,使 Transformer
能够完全复用自从字节码操作技术在移动端普及之后,各种 app 的架构中都采用了这一技术,最典型的例子便是采用 Service Locator 模式实现的 IoC 框架,这类框架都有着相同的实现思路,挫一点的则是通过反射来实例化对象,好一点的会用 apt 来生成 Factory 代码来解决实例化的问题,但都会存在一个问题,就是需要一个静态的映射(注册表)来解决根据接口查找实现的问题,而这个静态的映射(注册表)一般都是通过字节码操作技术在编译期间自动生成。
很早就想写一篇关于两种不同的做事哲学的文章,一直有些纠结标题是「两个世界,两种哲学」还是「两种哲学,两个世界」,前者在于从结果的角度出发,后者则是从原因的角度出发,以佛教的观点一看,因即是果,果即是因,其实都是一样,但其实我们从解决问题的角度来说,一般还是由果及因,找到了根本原因,才能真正的解决问题。
最近用 KAPT 来生成 Kotlin 代码,遇到了一个头疼的问题,生成的 Kotlin 代码需要调用源 Kotlin 代码中被 Annotation
标注的属性,理论上讲,直接用 .
操作符来调用属性不就行了吗?然而,事情并没有想象的那么简单。
是个 Java/Android 工程师都知道,用 ==
比较其实是比较的两个对象是否是同一个实例,比较实例其实就是比较内存地址是否相等,当我们在打印一个 Object
的时候,默认就会输出 java.lang.Object@xxxxxx
这样的字符串,@
后面的这一串,则是 Object
实例在内存中的地址。众所周知,由于 JVM 的垃圾回收机制,会导致实例在运行时内存中的位置被垃圾回收器移动,那么问题来了,当实例被移动位置后,Object
的 hashCode()
会变吗?
当开发一个 Android Library 时,如果还同时还要提供相应的 __Gradle Plugin__,对于 Gradle 新手来说,要在一个 Gradle 工程中同时集成 Android Library__,__Gradle Plugin 和 Example App 三个模块,并不是一件很容易的事,主要的问题在于 Android App 模块中无法引用同一个工程中的 Gradle Plugin 模块,这是因为 Gradle Plugin 需要先于所有的工程进行配置和编译,所以,很多工程师都会将 Gradle Plugin 作为一个独立的工程进行开发和发布,这对于频繁地开发和调试 Gradle Plugin 的工程师来说,是非常的痛苦,每次修改了 Gradle Plugin 都要先发布到 __Maven Local__,然后再跨工程进行调试,效率极低,那有什么优雅的解决方案呢?