I am looking to store simple variables so that if the app process is stopped the data will still be available when it relaunches. I looked into extending the Application class and sharedPreferences. To me, it seems that extending Application is good for temporary global variables that are deleted when the app process is stopped. sharedPreferences however saves the variable onto a file so that is is always available. What are the differences between the two, and what are their optimal uses? Also, what is the best for storing variables that you want to keep even if the app is stopped?
When your app's process is killed, any data stored in the Application class will be lost. You should only use that for storing data that is not needed across multiple launches and uses of your app.
For storing simple data like highscores, sound preference, showing a dialog at startup preference, your best bet would be SharedPreferences. For more comprehensive data, like a list of purchases made by an user in your app, or notes in a todo list app, you should use an SQLite Database.
Beyond that, if you want to store files like PDFs etc. or images (images can also be saved into a database), you can use the internal storage or the external storage (may be an SD Card, or a partition on the internal storage). Please keep in mind that on most devices, internal storage is very limited and you shouldn't save excessively large file there.
This part of the documentation should help you with storage options.
Related
The android documentation has the following options below but does not explain what circumstances each is best for. What are the pros and cons of each method? e.g. Under what conditions would SQL be better than Shared Preferences?
Shared Preferences
Internal Storage
External Storage
SQLite Databases
Network Connection
Different Storage options in Android
Content Providers
Consider the structured data added to the device from application1 is
not accessible to another application2 present in the same device but
the profile photo added to the device by application1 is available to
the application2 running in the same device
Consider android device as a city, the applications in it are the
houses in the city, people in the houses(application) are the data.
Now content provider is like an broker in the city(android device).
This broker provide access for the people in the city for finding
different houses referring as the content provider in the android
device provide access for the data in the device for different
applications.
Shared Preferences
Consider I have an App say a Face book App which I use to log in to
my account.
Now the very first time I enter my username and password to get
access to my account. Say I log out of the application an hour later
again I use the same Face book App to login again to my application.
I have to enter username and password again to login to my account
and I set a theme to my application and other settings on how my app
looks in my current phone
This is un-necessary because consider I am using my phone to login to
the application. So I will always use my phone to login again and
again, thus entering my credentials again and again is more work
shows it’s not a user friendly app
Shared Preferences is very handy in such scenarios where I can use
its feature to share my data in a xml file Which physically exists in
the Android app installed in my phone which is not destroyed even if
the app is closed. Here we can save user preferences data of the
current application.
As a result next time I open my app in my phone I can see the data
automatically filled in the necessary fields and the settings are
File Storage
In Android we can use the device storage space to store the data in
it for the applications. The type of data involves things such as a
text file, image file, video file, audio file etc.
As seen in the figure as we can see that there are two places we can
do this. One way is to write the raw files into primary /secondary
storage. Another way is to write the cache files into the
primary/secondary storage.
There is also difference between storing raw data and the cache data,
the raw data once stored in memory by user has to be explicitly
deleted by the user explicitly otherwise it would exist till then.
Cache data stored in memory is not a permanent data because the
system automatically deletes it if it feels there is shortage of
memory.
Internal Storage:
Consider a user in an application has stored data in internal
storage, then only that user of that application has access to that
data on the mobile and that data is automatically deleted when the
user uninstalls the application. Speaking of which internal memory is
private.
The apps internal storage directory is stored using the name package
name in a special place in the android file system.
Other apps or users of current app have no access to the file set by
a particular user and a particular app unless it is explicitly made
available to the user for readable/writable access.
SQLite
Sqlite is used to store more structured data locally in a mobile
where the android app is running. Structured data involves as of
which shown in the figure like a student’s information in the form of
rows and columns.
Sqlite offers similar functionality like Mysql and oracle but with
limited functional features. Some of the things involve performing
query operations on tables. There are features though like creating
views but also some features are not available like stored procedure.
Sqlite is very helpful in storing complex and large data which can be
downloaded once and can be used again and again until the application
is running. When the application is closed the sqlite database is
also destroyed.
Putting all the pieces together
Shared preferences are good for storing ... an application's preferences, and other small bits of data. It's a just really simple persistent string key store for a few data types: boolean, float, int, long and string. So for instance if my app had a login, I might consider storing the session key as string within SharedPreferences.
Internal storage is good for storing application data that the user doesn't need access to, because the user cannot easily access internal storage. Possibly good for caching, logs, other things. Anything that only the app intends to Create Read Update or Delete.
External storage. Great for the opposite of what I just said. The dropbox app probably uses external storage to store the user's dropbox folder, so that the user has easy access to these files outside the dropbox application, for instance, using the file manager.
SQLite databases are great whenever you are going to use a lot of structured data and a relatively rigid schema for managing it. Put in layman's terms, SQLite is like MySQL or PostgreSQL except instead of the database acting as a server daemon which then takes queries from the CGI scripts like php, it is simply stored in a .db file, and accessed and queried through a simple library within the application. While SQLite cannot scale nearly as big as the dedicated databases, it is very quick and convenient for smaller applications, like Android apps. I would use an SQLite db if I were making an app for aggregating and downloading recipes, since that kind of data is relatively structured and a database would allow for it to scale well. Databases are nice because writing all of your data to a file, then parsing it back in your own proprietary format it no fun. Then again, storing data in XML or JSON wouldn't be so bad.
Network connection refers to storing data on the cloud. HTTP or FTP file and content transfers through the java.net.* packages makes this happen.
SharedPreferences is mainly for application-specific settings that you can access via your Settings menu - like application settings. It's a good idea to keep everything simple here - mostly boolean flags, short strings, or integers. SharedPreferences data persist on device reboot, and are removed along with app uninstallation. Data is saved as a key-value pair.
Internal Storage is mostly used for larger non-persistent data storage. You utilize internal storage if you want to process an image, a short video clip, a large text file, etc. But you don't store the processed data in the internal storage - its function is more like a CPU's RAM. The amount of available internal storage for your application depends on the device, but it's always a good idea to keep anything under 1MB. Data is referenced via its file path.
External Storage does not only refer to the SDCard storage, but for higher-end phones, this can mean internal mountable storage (like in the Galaxy Nexus or S2). This is where you store the large video files, the high-resolution images, and the 20-megabyte text file you want to parse in your application. This is also a place to store data that you want shared across devices if you swap sd cards. Data is also referenced via its file path.
SQLite Databases is where you'd store pretty much anything you want in a regular database - with the advantage of organizing things into tables, rows, and columns. It works best with things that you want displayed in the UI as lists - the best example would be the great invention knows as the CursorAdapter. Data stored here also persist on device reboot, and are removed with app uninstallation. You can also share data across applications with sqlite db if you hook it up to a ContentProvider. Data is accessed using a Cursor, where you can call methods as if you're executing sql statements.
Network Connection is not really a data storage technique, but can be a way of persisting data for a specific user provided the device is connected to the internet, using some sort of authentication. You have to balance out between downloading data every time the app needs it, or having a one-time data sync, which would ultimately lead to another of the storage options mentioned above.
Shared preferences are key/value pairs, nothing more. So if you want to keep track of say, students and their test score, it really won't work well for that.
A database is just that, a database. You can define as many columns (and tables) as you need to get the job done.
If it's preferences for your app, use shared preferences (almost any preference I can think of can be done that way), if it's anything else more complicated, use a database.
The android documentation has the following options below but does not explain what circumstances each is best for. What are the pros and cons of each method? e.g. Under what conditions would SQL be better than Shared Preferences?
Shared Preferences
Internal Storage
External Storage
SQLite Databases
Network Connection
Different Storage options in Android
Content Providers
Consider the structured data added to the device from application1 is
not accessible to another application2 present in the same device but
the profile photo added to the device by application1 is available to
the application2 running in the same device
Consider android device as a city, the applications in it are the
houses in the city, people in the houses(application) are the data.
Now content provider is like an broker in the city(android device).
This broker provide access for the people in the city for finding
different houses referring as the content provider in the android
device provide access for the data in the device for different
applications.
Shared Preferences
Consider I have an App say a Face book App which I use to log in to
my account.
Now the very first time I enter my username and password to get
access to my account. Say I log out of the application an hour later
again I use the same Face book App to login again to my application.
I have to enter username and password again to login to my account
and I set a theme to my application and other settings on how my app
looks in my current phone
This is un-necessary because consider I am using my phone to login to
the application. So I will always use my phone to login again and
again, thus entering my credentials again and again is more work
shows it’s not a user friendly app
Shared Preferences is very handy in such scenarios where I can use
its feature to share my data in a xml file Which physically exists in
the Android app installed in my phone which is not destroyed even if
the app is closed. Here we can save user preferences data of the
current application.
As a result next time I open my app in my phone I can see the data
automatically filled in the necessary fields and the settings are
File Storage
In Android we can use the device storage space to store the data in
it for the applications. The type of data involves things such as a
text file, image file, video file, audio file etc.
As seen in the figure as we can see that there are two places we can
do this. One way is to write the raw files into primary /secondary
storage. Another way is to write the cache files into the
primary/secondary storage.
There is also difference between storing raw data and the cache data,
the raw data once stored in memory by user has to be explicitly
deleted by the user explicitly otherwise it would exist till then.
Cache data stored in memory is not a permanent data because the
system automatically deletes it if it feels there is shortage of
memory.
Internal Storage:
Consider a user in an application has stored data in internal
storage, then only that user of that application has access to that
data on the mobile and that data is automatically deleted when the
user uninstalls the application. Speaking of which internal memory is
private.
The apps internal storage directory is stored using the name package
name in a special place in the android file system.
Other apps or users of current app have no access to the file set by
a particular user and a particular app unless it is explicitly made
available to the user for readable/writable access.
SQLite
Sqlite is used to store more structured data locally in a mobile
where the android app is running. Structured data involves as of
which shown in the figure like a student’s information in the form of
rows and columns.
Sqlite offers similar functionality like Mysql and oracle but with
limited functional features. Some of the things involve performing
query operations on tables. There are features though like creating
views but also some features are not available like stored procedure.
Sqlite is very helpful in storing complex and large data which can be
downloaded once and can be used again and again until the application
is running. When the application is closed the sqlite database is
also destroyed.
Putting all the pieces together
Shared preferences are good for storing ... an application's preferences, and other small bits of data. It's a just really simple persistent string key store for a few data types: boolean, float, int, long and string. So for instance if my app had a login, I might consider storing the session key as string within SharedPreferences.
Internal storage is good for storing application data that the user doesn't need access to, because the user cannot easily access internal storage. Possibly good for caching, logs, other things. Anything that only the app intends to Create Read Update or Delete.
External storage. Great for the opposite of what I just said. The dropbox app probably uses external storage to store the user's dropbox folder, so that the user has easy access to these files outside the dropbox application, for instance, using the file manager.
SQLite databases are great whenever you are going to use a lot of structured data and a relatively rigid schema for managing it. Put in layman's terms, SQLite is like MySQL or PostgreSQL except instead of the database acting as a server daemon which then takes queries from the CGI scripts like php, it is simply stored in a .db file, and accessed and queried through a simple library within the application. While SQLite cannot scale nearly as big as the dedicated databases, it is very quick and convenient for smaller applications, like Android apps. I would use an SQLite db if I were making an app for aggregating and downloading recipes, since that kind of data is relatively structured and a database would allow for it to scale well. Databases are nice because writing all of your data to a file, then parsing it back in your own proprietary format it no fun. Then again, storing data in XML or JSON wouldn't be so bad.
Network connection refers to storing data on the cloud. HTTP or FTP file and content transfers through the java.net.* packages makes this happen.
SharedPreferences is mainly for application-specific settings that you can access via your Settings menu - like application settings. It's a good idea to keep everything simple here - mostly boolean flags, short strings, or integers. SharedPreferences data persist on device reboot, and are removed along with app uninstallation. Data is saved as a key-value pair.
Internal Storage is mostly used for larger non-persistent data storage. You utilize internal storage if you want to process an image, a short video clip, a large text file, etc. But you don't store the processed data in the internal storage - its function is more like a CPU's RAM. The amount of available internal storage for your application depends on the device, but it's always a good idea to keep anything under 1MB. Data is referenced via its file path.
External Storage does not only refer to the SDCard storage, but for higher-end phones, this can mean internal mountable storage (like in the Galaxy Nexus or S2). This is where you store the large video files, the high-resolution images, and the 20-megabyte text file you want to parse in your application. This is also a place to store data that you want shared across devices if you swap sd cards. Data is also referenced via its file path.
SQLite Databases is where you'd store pretty much anything you want in a regular database - with the advantage of organizing things into tables, rows, and columns. It works best with things that you want displayed in the UI as lists - the best example would be the great invention knows as the CursorAdapter. Data stored here also persist on device reboot, and are removed with app uninstallation. You can also share data across applications with sqlite db if you hook it up to a ContentProvider. Data is accessed using a Cursor, where you can call methods as if you're executing sql statements.
Network Connection is not really a data storage technique, but can be a way of persisting data for a specific user provided the device is connected to the internet, using some sort of authentication. You have to balance out between downloading data every time the app needs it, or having a one-time data sync, which would ultimately lead to another of the storage options mentioned above.
Shared preferences are key/value pairs, nothing more. So if you want to keep track of say, students and their test score, it really won't work well for that.
A database is just that, a database. You can define as many columns (and tables) as you need to get the job done.
If it's preferences for your app, use shared preferences (almost any preference I can think of can be done that way), if it's anything else more complicated, use a database.
I have a quiz app that shuffles everytime it is run. What is the most elegant way of saving a game state locally so that my user can resume the quiz using the same ordered list as before, as well as other primitives such as score, level, life points, etc.
I already have a bundle that saves this state when the game is paused. How can I retain the state when my activity is destroyed.
I know of shared preferences, but there must be something more elegant?
I think we need to understand firstly that there is several possibilities to save data in your app (with possibility to re-enter application and restore data):
1) Save on disc (it fast, but you can erase this data, for example, when reinstall application)
2) Save on remote disc (it slow, but it will keep your game progress throug removing and reinstalling app).
So first of all you need to choose one of this possibilities. I think in your case it will be enough to keep changes locally on disc (besides remote storage cost some additional $$)
In first possibility there are several variants to implement it:
- through shared preferences
- through saving in file (internal storage)
- through saving in file (external storage)
- through keeping data in database
I think last variant is not for you, since you want to just save state of game.
And 'external storage' variant is not for you, too, because game state is private data of your application.
So you need to choose between shared preferences and internal storrage.
In this dilemma, you can think about what you like more. For me shared preferences provides convenient and async way to save data, which is more preferable in game. But you need to think about how many data you want to keep.
If it's not big, choose Shared preferences. And if you do enance your way to save in SharedPreferences (write less code and make it more readable), you can import Gson or Jackson library. Then pick out special GameState class for your game and just convert it to json string and save. Same for restoring. Pick string from prefs and parse it to GameState. That's all.
Hope it helps. :)
I suggest you to use a database and a cursor for retrieving the huge data list. https://developer.android.com/training/basics/data-storage/databases.html
SQLite is very fast and not hard to implement.
Im saving datas from my db/user into a gson formated ArrayList in SharedPreferences. Now my question :
Is it safe to save these datas (or data in general) into Sharedpreferences. Are users able to read these gson Arraylists out ? Maybe from SD card ,in a folder or somewhere else.
Thank you !
They are stored as xml files in your app directory, with permissions that allow only your app to access them. But on rooted device they are easily accessible. If you are concerned with security then you may use encryption, those projects might be usefull to you:
https://github.com/rtoshiro/SecureSharedPreferences
https://github.com/sveinungkb/encrypted-userprefs
still those projects does not give you 100% guarantee, hacker may decompile your apk and find keys used to encrypt shared preferences. So if your data is of use only for short time then remember to remove it from your device once user has finished using it. You may for example keep data on server and download it only when needed, caching locally only for short time - when its needed.
SharedPreferences is just a file located in phone private memory. So user can't access it but root can. Root can everything and many users have root's nowadays. You shouldn't store fragile data there
Android SharedPreference security
You can read all shared preferences Data
The SharedPreferences class provides a general framework that allows
you to save and retrieve persistent key-value pairs of primitive data
types.
To see the information in the store you need to know the important thing from the data. This will make reading through the information super easy. But as simple as it's to keep a tiny bit of data as difficult it's to keep and browse large structured data since you need to define key for every data, in addition you can't really search inside the data except you've got a certain concept for naming the secrets.
Please read Android SharedPreference security
After reading the documention it seems that onSaveInstanceStaate works per instance (as the name suggests). I am just wondering what the preffered method of storing data is so that it is available for all instances of that activity?
As MaciejGorski mentioned in his comment, there are different levels of data storage available in Android:
Shared preferences
Internal storage
External storage
SQLite database
Network
From personal experience, the lower you go down this list, the more complicated your implementation will become. Thus, if you are simply trying to save simple data for your app to be shared among different instances of an activity (or of multiple activities), shared preferences are certainly the way to go. You can even create private shared preferences, which only your app can access.
In any case, check out this SO answer for how to implement them: How to use SharedPreferences in Android to store, fetch and edit values