DbHelper.java

import android.database.sqlite.SQLiteDatabase;
import android.database.sqlite.SQLiteOpenHelper;

public class DbHelper extends SQLiteOpenHelper {
	
	public DbHelper(Context context) {
		super(context, Constants.DB_NAME, null, Constants.DB_VERSION);
	}

	@Override
	public void onCreate(SQLiteDatabase db) {
		onUpgrade(db, 0, Constants.DB_VERSION);
	}

	@Override
	public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
		// sanity check
		if (oldVersion >= newVersion) return;

		// loop through incremental upgrades
		switch (oldVersion) {
			case 0:
				// create version 1 of tables
				db.execSql("CREATE TABLE ...");
				db.execSql("CREATE TABLE ...");
				db.execSql("CREATE TABLE ...");

			case 1:
				// upgrade from version 1 to 2
				db.execSql("ALTER TABLE ...");
				db.execSql("ALTER TABLE ...");

			case 2:
				// upgrade from version 2 to 3
				db.execSql("DROP TABLE ...");

			case 3:
				// upgrade from version 3 to 4
				db.execSql("ALTER TABLE ...");
				db.execSql("CREATE TABLE ...");

				break;

			default:
				throw new IllegalStateException("No upgrade specified for " + oldVersion + " -> " + newVersion);
		}
	}

}

/*

What's going on here?

- We're creating the DbHelper on lines 5-7 exactly as we did in the lecture.

- On lines 10-12, we *don't* create our database tables. Instead, we tell Android that
  we'd like to upgrade from "version 0" to whatever the current version is. This means
  that if someone installs your app from scratch (and therefore the database doesn't
  exist yet) they will create the initial tables from the first version of your app,
  and then go through every incremental upgrade you have specified to end up with the
  current version. In this case, "version 0" means "there isn't a database yet".

- On lines 15-46, we specify an incremental upgrade between each database version. The
  upgrade from "version 0" to "version 1" means creating the initial tables (3 of them,
  in this example). Each successive case specifies the upgrade from one version to the
  next (going from v1 to v2 we alter two tables; going from v2 to v3 we drop a table,
  and going from v3 to v4 we alter a table and create one more).

- Note the lack of "break" statements throughout the switch block. This allows the
  program flow to "fall through" into the next case. If you run onUpgrade(db, 2, 4) to
  upgrade from version 2 to 4 (lets say the user hasn't used the app for a while between
  some of your upgrades), then it will skip case 0 and case 1, enter the flow at case 2,
  and then keep executing cases until the "break". This means that whatever the entry
  point, the program will always execute everything required to take the database to the
  latest version.

- A final "safety" measure is defined to throw an explanatory exception if the user tries
  to upgrade to a version that doesn't exist.

Does this make sense? Awesome! Post any questions on the Slack channel.

Mark :)

*/