SQLiteDatabase APIと
ContentResolver APIが
悪いのは秘密ではないので、多くの人がそれらを
無視しようとします。 誰かがORMを選び、誰かがDAOを選び、誰かが自分で書きます。
Android開発の長年にわたって、これらすべての段階を経ました。ORMはプロジェクトの重要な瞬間にボトルネックになることが多く、そのDAOはテストと開発を必要とし、アプリケーション実装の他の詳細に費やすことができる多くの時間がかかります。質問ですが、異なるライブラリにはそれぞれ長所と短所があります（15 standard.jpg）。
1.人々のためのAPI：便利なビルダー（リクエストに5〜7個のnullを覚えていますか？）、読みやすく明白な構造、不変性、スレッドセーフ
2.簡素化された一連の操作：標準のCRUD（作成、読み取り、更新、削除、または挿入、選択、更新、削除）の代わりに、Put、Get、Deleteの3つの操作を提供します。 、1つのオブジェクトを複数のテーブルに保存して保存します。
3.リフレクションを使用しないオプションのタイプセーフオブジェクトマッピング。ただし、CursorまたはContentValuesを使用する場合は、お願いします。
4. Retrofitとのいくつかの類似点：ブロッキングコールまたはrx.Observableとして任意の操作を実行できます。将来操作を実行するためのコールバックモデルを追加できます。
5.リアクティブ-Get操作からのObservableは、Contentite Resolverの場合、SQLiteまたはUriの場合、テーブルの変更に関する通知を受け取ります。これにより、APIが単にうんざりするローダーを完全に置き換えることができます。
StorIOを試す理由：- オープンソース->バグの減少
- ドキュメント、サンプルアプリケーション、設計テスト->バグの減少
- 単体テストと統合テスト->バグの減少
- 3つの基本操作の単純な概念：Put、Get、Delete->少ないバグ
- ほとんどすべての不変でスレッドセーフ->バグの減少
StorIOを作成した理由：クエリに悲惨な5-7パラメーターを渡さなければならないことにうんざりしています。その半分はnullで、もう1つは1つの要素とString.valueOf（）->の呼び出しを持つ配列です。したがって、StorIOでは、クエリには便利なビルダーがあり、クエリ自体は不変であり、一般的に保存して使用します。
さまざまなライブラリに多くの制限があるオブジェクトマッピングにうんざりしている->したがって、StorIOにはオブジェクトマッピングに制限はなく、十分なデフォルトもありません。特定のデータタイプに対して各操作の動作を実装する権利があります。
データの各挿入/変更の前に挿入または更新->したがって、StorIOでは、これはPut操作に結合されます。
ORMは常にORMであり、場合によっては不必要な複雑さで愚かなクエリを生成するという事実にうんざりしています
このORMで決定できないような制限につまずくだけです。したがって、StorIOはORMではなく、本質的にDAOです。
誰も実際に通常のRxサポートを作成できないという事実にうんざりしています、はいSqlBriteがありますが、それを理解してみましょう-それは低レベルであり、オブジェクトマッピングは箱から出していない、BriteContentResolverには基本的に同じクエリメソッドが含まれ、BriteDatabaseは本質的に同じを提供しますSQLiteDatabaseのようなメソッドはすべてマイナスであるが、はい、Squareの人は一般に、クエリ結果のRx自動更新を実装した唯一のメソッドです。 StorIOでは、さらに進んで、上記のすべての内容と通常のRxを洗い流しました。StorIOは、優れた概念、API、さまざまなライブラリのアプローチ（レトロフィット、突然）および経験などの「マージ」です。
StorIOリポジトリ：
github.com/pushtorefresh/storioフィードバックは大歓迎です。