I am following this codelab and one of the suggested best practices for retrieving data from a database was to use a LiveData wrapper for my DAO return values (step 6 in the codelab).
But in my app, I am reading an existing .sqlite file only once at the start of the activity. Thus using this wrapper should be unnecessary, am I correct?
So is it acceptable (in terms of best practices) to make my DAO return a simple object instead of using the LiveData construct around it?
There are two features of LiveData: delivery of updates and asynchronous operation.
If you will not be changing the data during the run of your app, you will not take advantage of the update-delivery feature of LiveData.
However, you still need to arrange to load the data on a background thread. If you plan on doing that by some other means (e.g., RxJava, your own background thread), you could avoid using LiveData.
Also, if your plan is to load all of the data in the database at the outset and never change it, then SQLite and Room are pointless. Just use a JSON file. The value in SQLite is in being able to query and modify parts of the data.
Related
I am making an android app using MVVM architecture. I want to fetch data from an API and insert it into room database and then fetch it from the room in my app. I don't know if it is a better way to implement database cache functionality. If there is some other or better way to do so please let me know.
your question explains exactly how you would use Room:
fetch data from an api
insert it into room database
fetch it from room in my app
Room allows you to store your data locally and retrieve this data with various different threads, making use of something like Rxjava, it also allows you to observe onto any changes with LiveData, Room is definitely a decent option to consider for caching
BUT
Using Room is ONE of SEVERAL different implementations of caching, consider posting code or a specific scenario for better answers. Happy coding.
Edit:
A common approach to using Room (or any caching) would be to either load initial data from the database, display this to the user, perform an api call, update the cache and display this updated data from the api
OR
If the user does not have an internet connection, simply use what he has available in the cache as data. Again, all of this depends on your specific scenario.
I write android app using MVP pattern. My question is regarding database layer. I want to make it maximally independent, so it will be possible to replace it with something else without code changing in Presenter in the future. I decided to use pure SQLite without ORM, since the user table is updated in different places with differenet fields (in some place I update user's name, in other place in code - token etc.). ORM (I used realm) doesn't allow to do it, you have to write separate method for updating name, separate - for token etc.
Another problem is with ContentValues: when you update user you have to specify the fields you want to change via ContentValues in Presenter, and then Presenter calls repository.updateUserLocal(contentValues), so my Presenter dependents on data layer (if I decided to add ORM to the project, I will need to go to every Presenter and remove ContentValues). So the architecture is bad. Can you please advice how to organize the architecture of the app in the best way?
I'm facing with issue that Firebase as Realtime Database works great while we connect it with Activity or Fragment. But trying to separate from view elements and create some abstraction for it (because e.g. we want to replace it while testing or in the future) becomes quite hard, especially trying to implement MVP pattern.
Are there any solutions for this issue?
There should be no inherent coupling between Firebase and UI (unless you're using FirebaseUI). Typical solution would be to encapsulate firebase database access in some kind of Service/DAO class (injected in to UI classes using Dagger for example)....and have methods in that class return RxJava Observable (this also nicely enables making sets of nested firebase queries....for example if doing something equivalent to a "join")
Just save a string value in your resources and save your DB path
Then when you create a DatabaseReference use that value to point to the base of either your real or test DB
My app will pull some json data when it is started and realistically, once the data has been pulled, I really won't need to pull it again for the duration of the user experience. The backend data may update a few times a day at most, so I think I would like to just grab the data upon app start and then use that same data for the duration and give the user an option to manually refresh the data. So, my question is, where/how should I store that data? I've got all of my data structures set up (classes and sub-classes). And there may be 200 or so instances of some of the classes. If I store everything as member variables in my activity_main class, it won't be available to other activities once the other activities are started. Storing them all in databases could be an option, but it sort of feels like overkill. I really don't need the data to persist between sessions. Is there a way to easily store it in memory and still have it easily accessible to all activities?
You should think about OS killing your app process on low-memory, so backing your data on disk is a good thing to do. Doing so you have an ability to show user data from disk cache while refreshing it in background from server.
Choosing the tool for data storage depends on the way you need to work with data.
Of course, there is an option to use Realm, but you should consider the fact that it is not the relational database. So if you have complex domain model with joins and other relational stuff for your business logic, I'd go with something other. It is thread-safe, also has migrations (but, as for me, migrarations are always pain, you just can not do anythig about it). Realm is supposed to be RxJava-friendly now (support added in v0.87) There are some disadvantages(part of them may already be fixed), but you should consider it before using.
As for more relational approach, there is SQLBrite library:
A lightweight wrapper around SQLiteOpenHelper which introduces reactive stream semantics to SQL operations.
It is not an ORM (but you can add some kind of it on top of SQLBrite if you wish: see this for more info). In fact, being alone this library is doing one thing (and doing it good) - it provides a mechanism for coordinating and composing the notification of updates to tables(Realm also has such ability) such that you can update queries(in SQL fashion) as soon as data changes. And it respects RxJava!
As an alternative to SQLBrite you can look at StorIO.
There are also lots of different ORM solutions, like GreenDAO, ORMLite etc.
But I'm pretty sure, one of the first two libraries (Realm or SQLBrite) will likely help you. So analyze your app, these libs and decide what fits better.
P.S. Great article on how RxJava would help you to work with data from different data sources (in-memory cache + disk cache + network) easily. Might be helpful!
I would still recommend a SQLite Databse, you can easily declare it as a 'in-memory' database, if that is what you want.
However.... I would be rather upset as a user of your application if it downloaded redundant data over and over. I would just recommend making a content provider and being done with it. This gives you access to a SyncAdapter, and defines clear boundaries between where code should go.
The 'trick' with making a good ContentProvider is to make good POJOs, that have methods to convert from POJO -> ContentValues and Cursor -> POJO(s).
Easiest thing is to do is store the json file in Apps data storage and parse the json every time you need.
But this is not recommended as it is costly to parse data every time.
Best option is to implement Realm (Replacement for Sqlite) which is very easy to implement and its amazingly fast.
I'm having a hard time to optimize backwards compatibility, complexity and best practice for SQLite database handling on Android. I found two not deprecated ways to manage SQLite databases and cursors:
Directly through android.database.sqlite
ContentProvider, CursorLoader and LoaderManager
I'm trying to design the database implementation future proof. This means I would like to implement a best practice promoted by Google. I found a tutorial on implementing ContentProvider and LoaderManager.
If I follow Lars Vogels proposals, my code is blown up with duplications and unnecessary complexity. It does make sense for some tables in my database. But it would make no sense to implement this for a mapping table with three fields (for example). Furthermore I'm having problems with ActionbarSherlock and the Callback Interface of LoaderManager (there's a solution but it would double my data handling classes).
Direct handling of database and cursors via android.database.sqlite is provoking problems with resource management (close your cursors!) and makes me responsible for task handling.
My Questions:
How are you handling SQLite databases on Android?
When do you go the extra mile and implement ContentProvider and LoaderManager?
How do you stay backwards compatible?
My current approach:
I created a class that separates database I/O (via android.database.sqlite) from activities. All methods open and close the cursors they use during their execution (outside of my activities) and return the objects or the data as needed (instead of a cursor). I/O operations are performed in AsyncTasks. This approach seems very deprecated.
I recently had the same plain sqllite / content provider dilemma, and it looks like content provider are the most common approach to solve the problem.
Even if the official doc states that
You don't need to develop your own provider if you don't intend to share your data with other applications
they added the option to have unexported content providers using
android:exported="false"
All the books I read, including Reto Meier's Professional Android Development 4, suggest using content providers.
Moreover, at the cost of a lot of boilerplate code, you can forget about multithreading and open cursor issues.
Anyway, I have to say that the biggest advantage you get from the content provider / cursor loader combo is that your loader is automatically notified whenever the underlying data changes.
If you use plain sqllite you need to implement some way to get the client classes notified whenever the data changes in background. For example, I used broadcasts to notify any activity that the tables where updated inside an intentservice.
Finally, I was a bit disappointed by all the code duplication that you are ranting about, and I decided to write a python script to generate the content provider in my place using just a description of the data model. You probably have to modify the generated class (or better, to extend it), but I think it saves quite a lot of time. You can find it here
Conclusion:
if you want to export your data to other apps (not so common), you need to go for content provider
if you want to observe the data / update the ui because your dataset might be changed in background, content provider + loader is extremely powerful
if you have a preloaded data set, and maybe you update it in the same activity that display the data, or you need to perform simple operations with your tables, maybe a sqllite helper class is just enough