StorIO - human API for working with SQLiteDatabase and ContentResolver
It's no secret that the SQLiteDatabase API and ContentResolver sucks, so many try to abstract from them. Someone chooses ORM, someone DAO, someone writes his.
Over the years, we have gone through all these stages of Android development: ORM often becomes a bottleneck at a critical moment for a project, its DAO requires testing and development, which takes a lot of time that could be wasted on other details of the implementation of the application, ready for DAO to decide a question, but different libraries have their pros and cons (15standards.jpg), look what we offer:
1. API for people: convenient builders (remember 5-7 nulls in queries?), Readable and obvious constructs, Immutability and Thread-safety.
2. Simplified set of operations: instead of the standard CRUD (Create-Read-Update-Delete or Insert-Select-Update-Delete), we offer three operations - Put, Get, Delete, and you have full control over their implementation, for example, , resist and store one object in several tables and so on.
3. Optional Type-Safe Object Mapping without Reflection, but if you want to work with Cursor or ContentValues - please.
4. Some similarity with Retrofit: you can perform any operation as a blocking call or as rx.Observable, we can add a callback model for performing operations in the future.
5. Reactive - Observable from the Get operation will receive notifications about changing tables in the case of SQLite or Uri in the case of ContentResolver, this allows you to completely replace loaders, whose API is simply disgusting.
')
Reasons to try StorIO:
Why we made StorIO:
We are tired of having to send poor 5-7 parameters for requests, half of which are null, and the other is an array with one element and calling String.valueOf () -> therefore, in StorIO, queries have convenient builders, and the queries themselves are immutable save and use generically.
We are tired of Object-Mapping with a bunch of restrictions in different libraries -> so in StorIO there are no restrictions on Object-Mapping, there is not enough default - you have the right to implement your own behavior of each operation for a specific data type.
We are tired of the fact that we need to understand what needs to be done: insert or update before each data insertion / change -> so in StorIO this is combined into a Put operation.
We are tired of the fact that ORM will always be ORM and it will either generate stupid queries with unnecessary complexity in some cases, or you
you just stumble upon some kind of restriction that this ORM will not allow you to solve -> therefore StorIO is not ORM, but in essence DAO.
We are tired of the fact that no one really can do normal support for Rx, yes there is SqlBrite, but let's figure it out - it is low-level, there is no Object Mapping out of the box, BriteContentResolver contains only one query method, BriteDatabase basically provides the same methods as SQLiteDatabase with all their drawbacks, but yes, the guys from Square are the only ones who implemented the Rx auto update query results. In StorIO, we went further and wrote down everything described above + normal Rx, StorIO is our “merge” of good concepts, API, approaches from different libraries (even Retrofit, suddenly) and our experience, such things.
StorIO repository: github.com/pushtorefresh/storio
Fidbeck is very welcome.
Over the years, we have gone through all these stages of Android development: ORM often becomes a bottleneck at a critical moment for a project, its DAO requires testing and development, which takes a lot of time that could be wasted on other details of the implementation of the application, ready for DAO to decide a question, but different libraries have their pros and cons (15standards.jpg), look what we offer:
1. API for people: convenient builders (remember 5-7 nulls in queries?), Readable and obvious constructs, Immutability and Thread-safety.
2. Simplified set of operations: instead of the standard CRUD (Create-Read-Update-Delete or Insert-Select-Update-Delete), we offer three operations - Put, Get, Delete, and you have full control over their implementation, for example, , resist and store one object in several tables and so on.
3. Optional Type-Safe Object Mapping without Reflection, but if you want to work with Cursor or ContentValues - please.
4. Some similarity with Retrofit: you can perform any operation as a blocking call or as rx.Observable, we can add a callback model for performing operations in the future.
5. Reactive - Observable from the Get operation will receive notifications about changing tables in the case of SQLite or Uri in the case of ContentResolver, this allows you to completely replace loaders, whose API is simply disgusting.
')
Reasons to try StorIO:
- Open Source -> less bugs
- Documentation, Sample app, design tests -> fewer bugs
- Unit and Integration tests -> less bugs
- The simple concept of the three main operations: Put, Get, Delete -> fewer bugs
- Virtually all immutable and thread-safe -> fewer bugs
Why we made StorIO:
We are tired of having to send poor 5-7 parameters for requests, half of which are null, and the other is an array with one element and calling String.valueOf () -> therefore, in StorIO, queries have convenient builders, and the queries themselves are immutable save and use generically.
We are tired of Object-Mapping with a bunch of restrictions in different libraries -> so in StorIO there are no restrictions on Object-Mapping, there is not enough default - you have the right to implement your own behavior of each operation for a specific data type.
We are tired of the fact that we need to understand what needs to be done: insert or update before each data insertion / change -> so in StorIO this is combined into a Put operation.
We are tired of the fact that ORM will always be ORM and it will either generate stupid queries with unnecessary complexity in some cases, or you
you just stumble upon some kind of restriction that this ORM will not allow you to solve -> therefore StorIO is not ORM, but in essence DAO.
We are tired of the fact that no one really can do normal support for Rx, yes there is SqlBrite, but let's figure it out - it is low-level, there is no Object Mapping out of the box, BriteContentResolver contains only one query method, BriteDatabase basically provides the same methods as SQLiteDatabase with all their drawbacks, but yes, the guys from Square are the only ones who implemented the Rx auto update query results. In StorIO, we went further and wrote down everything described above + normal Rx, StorIO is our “merge” of good concepts, API, approaches from different libraries (even Retrofit, suddenly) and our experience, such things.
StorIO repository: github.com/pushtorefresh/storio
Fidbeck is very welcome.
Source: https://habr.com/ru/post/261623/
All Articles