I'm a beginner developer and I'm currently developing a Quiz app.
Each Quiz contains 50 questions and I'm storing them using Room database.
I've got Coins, Stars, and the score and number of finished questions for each Quiz (And also user's information) that I want to save.
And I still don't know what is the best method to do that.
I was thinking about combining SharedPreferences and Firestore to save user's progress and information, SharedPreferences to save them locally, and Firestore so that when the user signs in on another device, all his progress and information will be retrieved (and saved in SharedPref).
(**Data will be saved in Firestore when the user only signs in with Google)
Now my Questions is :
Can I combine SharedPref and Firestore when saving data? and is it a good idea to do so?
if not, should I only use Firestore for that?
Can I combine SharedPref and Firestore when saving data?
Yes, you can but I cannot see any benefit at all. You say:
Firestore so that when the user signs in on another device.
To have the data available no matter what device the user is using means that each time the user closes the app, you should save the progress in Firestore. So I cannot see why would you use another data structure. Besides that, SharedPreferences do not persist along with app uninstalls. SharedPreferences data is always deleted.
It would have been an excellent idea only if you wanted to store the progress in SharedPreferences and commit the quiz to Firestore only when it's finished. In this way, you'll only be billed with a single write operation, which sounds perfect. However, this solution doesn't provide the feature to have the progress available, no matter what the device the user uses, as it's stored only on a single device.
Firestore has a feature where it will automatically store data in the device's cache, so when your user go offline, they can still view what they last had access to. Since firebase already takes care of when your users go offline, I suggest going with firestore only route.
You can read more about firestore's offline cache here(Watch the video, it's great):
https://firebase.google.com/docs/firestore/manage-data/enable-offline
Related
I've been using Firebase in android apps for a while now and I was wondering if it would be at all possible for when a user creates an account (using Firebase authentication) it also creates a Firestore database linked to that account and only that account? I would also like it so that when the user deletes their account, the database is removed with it. I was looking into other database options but Firestore seems to be the best option for what I want to do.
Let me know if this needs clarification!
In your case one firestore database will work perfectly. You will need to do some thinking on database structure
This video will help https://youtu.be/haMOUb3KVSo
You shouldn't create a database for each user, it will become really messy when your code and userbase grows. Also there is no way to create databases programmatically.
So I am wondering about how necessary it is to store variables in the realtime firebase database if I want all Users at access the same dynamic variable.
So for instance, I have a arraylist that stores the list of open games, and if I want this list to update in realtime for every user should this List in firebase realtime database?
Sorry for the simplicity of the question
Yes, it may be a simple question, but it surely pops in head of everyone, once.
I think for updating any list dynamically in real time, would require you to access any kind of database.
It is not necessary to have it on Firebase database, but any database online, that can tell every open instance of your app that the list has to be updated at a particular instant.
The main reason of why you need it to be on database is updating it in real time and that too dynamically.
If it's not dynamic, meaning the content that you need, can be hardcoded then one way would be placing everything you need in your code and using timer or something like that to fire at particular moments to update things in your app.
Also that aside, sorting, storing and changing data is much simpler using a database, which also becomes one more reason for you to use a database like Firebase to keep content of your app that has to be updated frequently in real time.
You can know more about database in this Google link, I found.
I was trying to develop an mobile app which have some similar idea just like Uber, which is real time update driver & customer location. So here I am seeking for suggestion for what I was thinking for the app structure.
For what I research, in order to provide fast real time update location, I may need to make use of real time database such as Firebase for the backend. So, I was thinking to combine 2 different type of database to achieve what I was thinking...
Firebase - For real time fast update user location
MySQL - For backend api business logic
However, I have no experience with firebase, so I hope you all can give some advise. I plan to only store the user location coordinate information in firebase database, then retrieve it from mobile app to update realtime.
My problem is I not sure should I forever persist those driver coordinate data in firebase database? Since the coordinate data keep changing update in firebase, so should I delete those coordinate data from firebase as soon as the driver have reach the destination. (No need to keep those data persist, only real time data keep change on firebase)
Thanks for reading such long question, I will also happy that if you all can remind to me any other concern if I use 2 different database for my application.
You'll typically keep a list of drivers and their locations in Firebase:
driverlocations
driver1id: location
driver2id: location
This means that you're not adding new data, but updating existing data. So you don't have to worry about the list constantly growing.
To ensure you don't have stale data for drivers that closed the app/stopped driving, you can use Firebase's onDisconnect() handlers to remove the data when they disconnect.
Now querying this data for nearby drivers is still tricky. You'll want to look at GeoFire for that. I recently explained why that is needed and how it works here: Sort array by distance near user location from firebase
How should I proceed to build or update data based on Firebase user information ?
I'm building an app where people can posts messages in an open feed. On screen, these posts and replies contain the username and profile picture. I'm using Firebase to store these posts and the users.
The question is should I "build" and store a post with the profile pic (url) and username stored, "hardcoded", in that post or retrieve data stored in the corresponding user subtree in Firebase for each post?
If a user updates his profile picture, the first solution means searching through all posts and updating every corresponding post and replies but is quicker in loading the feed, the second seems more efficient for a large number of posts and users but more laggy on execution.
This is my first time with Firebase and with Android. What is the best practice ?
The common practice is to store the profile picture in Firebase Storage. When uploading the picture you need to get the coresponding url of that picture. Having that url, you can easily store it in the Firebase Database or in Cloud Firestore. Every time you need to display the picture, just simply use the reference of that picture. If a user will change the profie picture, there will be no need for doing something. Using that reference will display in every place the new picture.
I have an android app with user login i need to store the login details in my app.
My app also has some user history of certain request made by him/her.
My app is a software service app so user details must be stored in app which is fetched from the database
Is Sqlite or sharedpreference suitable for my application?
Depends, If you only want to save sessions of user use SharedPrefrence or else if the data is more you can use sqlite
/**
* method to set the login status for the application
*
* #param context
* #param status
*/
public static void setLoginStatus(Context context, int status) {
sharedPreferences = context.getSharedPreferences(PREFERENCE_NAME, Activity.MODE_PRIVATE);
Editor editor = sharedPreferences.edit();
editor.putInt(KEY_LOGIN_STATUS, status);
editor.apply();
}
NOTE :
About that its totally on your choice what you use to save the current
state of user , i will prefer using shared preferences. And for signup
and sign in use SQLite database. Shared preferences are commonly used
to perform light operations. You can search through data in SQLite as
you may have many users.
So use SQLite to register and login and then use shared preferences to
save tha current state of user.
Sqlite is always a better option to store the data there you can manage in proper format and you can encrypt as well.
I would suggest, you should use sharedPreferences for saving the login details and i suppose whatever request you are storing, contains more data, so save your requests in SQLite.
Here is some good details about theme :
Pros and Cons of SQLite and Shared Preferences
SQLite
Large amounts of same structured data should be stored in a SQLite
database as databases are designed for this kind of data. As the data
is structured and managed by the database, it can be queried to get a
sub set of the data which matches certain criteria using a query
language like SQL. This makes it possible to search in the data. Of
course managing and searching large sets of data influences the
performance so reading data from a database can be slower than reading
data from SharedPreferences.
SharedPreferences
SharedPreferences is a key/value store where you can save a data under
certain key. To read the data from the store you have to know the key
of the data. This makes reading the data very easy. But as easy as it
is to store a small amount of data as difficult it is to store and
read large structured data as you need to define key for every single
data, furthermore you cannot really search within the data except you
have a certain concept for naming the keys.
According to the Size or Format of your data you can choose one, for login information I suggest using SharedPreferences