We Keep Coding

Can I combine SharedPreferences and Firestore when saving data?

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

Is SharedPreferences necessary for all data?

I am new in Android.
I have a database like this.
I used SharedPreferences for remember user information.
However, there is a point that I do not understand. When the user logins the application, do I need to save all Firebase data in SharedPreference for the application to remember the user?
Which type of datas save in SharedPreference? I just want, If a user logins the application, my application will remember the user and its checkboxes, comments, likes or something else.
It might be a stupid question, but I am new in this. Thank you for all.

Yes you can use sharedPreferences for this purpose. You can save int, String, boolean, float, double... in sharedPreferences.
You need to save user information in sharedPreferences on login.

You can use SharedPreferences to save values. Make a model and the using Gson save all the values in one string instead of saving seperately.

Necessity of storing variables in Firebase Database

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.

Sqlite or sharedpreference is suitable for my application

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

Which option is faster using Intents in Android - SQLite index or Parcelable object?

I was wondering as I am now writing app using SQLite database also sending some informations between activities. What is faster and better:
Using SQLite and send to Activity only record (object) index and in this Activity open, and read data
Using Parelable with Intent and send like this object. In Activity read data from Parcelable object.
I am only talking about option when object is only read. Now write, edited or in any other way modified.
What is you opinion?

You'd need to benchmark to verify, but I suspect that using a Parcelable is faster. It can be done entirely in memory and doesn't need to flush to storage. Writing to SQLite requires that the data be flushed to wherever the SQLite data base is stored, which can take a significant amount of time. Reads can also be slow. (This is why StrictMode mode will normally alert about SQLite writes on the UI thread.)