The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
SharedPreferences and your own file structures, the third primary
means of persisting data locally on Android is via SQLite. For many applications,
SQLite is the app’s backbone, whether it is used directly or via some
This chapter will focus on how you can directly work with SQLite to store relational data.
SQLite is a very popular embedded database, as it combines a clean SQL interface with a very small memory footprint and decent speed. Moreover, it is public domain, so everyone can use it. Lots of firms (Adobe, Apple, Google, Symbian) and open source projects (Mozilla, PHP, Python) all ship products with SQLite.
For Android, SQLite is “baked into” the Android runtime, so every Android application can create SQLite databases. Since SQLite uses a SQL interface, it is fairly straightforward to use for people with experience in other SQL-based databases. However, its native API is not JDBC, and JDBC might be too much overhead for a memory-limited device like a phone, anyway. Hence, Android programmers have a different API to learn — the good news being is that it is not that difficult.
This chapter will cover the basics of SQLite use in the context of working on Android. It by no means is a thorough coverage of SQLite as a whole. If you want to learn more about SQLite, the SQLite Web site may help.
SQLite is a typical relational database, containing tables (themselves consisting of rows and columns), indexes, and so on. Your application will need its own set of tables and so forth for holding whatever data you wish to hold. This structure is generally referred to as a “schema”.
It is likely that your schema will need to change over time. You might add new tables or columns in support of new features. Or, you might significantly reorganize your data structure and wind up dropping some tables while moving the data into new ones.
As a result, when you ship an update to your application to your users, not only will your Java code change, but the expectations of that Java code will change as well, with respect to what your database schema will look like. Version 1 of your app will use your original schema, but by the time you ship, say, version 5 of the app, you might need an adjusted schema.
Android has facilities to assist you with handling changing database schemas,
mostly centered around the
The preview of this section is in an invisible, microscopic font.
The preview of this section is out seeking fame and fortune as the Dread Pirate Roberts.
The preview of this section was accidentally identified as an Android 'tasty treat' by the Cookie Monster.
The preview of this section is off trying to sweet-talk the Khaleesi into providing us with a dragon.
The preview of this section is [REDACTED].
The preview of this section is en route to Mars.