Не секрет, что API SQLiteDatabase и ContentResolver — отстой, поэтому многие стараются от них абстрагироваться. Кто-то выбирает ORM, кто-то DAO, кто-то пишет своё.

За долгие годы Android разработки мы прошли через все эти этапы: ORM часто становится узким местом в критический для проекта момент, своё DAO требует тестирования и разработки, что отнимает много времени, которое можно было тратить на другие детали реализации приложения, готовые DAO в принципе решают вопрос, но различные библиотеки имеют свои плюсы и минусы (15стандартов.jpg), посмотрите, что предлагаем мы:

1. API для людей: удобные билдеры (помните 5-7 nullов в запросах?), читаемые и очевидные конструкции, Immutability и Thread-safety.
2. Упрощенный набор операций: вместо стандартного CRUD (Create-Read-Update-Delete или Insert-Select-Update-Delete) мы предлагаем три операции — Put, Get, Delete, при этом вы имеете полный контроль над их реализацией, можете, например, упороться и хранить один объект в нескольких таблицах и так далее.
3. Опциональный Type-Safe Object Mapping без Reflection, но если вы хотите работать с Cursor или ContentValues — пожалуйста.
4. Некая схожесть с Retrofit: вы можете выполнить любую операцию как блокирующий вызов либо как rx.Observable, мы можем добавить callback модель выполнения операций в будущем.
5. Reactive — Observable из Get операции будет получать уведомления об изменении таблиц в случае SQLite или Uri в случае ContentResolver, это позволяет полностью заменить лоадеры, API которых просто отвратителен.


Причины попробовать StorIO:

• Open Source -> меньше багов
• Документация, Sample приложение, дизайн тесты -> меньше багов
• Unit и Integration тесты -> меньше багов
• Простой концепт трёх основных операций: Put, Get, Delete -> меньше багов
• Практически всё immutable и thread-safe -> меньше багов

Почему мы сделали StorIO:

Мы устали от необходимости передавать убогие 5-7 параметров для запросов, половина из которых null, а другая — массив с одним элементом и вызовом String.valueOf() -> поэтому в StorIO у запросов есть удобные билдеры, а сами запросы immutable и их можно сохранять и использовать обобщенно.

Мы устали от Object-Mapping с кучей ограничений в разных библиотеках -> поэтому в StorIO нет никаких ограничений на Object-Mapping, не хватает дефолтного — вы вправе реализовать свое поведение каждой операции для конкретного типа данных.

Мы устали от того, что нужно понять, что надо сделать: insert или update перед каждым вставкой/изменением данных -> поэтому в StorIO это объединено в операцию Put.

Мы устали от того, что ORM всегда будет ORM и он либо будет генерить тупейшие запросы с ненужной сложностью в некоторых случаях, либо вы
просто наткнётесь на какое-то ограничение, которое этот ORM не даст вам решить -> поэтому StorIO не ORM, а по-сути DAO.

Мы устали от того, что никто толком не может сделать нормальную поддержку Rx, да есть SqlBrite, но давайте разберемся — он low-level, в нем нет Object Mapping из коробки, BriteContentResolver содержит только один метод query, BriteDatabase по сути предоставляет те же самые методы, что и SQLiteDatabase со всеми их минусами, но да, ребята из Square в общем то единственные, кто реализовал Rx автоапдейт результатов запросов. В StorIO мы пошли дальше и запили всё, о чём написано выше + нормальный Rx, StorIO это наш «merge» хороших концепций, API, подходов разных библиотек (даже Retrofit, внезапно) и нашего опыта, такие дела.

Репозиторий StorIO: github.com/pushtorefresh/storio

Фидбек очень приветствуется.