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
Related
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.
I'm developing an app and I have a local SQLite database for keeping some user data and I am also using the Room persistence library as it is a recommended approach. I followed the tutorial and created a model, a DAO and a database itself. So in the activity I just populate my RecyclerView using the new thread and it is working OK.
But then I got a problem in another view where I want to change the TextView text to the value I got from the database. I can't do it in another thread like I did earlier because I get CalledFromWrongThreadException and I also can't call it from the main thread because I get IllegalStateException. All the tutorials I found just provided me with the info I already knew about the creation of the database and DAO, and all of them used allowMainThreadQueries() with a note that it shouldn't be used in production. However, more problem-related research lead me to some workarounds using runOnUiThread() which is not really a solution here. So I got a question:
Is there any straightforward approach of doing this that I missed? (Or maybe not so straightforward but rational).
In your case access to database should looks somthing like this
Thread{
val text = dataBase.getDao().getText()
Handler(Looper.getMainLooper()).post {
textView.text = text
}
}.start()
But using LiveData or RxJava2 it can be done more comfortable
Try this LiveData, RxJava2
The cleanest way to use Room is with LiveData API and Lifecycle API you can check the link
and I recommend you to watch other google codelabs, they helped me a lot
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?
looking for a database framework to use in a library I'm designing, I stepped with Realm.
Although is a very good ORM I think it doesn't cover some of the needs a lot of people have when implementing it.
As it does not allow inhetirance, how can I make such a simple thing as creating a caching-expiration based model with Realm? Say, for example, I want all my objects in Realm have two fields: Date lastUpdate and static long expirationTime and before every call to the API I will check if the object has expired to gather results from cache or from network. The only way to achieve this is copying the fields in all the classes and then I could not even make it generic, as I would have to explicity gettheir fields by type (I couldn't have a generic class for checking if objects has expired for example, without relying on reflection).
So my question is...
I'm doing a misuse of Realm or I can't really achieve this behavior?
I am looking for a way to test against an sqllite database, I know that Mocks Objects can't do it.
What is the best possible way?
I have already tried to look into writing sql scripts to delete the data out of there, but that just cluttered my production code with test code.
Assuming you need to actually test query your database, usually a separate test database is created, which mimics your 'real' database. Before each test, truncate the tables (and seed if necessary).
If you do not actually need to query your database, definitely use mocks. Create an interface and a class implementing it doing the actual queries, and mock the interface in your tests. Of course you need to test this implementing class, which you can do in the way described above.