1. Android 4: Saving Data
Kirk Scott

2. Oropendola

4. Introduction
Most Android apps need to save data, even if only to save information about the app state during onPause() so the user's progress is not lost.
Most non-trivial apps also need to save user settings, and some apps must manage large amounts of information in files and databases.

5. This class introduces you to the principal data storage options in Android, including:
Saving key-value pairs of simple data types in a shared preferences file
Saving arbitrary files in Android's file system
Using databases managed by SQLite

6. Outline 4.1 Saving Key-Value Sets 4.2 Saving Files
4.3 Saving Data in SQL Databases

7. 4.1 Saving Key-Value Sets

8. If you have a relatively small collection of key-values that you'd like to save, you should use the SharedPreferences APIs.
A SharedPreferences object points to a file containing key-value pairs and provides simple methods to read and write them.
Each SharedPreferences file is managed by the framework and can be private or shared.

9. This class shows you how to use the SharedPreferences APIs to store and retrieve simple values.

10. Note: The SharedPreferences APIs are only for reading and writing key-value pairs and you should not confuse them with the Preference APIs, which help you build a user interface for your app settings (although they use SharedPreferences as their implementation to save the app settings).
For information about using the Preference APIs, see the Settings guide.

11. Get a Handle to a SharedPreferences
You can create a new shared preference file or access an existing one by calling one of two methods:
getSharedPreferences() — Use this if you need multiple shared preference files identified by name, which you specify with the first parameter.
You can call this from any Context in your app.

12. getPreferences() — Use this from an Activity if you need to use only one shared preference file for the activity.
Because this retrieves a default shared preference file that belongs to the activity, you don't need to supply a name.

13. For example, the following code is executed inside a Fragment.
It accesses the shared preferences file that's identified by the resource string R.string.preference_file_key and opens it using the private mode so the file is accessible by only your app.

14. Context context = getActivity();
SharedPreferences sharedPref = context.getSharedPreferences(
getString(R.string.preference_file_key), Context.MODE_PRIVATE);

15. When naming your shared preference files, you should use a name that's uniquely identifiable to your app, such as "com.example.myapp.PREFERENCE_FILE_KEY"
Alternatively, if you need just one shared preference file for your activity, you can use the getPreferences() method:

