Skip to content

Latest commit

 

History

History
135 lines (104 loc) · 5.31 KB

结合RxJava更简单地使用SQLite.md

File metadata and controls

135 lines (104 loc) · 5.31 KB

结合RxJava更简单地使用SQLite

我经常想在项目中使用 ORM 来简化操作,但是最终都将这个念头打消。主要有以下几点原因:

  • 我的数据模型远远没有复杂到需要 ORM 帮助
  • 出于 Android 性能上的考虑,自动生成的SQL语句可能没有被优化

不过最近,我开始使用一个简单的设计模式,使用 RxJava 来提供一个简单的数据库访问管理。 我称它为 “Async Rx Read” 设计模式,很渣的一个名字哈,不过是我能想到最好的了,命名总是程序员的难题嘛。

#Easy Read Android 开发中有一条很重要的设计原则,永远不要在主线程执行 I/O 操作,显然这条规则对数据库访问也适用。 RxJava 很适用于解决这个问题。 在以前,我通常为每个 table 创建一个 Java 类,然后通过我的 SQLiteOpenHelper 来管理这些 table。 现在使用这个新的方法后,我将这个工具类扩展成所有事物读写 SQL table 的唯一入口。 我们来想个简单的例子:一个由 UserTable 类管理的 USERS 表:

// UserTable.java
List<User> getUsers(SQLiteDatabase db, String userId) {
  // select * from users where _id = {userId}
}

上面的方法有一个缺点,就是你一不小心可能会在主线程调用它,这里面是由调用者确保它是在后台线程中被执行的 (如果需要更新 UI 的话,再将结果返回给主线程)。而不是依赖一个线程池管理,或者更糟点,使用 AsyncTask 管理, 我们将使用 RxJava 替我们管理线程模型。

让我们重写这个方法返回一个 callback :

// UserTable.java
Callable<List<User>> getUsers(SQLiteDatabase db, String userId) {
  return new Callable<List<User>>() {
    @Override
    public List<User> call() {
      // select * from users where _id is userId
    }
  }
}

实际上,我们只是重构了一下这个方法返回一个 lazy result ,使得 database helper 可以将这个 result 转变成一个 Observable

// MySqliteOpenHelper.java
Observable<List<User>> getUsers(String userId) {
  return makeObservable(mUserTable.getUsers(getReadableDatabase(), userId))
    .subscribeOn(Schedulers.computation()) // note: do not use Schedulers.io()
}

注意到将 lazy result 转换成一个 Observable 时,helper 强制 subscription 运行在后台线程 (这里使用的是 computation scheduler;不要使用 Schedulers.io() 因为它是由 unbounded executor 支持的)。 这样调用者就不必担心这个方法会阻塞主线程了。

最后,makeObservable() 方法的实现很简单(而且是完全通用的):

// MySqliteOpenHelper.java
private static <T> Observable<T> makeObservable(final Callable<T> func) {
  return Observable.create(
      new Observable.OnSubscribe<T>() {
          @Override
          public void call(Subscriber<? super T> subscriber) {
            try {
              subscriber.onNext(func.call());
            } catch(Exception ex) {
              Log.e(TAG, "Error reading from the database", ex);
            }
          }
    });
}

现在,我们的 database 读取已经变成了 observables,保证查询是执行在后台线程的。 访问数据库操作也是很标准的 Rx code:

// DisplayUsersFragment.java
@Inject
MySqliteOpenHelper mDbHelper;

// ...

mDbHelper.getUsers(userId)
  .observeOn(AndroidSchedulers.mainThread())
  .subscribe(new Action1<List<User>>()) {
    @Override
    public void onNext(List<User> users) {
      // Update our UI with the users
    }
  }
}

如果你不需要返回结果更新你的 UI,那么你只需要 observe 一个后台线程。 然后你的 database 层会返回 observables,当获得结果时很容易将它组合变换。 例如,假定 ContactTable 是一个底层类, model (User class) 对它是不可见的, 它应该返回底层 object (可能是 Cursor 或者 ContentValues)。然后你可以用 Rx 去 map 这些底层值,把它们转换成你的 model 类,实现更加清晰的分离层。

两个提示:

  • 你的 Table 类不应该包含 public 方法:只能有 package 的 protected 方法(仅允许相同 package 内的 Helper 访问 ) 和 private 方法, 其他类不能直接访问 Table 类。

  • 这个方法对依赖注入兼容性很好:很轻松就可以同时实现 database helper 和注入单个 Table (意外收获:使用 Dagger 2,你的 table 可以拥有自己的组件,因为 database helper 是实例化它们所需的唯一参考资料 )。

这是一个很简单的设计模式,它显著提升了 RxJava 在项目中发挥的效果。 我正在扩展这层结构,让它可以为 list view adapter update 提供更灵活的通知机制 (和 SQLBrite 提供的不同),会在以后的文章中介绍。

这项工作还在进行中,欢迎反馈。