
StorIO - людський API для роботи з SQLiteDatabase і ContentResolver
Не секрет, що 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
Фідбек дуже вітається.