Finding Places to Put Data

Depending on the requirements of your application, you may need to store data in a variety of places. For example, if an application interacts with music files and a user wants to play them in more than one music program, you have to store them in a location where all applications can access them. An application that needs to store sensitive data, such as encrypted usernames and password details, shouldn’t share data — placing it in a secure, local storage environment is the best strategy. Regardless of your situation, Android provides various options for storing data.

Viewing your storage options

The Android ecosystem provides various locations where data can be persisted:

Shared preferences: Private data stored in key-value pairs. (See Chapter 15 to find out how to handle shared preferences.)

Internal storage: A location for saving files on the device. Files stored in internal storage are private to your application by default, and other applications cannot access them. (Neither can the user, except by using your application.) When the application is uninstalled, the private files are deleted as well.

Local cache: The internal data directory for caching data rather than storing it persistently. Cached files may be deleted at any time. You use the getCacheDir() method, available on the Activity or Context objects in Android.

If you store data in an internal data directory and the internal storage space begins to run low, Android may delete files to reclaim space. Don’t rely on Android to delete your files for you though! You should delete your cache files yourself to stay within a reasonable limit (about 1 MB) of space consumed in the cache directory.

External storage: Every Android device supports shared external storage for files — either removable storage, such as a Secure Digital card (SD card) or nonremovable storage. Files saved to external storage are public (any person or application can alter them), and no level of security is enforced. Users can modify files by either using a file manager application or connecting the device to a computer via a USB cable and mounting the device as external storage. Before you work with external storage, check the current state of the external storage with the Environment object, using a call to getExternalStorageState() to check whether the media is available.

In Android 2.2, a new set of methods was introduced to handle external files. The main method is a call on the Context object — getExternal FilesDir(). This call takes a string parameter as a key to help define the type of media you’re saving, such as ringtones, music, or photos. For more information, view the external data storage examples and documents at http://d.android.com/guide/topics/data/data-storage.html#filesExternal .

SQLite database: A lightweight SQL database implementation that’s available across various platforms (including Android, iPhone, Windows, Linux, and Mac) and fully supported by Android. You can create tables and perform SQL queries against the tables accordingly. You implement an SQLite database in this chapter to handle the persistence of the tasks in the Task Reminder application.

Content provider: A “wrapper” around another storage mechanism. A content provider is used by an app to read and write application data that can be stored in preferences, files, or SQLite databases, for example.

Network connection: (Also known as remote storage.) Any remote data source that you have access to. For example, because Flickr exposes an API that allows you to store images on its servers, your application might work with Flickr to store images. If your application works with a popular tool on the Internet (such as Twitter, Facebook, or Basecamp), your app might send information via HTTP — or any other protocol you deem necessary — to third-party APIs to store the data.

Choosing a storage option

The various data storage locations offer quite the palette of options. However, you have to figure out which one to use, and you may even want to use multiple storage mechanisms.

Suppose that your application communicates with a third-party remote API such as Twitter, and network communication is slow and less than 100 percent reliable. You may want to retain on the server a local copy of all data since the last update, to allow the application to remain usable (in some fashion) until the next update. When you store the data in a local copy of an SQLite database and the user initiates an update, the new updates refresh the SQLite database with the new data.

If your application relies solely on network communication for information retrieval and storage, use the SQLite database (or any other storage mechanism) to make the application remain usable when the user cannot connect to a network and must work offline — a common occurrence. If your application doesn’t function when a network connection is unavailable, you’ll likely receive negative reviews in the Google Play Store — as well as feature requests to make your app work offline. This strategy introduces quite a bit of extra work into the application development process, but it’s worth your time tenfold in user experience.