16. SharedPreferences sharedPref = getActivity(). getPreferences(Context
SharedPreferences sharedPref = getActivity().getPreferences(Context.MODE_PRIVATE);

17. Caution: If you create a shared preferences file with MODE_WORLD_READABLE or MODE_WORLD_WRITEABLE, then any other apps that know the file identifier can access your data.

18. Write to Shared Preferences
To write to a shared preferences file, create a SharedPreferences.Editor by calling edit() on your SharedPreferences.
Pass the keys and values you want to write with methods such as putInt() and putString(). Then call commit() to save the changes. For example:

19. SharedPreferences sharedPref = getActivity(). getPreferences(Context
SharedPreferences sharedPref = getActivity().getPreferences(Context.MODE_PRIVATE);
SharedPreferences.Editor editor = sharedPref.edit();
editor.putInt(getString(R.string.saved_high_score), newHighScore);
editor.commit();

20. Read from Shared Preferences
To retrieve values from a shared preferences file, call methods such as getInt() and getString(), providing the key for the value you want, and optionally a default value to return if the key isn't present. For example:

21. SharedPreferences sharedPref = getActivity(). getPreferences(Context
SharedPreferences sharedPref = getActivity().getPreferences(Context.MODE_PRIVATE);
int defaultValue = getResources().getInteger(R.string.saved_high_score_default);
long highScore = sharedPref.getInt(getString(R.string.saved_high_score), defaultValue);

22. 4.2 Saving Files

23. Android uses a file system that's similar to disk-based file systems on other platforms.
This lesson describes how to work with the Android file system to read and write files with the File APIs.

24. A File object is suited to reading or writing large amounts of data in start-to-finish order without skipping around.
For example, it's good for image files or anything exchanged over a network.

25. This lesson shows how to perform basic file-related tasks in your app.
The lesson assumes that you are familiar with the basics of the Linux file system and the standard file input/output APIs in java.io.

26. Choose Internal or External Storage
All Android devices have two file storage areas: "internal" and "external" storage.
These names come from the early days of Android, when most devices offered built-in non-volatile memory (internal storage), plus a removable storage medium such as a micro SD card (external storage).

27. Some devices divide the permanent storage space into "internal" and "external" partitions, so even without a removable storage medium, there are always two storage spaces and the API behavior is the same whether the external storage is removable or not.
The following lists summarize the facts about each storage space.

28. Internal storage: It's always available.
Files saved here are accessible by only your app.
When the user uninstalls your app, the system removes all your app's files from internal storage.
Internal storage is best when you want to be sure that neither the user nor other apps can access your files.

29. Note: Before Android 7.0 (API level 24), internal files could be made accessible to other apps by means of relaxing file system permissions.
This is no longer the case.
If you wish to make the content of a private file accessible to other apps, your app may use the FileProvider.
See Sharing Files.

30. External storage:
It's not always available, because the user can mount the external storage as USB storage and in some cases remove it from the device.
It's world-readable, so files saved here may be read outside of your control.

31. When the user uninstalls your app, the system removes your app's files from here only if you save them in the directory from getExternalFilesDir().
External storage is the best place for files that don't require access restrictions and for files that you want to share with other apps or allow the user to access with a computer.

32. Tip: Although apps are installed onto the internal storage by default, you can specify the android:installLocation attribute in your manifest so your app may be installed on external storage.
Users appreciate this option when the APK size is very large and they have an external storage space that's larger than the internal storage.
For more information, see App Install Location.

33. Obtain Permissions for External Storage
To write to the external storage, you must request the WRITE_EXTERNAL_STORAGE permission in your manifest file:
<manifest ...>
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
...
</manifest>

34. Caution: Currently, all apps have the ability to read the external storage without a special permission.
However, this will change in a future release.
If your app needs to read the external storage (but not write to it), then you will need to declare the READ_EXTERNAL_STORAGE permission.

35. To ensure that your app continues to work as expected, you should declare this permission now, before the change takes effect.
<manifest ...>
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
...
</manifest>

36. However, if your app uses the WRITE_EXTERNAL_STORAGE permission, then it implicitly has permission to read the external storage as well.
You don’t need any permissions to save files on the internal storage.
Your application always has permission to read and write files in its internal storage directory.

37. Save a File on Internal Storage
When saving a file to internal storage, you can acquire the appropriate directory as a File by calling one of two methods:
getFilesDir()
Returns a File representing an internal directory for your app.

38. getCacheDir()
Returns a File representing an internal directory for your app's temporary cache files.

39. Be sure to delete each file once it is no longer needed and implement a reasonable size limit for the amount of memory you use at any given time, such as 1MB.
If the system begins running low on storage, it may delete your cache files without warning.

40. To create a new file in one of these directories, you can use the File() constructor, passing the File provided by one of the above methods that specifies your internal storage directory. For example:
File file = new File(context.getFilesDir(), filename);

41. Alternatively, you can call openFileOutput() to get a FileOutputStream that writes to a file in your internal directory.
For example, here's how to write some text to a file:

42. String filename = "myfile";
String string = "Hello world!";
FileOutputStream outputStream;
try {
outputStream = openFileOutput(filename, Context.MODE_PRIVATE);
outputStream.write(string.getBytes());
outputStream.close();
} catch (Exception e) {
e.printStackTrace(); }

43. Or, if you need to cache some files, you should instead use createTempFile().
For example, the following method extracts the file name from a URL and creates a file with that name in your app's internal cache directory:

44. public File getTempFile(Context context, String url) {
File file;
try {
String fileName = Uri.parse(url).getLastPathSegment();
file = File.createTempFile(fileName, null, context.getCacheDir());
} catch (IOException e) {
// Error while creating file }
return file;

45. Note: Your app's internal storage directory is specified by your app's package name in a special location of the Android file system.
Technically, another app can read your internal files if you set the file mode to be readable.
However, the other app would also need to know your app package name and file names.

46. Other apps cannot browse your internal directories and do not have read or write access unless you explicitly set the files to be readable or writable.
So as long as you use MODE_PRIVATE for your files on the internal storage, they are never accessible to other apps.

47. Save a File on External Storage
Because the external storage may be unavailable—such as when the user has mounted the storage to a PC or has removed the SD card that provides the external storage—you should always verify that the volume is available before accessing it.

48. You can query the external storage state by calling getExternalStorageState().
If the returned state is equal to MEDIA_MOUNTED, then you can read and write your files.
For example, the following methods are useful to determine the storage availability:

49. /* Checks if external storage is available for read and write */
public boolean isExternalStorageWritable() {
String state = Environment.getExternalStorageState();
if (Environment.MEDIA_MOUNTED.equals(state)) {
return true; }
return false;

50. /* Checks if external storage is available to at least read */
public boolean isExternalStorageReadable() {
String state = Environment.getExternalStorageState();
if (Environment.MEDIA_MOUNTED.equals(state) ||
Environment.MEDIA_MOUNTED_READ_ONLY.equals(state)) {
return true; }
return false;

51. Although the external storage is modifiable by the user and other apps, there are two categories of files you might save here:

52. 1. Public files
Files that should be freely available to other apps and to the user.
When the user uninstalls your app, these files should remain available to the user.
For example, photos captured by your app or other downloaded files.

53. 2. Private files
Files that rightfully belong to your app and should be deleted when the user uninstalls your app.
Although these files are technically accessible by the user and other apps because they are on the external storage, they are files that realistically don't provide value to the user outside your app.

54. When the user uninstalls your app, the system deletes all files in your app's external private directory.
For example, additional resources downloaded by your app or temporary media files.

55. If you want to save public files on the external storage, use the getExternalStoragePublicDirectory() method to get a File representing the appropriate directory on the external storage.

56. The method takes an argument specifying the type of file you want to save so that they can be logically organized with other public files, such as DIRECTORY_MUSIC or DIRECTORY_PICTURES.
For example:

57. public File getAlbumStorageDir(String albumName) {
// Get the directory for the user's public pictures directory.
File file = new File(Environment.getExternalStoragePublicDirectory(
Environment.DIRECTORY_PICTURES), albumName);
if (!file.mkdirs()) {
Log.e(LOG_TAG, "Directory not created"); }
return file;

58. If you want to save files that are private to your app, you can acquire the appropriate directory by calling getExternalFilesDir() and passing it a name indicating the type of directory you'd like.

59. Each directory created this way is added to a parent directory that encapsulates all your app's external storage files, which the system deletes when the user uninstalls your app.
For example, here's a method you can use to create a directory for an individual photo album:

60. public File getAlbumStorageDir(Context context, String albumName) {
// Get the directory for the app's private pictures directory.
File file = new File(context.getExternalFilesDir(
Environment.DIRECTORY_PICTURES), albumName);
if (!file.mkdirs()) {
Log.e(LOG_TAG, "Directory not created"); }
return file;

61. If none of the pre-defined sub-directory names suit your files, you can instead call getExternalFilesDir() and pass null.
This returns the root directory for your app's private directory on the external storage.

62. Remember that getExternalFilesDir() creates a directory inside a directory that is deleted when the user uninstalls your app.

63. If the files you're saving should remain available after the user uninstalls your app—such as when your app is a camera and the user will want to keep the photos—you should instead use getExternalStoragePublicDirectory().

64. Regardless of whether you use getExternalStoragePublicDirectory() for files that are shared or getExternalFilesDir() for files that are private to your app, it's important that you use directory names provided by API constants like DIRECTORY_PICTURES.

65. These directory names ensure that the files are treated properly by the system.
For instance, files saved in DIRECTORY_RINGTONES are categorized by the system media scanner as ringtones instead of music.

66. Query Free Space
If you know ahead of time how much data you're saving, you can find out whether sufficient space is available without causing an IOException by calling getFreeSpace() or getTotalSpace().

67. These methods provide the current available space and the total space in the storage volume, respectively.
This information is also useful to avoid filling the storage volume above a certain threshold.

68. However, the system does not guarantee that you can write as many bytes as are indicated by getFreeSpace().
If the number returned is a few MB more than the size of the data you want to save, or if the file system is less than 90% full, then it's probably safe to proceed.
Otherwise, you probably shouldn't write to storage.

69. Note: You aren't required to check the amount of available space before you save your file.
You can instead try writing the file right away, then catch an IOException if one occurs.
You may need to do this if you don't know exactly how much space you need.

70. For example, if you change the file's encoding before you save it by converting a PNG image to JPEG, you won't know the file's size beforehand.

71. Delete a File You should always delete files that you no longer need.
The most straightforward way to delete a file is to have the opened file reference call delete() on itself.
myFile.delete();

72. If the file is saved on internal storage, you can also ask the Context to locate and delete a file by calling deleteFile():
myContext.deleteFile(fileName);

73. Note: When the user uninstalls your app, the Android system deletes the following:
All files you saved on internal storage
All files you saved on external storage using getExternalFilesDir().

74. However, you should manually delete all cached files created with getCacheDir() on a regular basis and also regularly delete other files you no longer need.

75. 4.3 Saving Data in SQL Databases

76. Saving data to a database is ideal for repeating or structured data, such as contact information.
This class assumes that you are familiar with SQL databases in general and helps you get started with SQLite databases on Android.

77. The APIs you'll need to use a database on Android are available in the android.database.sqlite package.

78. Define a Schema and Contract
One of the main principles of SQL databases is the schema: a formal declaration of how the database is organized.
The schema is reflected in the SQL statements that you use to create your database.

79. You may find it helpful to create a companion class, known as a contract class, which explicitly specifies the layout of your schema in a systematic and self-documenting way.
A contract class is a container for constants that define names for URIs, tables, and columns.

80. The contract class allows you to use the same constants across all the other classes in the same package.
This lets you change a column name in one place and have it propagate throughout your code.

81. A good way to organize a contract class is to put definitions that are global to your whole database in the root level of the class.
Then create an inner class for each table that enumerates its columns.

82. Note: By implementing the BaseColumns interface, your inner class can inherit a primary key field called _ID that some Android classes such as cursor adaptors will expect it to have.

83. It's not required, but this can help your database work harmoniously with the Android framework.
For example, this snippet defines the table name and column names for a single table:

84. public final class FeedReaderContract {
// To prevent someone from accidentally instantiating the contract class,
// make the constructor private.
private FeedReaderContract() {}
/* Inner class that defines the table contents */
public static class FeedEntry implements BaseColumns {
public static final String TABLE_NAME = "entry";
public static final String COLUMN_NAME_TITLE = "title";
public static final String COLUMN_NAME_SUBTITLE = "subtitle"; }

85. Create a Database Using a SQL Helper
Once you have defined how your database looks, you should implement methods that create and maintain the database and tables.
Here are some typical statements that create and delete a table:

86. private static final String SQL_CREATE_ENTRIES =
"CREATE TABLE " + FeedEntry.TABLE_NAME + " (" +
FeedEntry._ID + " INTEGER PRIMARY KEY," +
FeedEntry.COLUMN_NAME_TITLE + " TEXT," +
FeedEntry.COLUMN_NAME_SUBTITLE + " TEXT)";
private static final String SQL_DELETE_ENTRIES =
"DROP TABLE IF EXISTS " + FeedEntry.TABLE_NAME;

87. Just like files that you save on the device's internal storage, Android stores your database in private disk space that's associated application.
Your data is secure, because by default this area is not accessible to other applications.

88. A useful set of APIs is available in the SQLiteOpenHelper class.
When you use this class to obtain references to your database, the system performs the potentially long-running operations of creating and updating the database only when needed and not during app startup.

89. All you need to do is call getWritableDatabase() or getReadableDatabase().
Note: Because they can be long-running, be sure that you call getWritableDatabase() or getReadableDatabase() in a background thread, such as with AsyncTask or IntentService.

90. To use SQLiteOpenHelper, create a subclass that overrides the onCreate(), onUpgrade() and onOpen() callback methods.
You may also want to implement onDowngrade(), but it's not required.
For example, here's an implementation of SQLiteOpenHelper that uses some of the commands shown above:

91. public class FeedReaderDbHelper extends SQLiteOpenHelper {
// If you change the database schema, you must increment the database version.
public static final int DATABASE_VERSION = 1;
public static final String DATABASE_NAME = "FeedReader.db";
public FeedReaderDbHelper(Context context) {
super(context, DATABASE_NAME, null, DATABASE_VERSION); }
public void onCreate(SQLiteDatabase db) {
db.execSQL(SQL_CREATE_ENTRIES);
public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
// This database is only a cache for online data, so its upgrade policy is
// to simply to discard the data and start over
db.execSQL(SQL_DELETE_ENTRIES);
onCreate(db);
public void onDowngrade(SQLiteDatabase db, int oldVersion, int newVersion) {
onUpgrade(db, oldVersion, newVersion);

92. To access your database, instantiate your subclass of SQLiteOpenHelper:
FeedReaderDbHelper mDbHelper = new FeedReaderDbHelper(getContext());

93. Put Information into a Database
Insert data into the database by passing a ContentValues object to the insert() method:

94. // Gets the data repository in write mode
SQLiteDatabase db = mDbHelper.getWritableDatabase();
// Create a new map of values, where column names are the keys
ContentValues values = new ContentValues();
values.put(FeedEntry.COLUMN_NAME_TITLE, title);
values.put(FeedEntry.COLUMN_NAME_SUBTITLE, subtitle);
// Insert the new row, returning the primary key value of the new row
long newRowId = db.insert(FeedEntry.TABLE_NAME, null, values);

95. The first argument for insert() is simply the table name.
The second argument tells the framework what to do in the event that the ContentValues is empty (i.e., you did not put any values).

96. If you specify the name of a column, the framework inserts a row and sets the value of that column to null.
If you specify null, like in this code sample, the framework does not insert a row when there are no values.

97. Read Information from a Database
To read from a database, use the query() method, passing it your selection criteria and desired columns.

98. The method combines elements of insert() and update(), except the column list defines the data you want to fetch, rather than the data to insert.
The results of the query are returned to you in a Cursor object.

99. SQLiteDatabase db = mDbHelper.getReadableDatabase();
// Define a projection that specifies which columns from the database
// you will actually use after this query.
String[] projection = {
FeedEntry._ID,
FeedEntry.COLUMN_NAME_TITLE,
FeedEntry.COLUMN_NAME_SUBTITLE };
// Filter results WHERE "title" = 'My Title'
String selection = FeedEntry.COLUMN_NAME_TITLE + " = ?";
String[] selectionArgs = { "My Title" };

100. // How you want the results sorted in the resulting Cursor
String sortOrder =
FeedEntry.COLUMN_NAME_SUBTITLE + " DESC";
Cursor cursor = db.query(
FeedEntry.TABLE_NAME, // The table to query
projection, // The columns to return
selection, // The columns for the WHERE clause
selectionArgs, // The values for the WHERE clause
null, // don't group the rows
null, // don't filter by row groups
sortOrder // The sort order );

101. To look at a row in the cursor, use one of the Cursor move methods, which you must always call before you begin reading values.
Since the cursor starts at position -1, calling moveToNext() places the "read position" on the first entry in the results and returns whether or not the cursor is already past the last entry in the result set.

102. For each row, you can read a column's value by calling one of the Cursor get methods, such as getString() or getLong().
For each of the get methods, you must pass the index position of the column you desire, which you can get by calling getColumnIndex() or getColumnIndexOrThrow().

103. When finished iterating through results, call close() on the cursor to release its resources.
For example:

104. List itemIds = new ArrayList<>();
while(cursor.moveToNext()) {
long itemId = cursor.getLong(
cursor.getColumnIndexOrThrow(FeedEntry._ID));
itemIds.add(itemId); }
cursor.close();

105. Delete Information from a Database
To delete rows from a table, you need to provide selection criteria that identify the rows.
The database API provides a mechanism for creating selection criteria that protects against SQL injection.

106. The mechanism divides the selection specification into a selection clause and selection arguments.
The clause defines the columns to look at, and also allows you to combine column tests.

107. The arguments are values to test against that are bound into the clause.
Because the result isn't handled the same as a regular SQL statement, it is immune to SQL injection.

108. // Define 'where' part of query.
String selection = FeedEntry.COLUMN_NAME_TITLE + " LIKE ?";
// Specify arguments in placeholder order.
String[] selectionArgs = { "MyTitle" };
// Issue SQL statement.
db.delete(FeedEntry.TABLE_NAME, selection, selectionArgs);

109. Update a Database
When you need to modify a subset of your database values, use the update() method.
Updating the table combines the content values syntax of insert() with the where syntax of delete().

110. SQLiteDatabase db = mDbHelper.getWritableDatabase();
// New value for one column
ContentValues values = new ContentValues();
values.put(FeedEntry.COLUMN_NAME_TITLE, title);
// Which row to update, based on the title
String selection = FeedEntry.COLUMN_NAME_TITLE + " LIKE ?";
String[] selectionArgs = { "MyTitle" };
int count = db.update(
FeedReaderDbHelper.FeedEntry.TABLE_NAME,
values,
selection,
selectionArgs);

111. Persisting Database Connection
Since getWritableDatabase() and getReadableDatabase() are expensive to call when the database is closed, you should leave your database connection open for as long as you possibly need to access it.
Typically, it is optimal to close the database in the onDestroy() of the calling Activity.

112. @Override
protected void onDestroy() {
mDbHelper.close();
super.onDestroy(); }

113. Summary and Mission The usual blah blah blah:
The chance that any particular student will use this stuff is small
On the other hand, here it is, in case someone wants to do a project that uses it
It’s useful background knowledge even if you choose not to use it

114. The End