Android Weekly Notes Issue #248

转载

mob60475706e1a1 2021-06-02 16:35:31

文章标签 java 文章分类 Java 后端开发

ARTICLES & TUTORIALS

Why your app should crash

作者认为有时候让应用崩溃反而是有好处的.

以NPE为例, 有时候我们会习惯性地加很多null判断, 有的是多余的, 有的防御型的代码反而会掩盖了真实问题所在. 比如当一个不合理的情况发生时, 让用户看到一个不可理解的页面, 比如空白, 然后我们开发者根本不知道这种情况的发生.

与其这样掩盖错误, 不如让应用崩溃, 让开发者立即知道问题的原因.

实用建议:

永远让应用对外来输入(比如service的响应, UI的输入, 进来的intents)保持健壮性.
在程序的入口点保证数据的完整性. 这样不合理的数据就不会到处都是, 所以你不用到处检查.
如果你不确定某个错误是否会在某个地方发生, 先假装它不会发生, 在测试阶段再验证.
如果某个方法在产品环境不能被调用, 或者只能被调用一次等, 抛出IllegalStateException.
永远在发布之前进行完整测试, 这样你就会在用户之前, catch住可怕的崩溃.

The Two ID Problem

还是Trello开发离线模式的系列文章, 本篇讲他们遇到的一个很tricky的问题: id问题.

在他们的项目里, 所有的models都有一个id, 用以和server通信, 以及定义model之间的关系.

如果是在离线模式下, 就不能依靠server来提供这个id, 客户端需要自己生成.

所以离线模式下有两种id, 一种是本地生成的, 一种是用来和server通信的.

他们想过几个办法, 比如在sync的时候将local的id转化为server id; 或者干脆存储一个id的Pair类, 但是都有难以维护或者性能缺陷等种种问题.

最后他们提出了一个叫local-server barrier的解决方案. 基本的原则就是, 在app中, 只使用local的id, 同server通信时, 使用server id. 好处: 首先保证了客户端代码的简洁, 只有网络通信层需要考虑到server id; 重构代码量小.

Retaining Dagger components

如果你用dagger创建了component, scope是Activity或者Fragment, 那么你可能遇到过这个问题: 旋转屏幕之后, 所有的依赖都重建了, 因为你创建了一个新的component.

如果你想要在configuration变化的时候不重建, 你就需要把component存储在一个全局的地方, 但是这样的话, 当你真的结束你的Activity和Fragment的时候, 你如何释放这些component呢?

你需要分层地(hierarchical)存储, service-tree就是用来做分层存储东西的一个工具.

文中基本思想是把Application的component作为根节点, 然后Activity和Fragment的component作为树形结构的叶子节点逐级存储. Activity和Fragment的节点什么时候移除, 有一些判断条件和时机选择, 详见原文代码.

The Burden of Knowledge

鼓励在team里分享知识.

Realm Migrations Supercharged with Dagger

使用Dagger2可以大幅度改善Realm中的数据迁移处理. 具体的做法是把每一步的迁移处理都放在一个统一接口的实现类里, 然后注入它们.

@Module public class MigrationsModule {     @Provides     @IntoMap     @IntKey(1)     static VersionMigration provideVersion1Migration() {         return new Version1Migration();     }     @Provides     @IntoMap     @IntKey(2)     static VersionMigration provideVersion2Migration() {         return new Version2Migration();     } }

所以最后的迁移类看起来就是这样:

@Reusable public class Migration implements RealmMigration {     private Map<Integer, Provider<VersionMigration>> versionMigrations;     @Inject     Migration(Map<Integer, Provider<VersionMigration>> versionMigrations) {         this.versionMigrations = versionMigrations;     }     @Override     public void migrate(final DynamicRealm realm, long oldVersion, long newVersion) {         for (int i = (int) oldVersion; i < newVersion; i++) {             final Provider<VersionMigration> provider = versionMigrations.get(i);             if (provider != null) {                 VersionMigration versionMigration = provider.get();                 versionMigration.migrate(realm, i);             }         }     } }

这样做的好处:

1.以后再有数据库升级也不需要再改这个类了.
2.不需要逐个check每个版本号, 自动只从需要的版本号开始做迁移.
3.每个迁移模块都变成了可测试的单元.

我觉得作者的这种处理结构很好, 不仅仅限于Realm数据库的迁移, 其他的数据库迁移也可以用类似的结构来处理.

How to be a Mock-Star…

介绍如何用mockito来测试一个MVP的程序.

首先测试Presenter的部分, 这里Mock了数据源和各种错误响应.

测试Repository, 需要用到MockWebServer, 来模拟测试环境下的响应.

Animating Markers with MapOverlayLayout

作者App的动画实现讨论第二发, 如何让地图上的markers带缩放和渐变动画 -> 用MapOverlayLayout.

文中有详细的实现代码, 基本思路就是在这个MapOverlayLayout中保存一个View的列表, 然后在自定义View中实现每个marker在相应动作时的动画.

What Unit Tests are Trying to Tell us About Activities Pt 2

以Activity/Fragment作为基本构建单元, 让程序难以测试, 本文举例说明了这一点.

JUnit 5: DisplayName

JUnit 5提供了@DisplayName, 这样测试报告里case显示的名字将是@DisplayName定义的字符串.

相比原先的方法名来说, 这个字符串是可以带空格的, 所以比之前的可读性增强了.

Clearer RxJava intentions with Single and Completable

RxJava中我们经常用到的类就是Observable, 然后处理三个事件: onNext(), onError()和onCompleted().

但是有些时候我们并不需要关心全部这三个事件, 这时候我们就可以用Single<T>和Completable.

Single<T>返回一个值或者一个error.
它和Observable之间可以互相转换: 用toObservable()和singleOrError()方法.

Completable, 只有onCompleted()和onError(). 它不发射任何值, 可以在它之后用andThen()来添加另一个Observable, 进行后续其他操作.

Observable不能直接转换为Completable, 因为不知道Observable到底会不会停止. 可以把Single转换为Completable, 用toCompletable()方法.

Custom FindBugs detectors in Android

Android中有两种工具可以做进一步的编译期检查: Android Lint和FindBugs.

FindBugs是一个静态的分析工具. 本文的主要任务是讲解如何实现一个自定义的检测器来检测一种特定的错误.

作者的例子是try-with-resources模式的代码.
这是Java 7新加的模式try-with-resources:

try (Cursor c = db.query(...)) {     c.moveToFirst();     while (!c.isAfterLast()) {         return new Foo(                 c.getString(c.getColumnIndex(...))                 ...         );     } }

try语句中声明的资源将会在这个block结束的时候自动close.

但是这个特性最低需要API 19.
所以为了兼容旧版本, 我们不得不使用finally来自己close:

Cursor c = db.query(...); try {     c.moveToFirst();     while (!c.isAfterLast()) {         return new Foo(                 c.getString(c.getColumnIndex(...))                 ...         );     } } finally {     c.close(); }

但是有时候我们会忘记close导致了泄露, 所以需要实现一个自定义的findbugs检测器来检查这种错误. 具体实现步骤和讨论见原文.