I'm a bit confused on when should I use a room database instead of SharedPreferences or DataStore.
In my case I have an apps that let the user login and currently I store the logged in user data (followers, age, etc.) in a SharedPreferences, is this the correct approach for this kind of case? Should I just create a Room implementation for storing said user data? Thank you
First you need to understand the nature of these two things.
Room DB is schema so you will need to define every properties before you can use it. Such as table name, column name etc.
As it is a DB, you can easily perform a partial update on the corresponding table.
While Shared Prefs is just a key value pair in a xml file.
You insert age as key and 25 as value and that's all.
Even you can use GSON to convert the object to a JSON and store it as plain text like a non SQL DB:
key = login-data, value = {"follower": "sskrts", "age": 25}
Decision
If it just a simple login session data, then I will recommend to use Shared Prefs to cache the data. It is a simpler implementation.
If you are going to store a table of data instead, both works fine, at least in my use case experience. So it will more depends on your preference of schema or non schema DB.
Note that both storage seem to have NO encryption so don't store raw credential info there.
Related
In my android app I have about 100 places (maximum will be 200). I want to allow the user to mark each place as visited and store this selection.
So the user can mark/unmark that he already visited some places/cities.
Is it a good idea if I store the values as SharedPreference?
My code:
SharedPreferences sharedPref = getActivity().getPreferences(Context.MODE_PRIVATE);
SharedPreferences.Editor editor = sharedPref.edit();
editor.putString("London", "1");
editor.commit();
and next time when user marks another place then:
editor.putString("Paris", "1");
I am asking due to amount of possible places to be stored there, which will be maximum 200 in my case. I am usually using this kind of storage just to store some settings or so, but I think this is an easy way to store the values in my case too, I don't want to use database or anything similar for storage.
Whether this is a good idea or not depends on your requirements and expectations. If you store the data like this, it will work for sure, but, there will be some limitations:
It might be complicated to show a list of places to the user. If you store some other data to shared preferences you will need a way to distinguish places from other data. In this case you'll probably need to add a prefix to all your keys, such as "place_London", "place_Paris", etc.
You are relying on English key names so you might have issues with localization if you support other languages
It will be much harder to support versioning and scalability. E.g. if later you have an entity called "Place" and it has more information than just a name with a flag, then it will be much harder to keep it in shared preferences. E.g. if at some point you want to add a corresponding country name to all places, what do you do?
I think in this scenario you actually DO want to use database. It will pay off.
SharedPreferences is a key/value way to save data. I think it is not appropriate to save large amount of structured data as you have to define a key for each value you have.
Using SQLite might be a better option for your case.
You should switch to a more reliable way of storing data in storage instead of using SharedPreferences.
Sqlite is good option but if you don't like to write SQL Queries and want a solution where you want to store data in your storage, Realm is an amazing alternative.
Although before implementing please read more on the pros and cons of using realm. You can read more about Realm here :-
realm.io
Realm vs Room vs ObjectBox
I am a beginner to android eclipse. I am trying to do one simple application which is to register information in online and receive the same information while searching on the same application who interested to see that information
kindly guide me for this.
Shared Preferences :
You can use SharedPreferences to save any primitive data: booleans, floats, ints, longs, and strings. This data will persist across user sessions (even if your application is killed).
Sqlite
SQLite is an Open Source database. SQLite supports standard relational database features like SQL syntax, transactions and prepared statements. The database requires limited memory at runtime (approx. 250 KByte) which makes it a good candidate from being embedded into other runtimes.
SQLite supports the data types TEXT (similar to String in Java), INTEGER (similar to long in Java) and REAL (similar to double in Java). All other types must be converted into one of these fields before getting saved in the database. SQLite itself does not validate if the types written to the columns are actually of the defined type, e.g. you can write an integer into a string column and vice versa.
SQLite will allow you to store persistent data in a very structured way. It's usually used to store data models that your application needs to work with. For example, you make an application that is intended to show car details locally. Those cars should be stored in a SQLite database.
SharedPreferences allow you to store vars that are needed for your application and that should be saved even when the application is closed. For example, Shared Preferences will allow you to save mainly all the preferences of the user (should the application use sound, should it vibrate....).
Currently I have a text file where I store username/password on to a text file!
I want to store hashmap of username->{password,other user info}.
This is just initial prototype, finally I will use a SQL database to store these values.
I did some google searches and people are mostly talking about connecting to sql database, is it easier than attemping to store it temporarily ?
You might try marshalling/unmarshalling the data as JSON using a library like GSON. The data would be stored on disk. This approach will be lighter weight than SQLite for your prototype and shouldn't require too much throwaway code.
I am thinking about using Google App Engine.
For my project I will need several data stored in different databases. From what I've been reading so far AppEngine only provides one database to store and track users.
My problem is I need to have multiple databases to store the same data but store only the data related to its criteria.
Is AppEngine the way to go for this? Its a android app I will be using by the way.
Or should I have my own server? If so what would I need to implement?
Can you explain, why you need more than one database.
You can use namespaces to create a multitenancy environment.
https://developers.google.com/appengine/docs/python/multitenancy/multitenancy
Each entity you define (see https://developers.google.com/appengine/docs/python/datastore/entities) is conceptually like a table -- the entity's fields are the equivalent of columns in a table.
So after reading the documentation in the link #Moishe supplied in his answer, i figured out the answer.
I just thought i would post an answer here to save someone some time in the future.
Here is a class called employees that accepts App engines Datastore parameters.
//Class name Employee
class Employee(db.Model):
//Employee information we want to enter into the Employee entity.
first_name = db.StringProperty()
last_name = db.StringProperty()
hire_date = db.DateProperty()
attended_hr_training = db.BooleanProperty()
//Set employees information to the Database Model to be inserted into the Datastore.
employee = Employee(first_name='Antonio',
last_name='Salieri')
employee.hire_date = datetime.datetime.now().date()
employee.attended_hr_training = True
//Like committ..this initiates the insertion of the information you put into the database store mode. This works sorta like androids bundle or SharedPreference you put the information into the datastore and then committ it or save it.
employee.put()
I have the following data tuple describing the user of my application:
(userID, name, email, contact number)
and I want to access this data frequently throughout my application. I have a contacts table in my database in which tuples of this type are stored to describe other contacts. The reason I don't want to store the tuple describing the user is because it seems wasteful to have an attribute to mark which data is "self", and also I use the table directly for inviting users, so I don't want users to see themselves on the list of contacts! I thought about using shared preferences to store "self", but I may decide to include more data in the future, and piecing together a tuple from several key:value lookups seems like a very messy solution. What's the best way to store these "shards" of data so they're easily accessible and not wasteful?
Thank you :)
try Shared Preferences
http://developer.android.com/guide/topics/data/data-storage.html#pref
Here are your choices for storing data:
Android Data Storage
I would try using the external file if you don't want to use shared preferences or a database. XML and JSON files are both good choices that can be easily parsed. If you try a JSON file you could access it using GSON in your code.
Another option is to create a subclass of Application which has fields (and get/set methods) for your variables. Use this class in your <application> tag in the manifest. Then use e.g. ((MyApplication)getApplicationContext()).getUserId()
If the fields are static you might find they persist across application instances. I haven't tried this though.