道産子エンジニア

悲観主義は気分に属し、楽観主義は意志に属する

greenDAOをObjectBoxに置き換えたい

この記事は本日 potatotips #37でした以下の発表のafter showみたいな内容。

speakerdeck.com

greenDAOをプロダクトで使っているけど、version2なのでかなりいけてない。

greenDAO v2の良くないところ

  • 自動生成されるクラスが多い&コードを変更でてきてしまい、闇クラスの香りがする
  • とにかく Schema の記述が面倒。リレーションを組むならまず精神統一が必要
  • SQLiteベースでシンタックスも微妙

などなどいろいろ問題はある。スピードは早いのだけど、 設計が開発者フレンドリーじゃないのであまり好きじゃない。(もっと楽したい)ちなみに、この辺はv3になりannotationベースになってから改善されてきている。導入については今回端折るけれど最新のv3.2.1ならまだすぐに別ライブラリに置き換えたい!と思うレベルではないかもしれない。

そして先月末でてきて期待しているのが、同じくgreenrobotが作っている新しいORMライブラリの ObjectBoxだ。

ObjectBoxのいいところ

  • 公式のベンチマークはないが読み込み早いらしい(gfxさんの記事が詳しい)
  • アノテーションベースでいい感じ(日本語最速の記事はこれだった)
  • 自動マイグレーションあり

などなど導入しない手はないな!って気持ちでいっぱいなのでまずはv3に上げるところからサンプルを作ってみた。

github.com

コミットの順番にアップデートして見てるので試してもらうと動きがわかりやすいと思う。 greenDAOにはないのがマイグレーションとDBっぽくないシンタックスなので最終的には全部置き換えたい。

DaoCompatを使えばgreenDAOから移行できる

とはいえ今のプロジェクトの膨大なコードを別ライブラリに一気に置き換えるのはテストが大変なので困る。 俺がこの発表をしたかったきっかけは greenDAO から ObjectBox へ以降しやすいように DaoCompat なるものを用意しているから簡単だよ!というからだった。

featureにもちゃんと

DaoCompat library: Already using greenDAO? This small helper library gives you familiar greenDAO APIs for ObjectBox.

と書いてあったので期待していたが結果は発表した通り、エラーがでまくってて動かなかった。
サンプルを見て問題があったら指摘待っております。
コードもまだgithubにないのでどの辺が悪さをしているのか想像するしかない。importが失敗してるのでその辺はちゃんと見たいが、daoCompatを使うとgreenDAOのコードが生きたままなので結局あんまりいけてない。

最終的には DaoCompat 使わずに ObjectBox でフルスクラッチできたほうが幸せなのでこの際やりきってしまうのもありだと思う。(サンプルコードはそうなった。)ただし、導入においていくつか注意点もある。

  • もちろんまだbeta版なのでAPIの破壊的変更などがありえる。あと下位互換はしないそう
  • 複数スキーマを作っている場合はまだ未対応

個人的にはコードが自動生成されるのは好きだ。中を見れば何をしていて、どこが問題かすぐわかるから。 ただ既存のモデルにアノテーションをつけたらクラス内を変更されるので、メソッド名の競合など何か不具合が起きる可能性は0ではないかもしれない。

今後もアプデされたら追って発表していく。issueを見るかぎりRxやkotlinの対応もされていくっぽい。