Today we’ll discuss about custom loaders in Android. Loaders have been introduced from Android 3.0 but we can also use loaders in prior versions of Android starting from Android 1.6 with the help of Android compatibility library.

In this tutorial we won’t discuss the basics of loader which is vastly available in the Internet. A very good tutorial on loaders in Android can be found here . Here we’ll discuss about how to create a custom loader in Android which can read data from SQLite Database and return the read data as a collection of POJO.

Android provides a ‘CursorLoader’ class which can read data from content providers but to read data directly from the SQLite database we need our own custom loader. A very nice loader library is written for this which reads data from cursor and can be found here and I’ve taken the idea of the custom loader from these mentioned links. But our custom loader is capable to read data from the SQLite database without using any content provider and returns the data as collection of objects.

Create a new Android project and remember to use the library ‘android-support-v4.jar’ and implement the custom loader as follows :

First we’ll create a generic data source class file ‘DataSource.java’ with common methods to perform CRUD operations on data. The code is as follows :

package com.example.customloaderexample.db;
import java.util.List;
import android.content.Context;
import android.database.sqlite.SQLiteDatabase;
public abstract class DataSource {
	protected SQLiteDatabase mDatabase;
	public DataSource(SQLiteDatabase database) {
		mDatabase = database;
	}

	public abstract boolean insert(T entity);
	public abstract boolean delete(T entity);
	public abstract boolean update(T entity);
	public abstract List read();
	public abstract List read(String selection, String[] selectionArgs, String groupBy, String having, String orderBy);
}

Next we’ll create our model class file ‘Test.java’ with the following code. This class represents the data that we want to store and retrieve from the database.

package com.example.customloaderexample.model;
public class Test {
	private int id;
	private String name;
	public Test() {} 
	public Test(String name) {
		this.name = name;
	} 
	public int getId() {
		return id;
	} 
	public void setId(int id) {
		this.id = id;
	} 
	public String getName() {
		return name;
	} 
	public void setName(String name) {
		this.name = name;
	} 
	@Override 
	public String toString() {
		return name;
	}
}

Next we’ll create a subclass of ‘TestDataSource.java’ to specifically perform CRUD operations on ‘Test’ objects.

package com.example.customloaderexample.db;
import java.util.ArrayList;
import java.util.List;
import android.content.ContentValues;
import android.content.Context;
import android.database.Cursor;
import android.database.sqlite.SQLiteDatabase;
import com.example.customloaderexample.model.Test;
public class TestDataSource extends DataSource {
	public static final String TABLE_NAME = "test";
	public static final String COLUMN_ID = "_id";
	public static final String COLUMN_NAME = "name";
	// Database creation sql statement
	public static final String CREATE_COMMAND = "create table " + TABLE_NAME + "(" + COLUMN_ID + " integer primary key autoincrement, " + COLUMN_NAME + " text not null);";
	public TestDataSource(SQLiteDatabase database) {
		super(database);
		// TODO Auto-generated constructor stub
	}
	@Override
	public boolean insert(Test entity) {
		if (entity == null) {
			return false;
		}
		long result = mDatabase.insert(TABLE_NAME, null, generateContentValuesFromObject(entity));
		return result != -1;
	}
	@Override
	public boolean delete(Test entity) {
		if (entity == null) {
			return false;
		}
		int result = mDatabase.delete(TABLE_NAME, COLUMN_ID + " = " + entity.getId(), null);
		return result != 0;
	}
	@Override
	public boolean update(Test entity) {
		if (entity == null) {
			return false;
		}
		int result = mDatabase.update(TABLE_NAME, generateContentValuesFromObject(entity), COLUMN_ID + " = " + entity.getId(), null);
		return result != 0;
	}
	@Override
	public List read() {
		Cursor cursor = mDatabase.query(TABLE_NAME, getAllColumns(), null, null, null, null, null);
		List tests = new ArrayList();
		if (cursor != null && cursor.moveToFirst()) {
			while (!cursor.isAfterLast()) {
				tests.add(generateObjectFromCursor(cursor));
				cursor.moveToNext();
			}
			cursor.close();
		}
		return tests;
	}
	@Override
	public List read(String selection, String[] selectionArgs, String groupBy, String having, String orderBy) {
		Cursor cursor = mDatabase.query(TABLE_NAME, getAllColumns(), selection, selectionArgs, groupBy, having, orderBy);
		List tests = new ArrayList();
		if (cursor != null && cursor.moveToFirst()) {
			while (!cursor.isAfterLast()) {
				tests.add(generateObjectFromCursor(cursor));
				cursor.moveToNext();
			}
			cursor.close();
		}
		return tests;
	}
	public String[] getAllColumns() {
		return new String[] { COLUMN_ID, COLUMN_NAME };
	}
	public Test generateObjectFromCursor(Cursor cursor) {
		if (cursor == null) {
			return null;
		}
		Test test = new Test();
		test.setId(cursor.getInt(cursor.getColumnIndex(COLUMN_ID)));
		test.setName(cursor.getString(cursor.getColumnIndex(COLUMN_NAME)));
		return test;
	}
	public ContentValues generateContentValuesFromObject(Test entity) {
		if (entity == null) {
			return null;
		}
		ContentValues values = new ContentValues();
		values.put(COLUMN_NAME, entity.getName());
		return values;
	}
}

Now we’ll create our SQLite database open helper ‘DbHelper.java’. This class extends the SQLiteOpenHelper which helps us to create the initial database and tables.

package com.example.customloaderexample.db;
import android.content.Context;
import android.database.sqlite.SQLiteDatabase;
import android.database.sqlite.SQLiteOpenHelper;
public class DbHelper extends SQLiteOpenHelper {
	private static final String DATABASE_NAME = "test.db";
	private static final int DATABASE_VERSION = 1;
	public DbHelper(Context context) {
		super(context, DATABASE_NAME, null, DATABASE_VERSION);
	}
	@Override
	public void onCreate(SQLiteDatabase database) {
		database.execSQL(TestDataSource.CREATE_COMMAND);
	}
	@Override
	public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
		db.execSQL("DROP TABLE IF EXISTS " + TestDataSource.TABLE_NAME);
		onCreate(db);
	}
}

Next we’ll create a generic AsyncTask subclass ‘ContentChangingTask.java’ to perform content changing in background. This class is the base class for changing contents. We’ll create subclasses of this base class to perform CRUD operation on data in background.

package com.example.customloaderexample.loader;
import android.os.AsyncTask;
import android.support.v4.content.Loader;
public abstract class ContentChangingTask extends AsyncTask {
	private Loader loader=null;
	ContentChangingTask(Loader loader) {
		this.loader=loader;
	}
	@Override
	protected void onPostExecute(T3 param) {
		loader.onContentChanged();
	}
}

Now we’ll create a generic base class for our custom loader ‘AbstractDataLoader.java’. This class is the base class of our custom loader.

package com.example.customloaderexample.loader;
import java.util.List;
import android.content.Context;
import android.support.v4.content.AsyncTaskLoader;
public abstract class AbstractDataLoader> extends AsyncTaskLoader {
	protected E mLastDataList = null;
	protected abstract E buildList();
	public AbstractDataLoader(Context context) {
		super(context);
	}
	/** * Runs on a worker thread, loading in our data. Delegates the real work to * concrete subclass' buildCursor() method. */
	@Override
	public E loadInBackground() {
		return buildList();
	}
	/** * Runs on the UI thread, routing the results from the background thread to * whatever is using the dataList. */ @Override
	public void deliverResult(E dataList) {
		if (isReset()) {
			// An async query came in while the loader is stopped
			emptyDataList(dataList);
			return;
		}
		E oldDataList = mLastDataList;
		mLastDataList = dataList;
		if (isStarted()) {
			super.deliverResult(dataList);
		}
		if (oldDataList != null && oldDataList != dataList && oldDataList.size() > 0) {
			emptyDataList(oldDataList);
		}
	}
	/** * Starts an asynchronous load of the list data. When the result is ready * the callbacks will be called on the UI thread. If a previous load has * been completed and is still valid the result may be passed to the * callbacks immediately. * * Must be called from the UI thread. */
	@Override
	protected void onStartLoading() {
		if (mLastDataList != null) {
			deliverResult(mLastDataList);
		}
		if (takeContentChanged() || mLastDataList == null || mLastDataList.size() == 0) {
			forceLoad();
		}
	}
	/** * Must be called from the UI thread, triggered by a call to stopLoading(). */
	@Override
	protected void onStopLoading() {
		// Attempt to cancel the current load task if possible.
		cancelLoad();
	}
	/** * Must be called from the UI thread, triggered by a call to cancel(). Here, * we make sure our Cursor is closed, if it still exists and is not already * closed. */
	@Override
	public void onCanceled(E dataList) {
		if (dataList != null && dataList.size() > 0) {
			emptyDataList(dataList);
		}
	}
	/** * Must be called from the UI thread, triggered by a call to reset(). Here, * we make sure our Cursor is closed, if it still exists and is not already * closed. */
	@Override
	protected void onReset() {
		super.onReset();
		// Ensure the loader is stopped
		onStopLoading();
		if (mLastDataList != null && mLastDataList.size() > 0) {
			emptyDataList(mLastDataList);
		}
		mLastDataList = null;
	}
	protected void emptyDataList(E dataList) {
		if (dataList != null && dataList.size() > 0) {
			for (int i = 0; i < dataList.size(); i++) {
				dataList.remove(i);
			}
		}
	}
}

Now we’ll create the specific loader ‘SQLiteTestDataLoader.java’ for ‘Test’ object which is a subclass of the previous generic loader. This class is the custom loader for ‘Test’ objects. We’ll instantiate this class as our loader.

package com.example.customloaderexample.loader;
import java.util.List;
import android.content.Context;
import com.example.customloaderexample.db.DataSource;
import com.example.customloaderexample.model.Test;
public class SQLiteTestDataLoader extends AbstractDataLoader {
	private DataSource mDataSource;
	private String mSelection;
	private String[] mSelectionArgs;
	private String mGroupBy;
	private String mHaving;
	private String mOrderBy;
	public SQLiteTestDataLoader(Context context, DataSource dataSource, String selection, String[] selectionArgs, String groupBy, String having, String orderBy) {
		super(context);
		mDataSource = dataSource;
		mSelection = selection;
		mSelectionArgs = selectionArgs;
		mGroupBy = groupBy;
		mHaving = having;
		mOrderBy = orderBy;
	}
	@Override
	protected List buildList() {
		List testList = mDataSource.read(mSelection, mSelectionArgs, mGroupBy, mHaving,	mOrderBy);
		return testList;
	}
	public void insert(Test entity) {
		new InsertTask(this).execute(entity);
	}
	public void update(Test entity) {
		new UpdateTask(this).execute(entity);
	}
	public void delete(Test entity) {
		new DeleteTask(this).execute(entity);
	}
	private class InsertTask extends ContentChangingTask {
		InsertTask(SQLiteTestDataLoader loader) {
			super(loader);
		}
		@Override
		protected Void doInBackground(Test... params) {
			mDataSource.insert(params[0]);
			return (null);
		}
	}
	private class UpdateTask extends ContentChangingTask {
		UpdateTask(SQLiteTestDataLoader loader) {
			super(loader);
		}
		@Override
		protected Void doInBackground(Test... params) {
			mDataSource.update(params[0]);
			return (null);
		}
	}
	private class DeleteTask extends ContentChangingTask {
		DeleteTask(SQLiteTestDataLoader loader) {
			super(loader);
		}
		@Override
		protected Void doInBackground(Test... params) {
			mDataSource.delete(params[0]);
			return (null);
		}
	}
}

Next we’ll create the initial view xml ‘activity_main.xml’ for our launcher activity into the res/layout folder.

<FrameLayoutxmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent"android:layout_height="match_parent">
<fragmentclass="com.example.customloaderexample.CustomLoaderExampleListFragment" android:id="@+id/titles" android:layout_width="match_parent"android:layout_height="match_parent"/>

Now we’ll create the launcher activity to launch our project. This is a FragmentActivity which holds our ListFragment and performs initial record insertion into database.

package com.example.customloaderexample;
import java.util.List;
import android.database.sqlite.SQLiteDatabase;
import android.os.Bundle;
import android.support.v4.app.FragmentActivity;
import com.example.customloaderexample.db.DbHelper;
import com.example.customloaderexample.db.TestDataSource;
import com.example.customloaderexample.model.Test;
public class MainFragmentActivity extends FragmentActivity {
	@Override
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		setContentView(R.layout.activity_main);
		DbHelper helper = new DbHelper(this);
		SQLiteDatabase database = helper.getWritableDatabase();
		TestDataSource dataSource = new TestDataSource(database);
		List list = dataSource.read();
		if(list == null || list.size() == 0) {
			dataSource.insert(new Test("Samik"));
			dataSource.insert(new Test("Piyas"));
			dataSource.insert(new Test("Sujal"));
		}
		helper.close();
		database.close();
	}
}

Don’t forget to maintain the entry of the launcher activity into the ‘AndroidManifest.xml’ along with proper intent filter (to make it the launcher activity).

Now we’ll create the ListFragment to retrieve the list of Test objects from the database and show using our custom loader.

package com.example.customloaderexample;
import java.util.List;
import android.database.sqlite.SQLiteDatabase;
import android.database.sqlite.SQLiteOpenHelper;
import android.os.Bundle;
import android.support.v4.app.ListFragment;
import android.support.v4.app.LoaderManager;
import android.support.v4.content.Loader;
import android.util.Log;
import android.view.Menu;
import android.view.MenuInflater;
import android.view.MenuItem;
import android.widget.ArrayAdapter;
import com.example.customloaderexample.db.DbHelper;
import com.example.customloaderexample.db.TestDataSource;
import com.example.customloaderexample.loader.SQLiteTestDataLoader;
import com.example.customloaderexample.model.Test;
public class CustomLoaderExampleListFragment extends ListFragment implements LoaderManager.LoaderCallbacks {
	private ArrayAdapter mAdapter;
	// The Loader's id (this id is specific to the ListFragment's LoaderManager)
	private static final int LOADER_ID = 1;
	private static final boolean DEBUG = true;
	private static final String TAG = "CustomLoaderExampleListFragment";
	private SQLiteDatabase mDatabase;
	private TestDataSource mDataSource;
	private DbHelper mDbHelper;
	@Override
	public void onActivityCreated(Bundle savedInstanceState) {
		// TODO Auto-generated method stub
		super.onActivityCreated(savedInstanceState);
		//setHasOptionsMenu(true);
		mDbHelper = new DbHelper(getActivity());
		mDatabase = mDbHelper.getWritableDatabase();
		mDataSource = new TestDataSource(mDatabase);
		mAdapter = new ArrayAdapter(getActivity(), android.R.layout.simple_list_item_1);
		setEmptyText("No data, please add from menu.");
		setListAdapter(mAdapter);
		setListShown(false);
		if (DEBUG) {
			Log.i(TAG, "+++ Calling initLoader()! +++");
			if (getLoaderManager().getLoader(LOADER_ID) == null) {
				Log.i(TAG, "+++ Initializing the new Loader... +++");
			} else {
				Log.i(TAG, "+++ Reconnecting with existing Loader (id '1')... +++");
			}
		}
		// Initialize a Loader with id '1'. If the Loader with this id already // exists, then the LoaderManager will reuse the existing Loader.
		getLoaderManager().initLoader(LOADER_ID, null, this);
	}
	@Override
	public Loader onCreateLoader(int id, Bundle args) {
		SQLiteTestDataLoader loader = new SQLiteTestDataLoader(getActivity(), mDataSource, null, null, null, null, null);
		return loader;
	}
	@Override
	public void onLoadFinished(Loader loader, List data) {
		if (DEBUG) {
			Log.i(TAG, "+++ onLoadFinished() called! +++");
		}
		mAdapter.clear();
		for(Test test : data) {
			mAdapter.add(test);
		}
		if (isResumed()) {
			setListShown(true);
		} else {
			setListShownNoAnimation(true);
		}
	}
	@Override
	public void onLoaderReset(Loader arg0) {
		mAdapter.clear();
	}
	@Override
	public void onDestroy() {
		super.onDestroy();
		mDbHelper.close();
		mDatabase.close();
		mDataSource = null;
		mDbHelper = null;
		mDatabase = null;
	}
}

Now run the project as Android application and you’ll get the following screen :

Acknowledgement :

http://www.vogella.com/articles/AndroidSQLite/article.html

https://github.com/commonsguy/cwac-loaderex

http://www.androiddesignpatterns.com/2012/07/loaders-and-loadermanager-background.html

文章节选：http://www.phloxblog.in/android-custom-loader-load-data-sqlite-database-android-version-1-6/

创建自定义的SQLite Loader，首发于润物无声。

Java developers mix object-oriented thinking with imperative thinking, depending on their levels of:

• Skill (anyone can code imperatively)
• Dogma (some use the “Pattern-Pattern”, i.e. the pattern of applying patterns everywhere and giving them names)
• Mood (true OO is more clumsy to write than imperative code. At first)

But when Java developers write SQL, everything changes. SQL is a declarative language that has nothing to do with either object-oriented or imperative thinking. It is very easy to express a query in SQL. It is not so easy to express it optimally or correctly. Not only do developers need to re-think their programming paradigm, they also need to think in terms of set theory.

Here are common mistakes that a Java developer makes when writing SQL (in no particular order):

1. Forgetting about NULL

Misunderstanding NULL is probably the biggest mistake a Java developer can make when writing SQL. This is also (but not exclusively) due to the fact that NULL is also called UNKNOWN. If it were only called UNKNOWN, it would be easier to understand. Another reason is that JDBC maps SQL NULL to Java null when fetching data or when binding variables. This may lead to thinking that NULL = NULL (SQL) would behave the same way as null == null (Java)

One of the crazier examples of misunderstanding NULL is when NULL predicates are used with row value expressions.

Another, subtle problem appears when misunderstanding the meaning ofNULL in NOT IN anti-joins.

The Cure:

Train yourself. There’s nothing but explicitly thinking about NULL, every time you write SQL:

• Is this predicate correct with respect to NULL?
• Does NULL affect the result of this function?

2. Processing data in Java memory

Few Java developers know SQL very well. The occasional JOIN, the odd UNION, fine. But window functions? Grouping sets? A lot of Java developers load SQL data into memory, transform the data into some appropriate collection type, execute nasty maths on that collection with verbose loop structures (at least, before Java 8′s Collection improvements).

But some SQL databases support advanced (and SQL standard!) OLAP features that tend to perform a lot better and are much easier to write. A (non-standard) example is Oracle’s awesome MODEL clause. Just let the database do the processing and fetch only the results into Java memory. Because after all some very smart guys have optimised these expensive products. So in fact, by moving OLAP to the database, you gain two things:

• Simplicity. It’s probably easier to write correctly in SQL than in Java
• Performance. The database will probably be faster than your algorithm. And more importantly, you don’t have to transmit millions of records over the wire.

The Cure:

Every time you implement a data-centric algorithm in Java, ask yourself: Is there a way to let the database perform that work for me?

3. Using UNION instead of UNION ALL

It’s a shame that UNION ALL needs an extra keyword compared to UNION. It would be much better if the SQL standard had been defined to support:

• UNION (allowing duplicates)
• UNION DISTINCT (removing duplicates)

Not only is the removal of duplicates rarely needed (or sometimes even wrong), it is also quite slow for large result sets with many columns, as the two subselects need to be ordered, and each tuple needs to be compared with its subsequent tuple.

Note that even if the SQL standard specifies INTERSECT ALL and EXCEPT ALL, hardly any database implements these less useful set operations.

The Cure:

Every time you write a UNION, think if you actually wanted to write UNION ALL.

4. Using JDBC Paging to page large results

Most databases support some way of paging ordered results through LIMIT .. OFFSET, TOP .. START AT, OFFSET .. FETCH clauses. In the absence of support for these clauses, there is still the possibility for ROWNUM (Oracle)or ROW_NUMBER() OVER() filtering (DB2, SQL Server 2008 and less), which is much faster than paging in memory. This is specifically true for large offsets!

The Cure:

Just use those clauses, or a tool (such as jOOQ) that can simulate those clauses for you.

5. Joining data in Java memory

From early days of SQL, some developers still have an uneasy feeling when expressing JOINs in their SQL. There is an inherent fear of JOIN being slow. This can be true if a cost-based optimiser chooses to perform a nested loop, possibly loading complete tables into database memory, before creating a joined table source. But that happens rarely. With appropriate predicates, constraints and indexes, MERGE JOIN and HASH JOIN operations are extremely fast. It’s all about the correct metadata (I cannot cite Tom Kyte often enough for this). Nonetheless, there are probably still quite a few Java developers who will load two tables from separate queries into maps and join them in Java memory in one way or another.

The Cure:

If you’re selecting from various tables in various steps, think again to see if you cannot express your query in a single statement.

6. Using DISTINCT or UNION to remove duplicates from an accidental cartesian product

With heavy joining, one can loose track of all the relations that are playing a role in a SQL statement. Specifically, if multi-column foreign key relationships are involved, it is possible to forget to add the relevant predicates in JOIN .. ON clauses. This might result in duplicate records, but maybe only in exceptional cases. Some developers may then choose to use DISTINCT to remove those duplicates again. This is wrong in three ways:

• It (may) solve the symptoms but not the problem. It may as well not solve the symptoms in edge-cases.
• It is slow for large result sets with many columns. DISTINCT performs an ORDER BY operation to remove duplicates.
• It is slow for large cartesian products, which will still load lots of data into memory

The Cure:

As a rule of thumb, when you get unwanted duplicates, always review your JOIN predicates. There’s probably a subtle cartesian product in there somewhere.

7. Not using the MERGE statement

This isn’t really a mistake, but probably some lack of knowledge or some fear towards the powerful MERGE statement. Some databases know other forms of UPSERT statements, e.g. MySQL’s ON DUPLICATE KEY UPDATE clause. But MERGE is really so powerful, most importantly in databases that heavily extend the SQL standard, such as SQL Server.

The Cure:

If you’re UPSERTING by chaining INSERT and UPDATE or by chaining SELECT .. FOR UPDATE and then INSERT or UPDATE, think again. Apart from risking race conditions, you might be able to express a simpler MERGE statement.

8. Using aggregate functions instead of window functions

Before the introduction of window functions, the only means to aggregate data in SQL was by using a GROUP BY clause along with aggregate functions in the projection. This works well in many cases, and if aggregation data needed to be enriched with regular data, the grouped query can be pushed down into a joined subquery.

But SQL:2003 defined window functions, which are implemented by many popular database vendors. Window functions can aggregate data on result sets that are not grouped. In fact, each window function supports its own, independent PARTITION BY clause, which is an awesome tool for reporting.

Using window functions will:

• Lead to more readable SQL (less dedicated GROUP BY clauses in subqueries)
• Improve performance, as a RDBMS is likely to optimise window functions more easily

The Cure:

When you write a GROUP BY clause in a subquery, think again if this cannot be done with a window function.

9. Using in-memory sorting for sort indirections

The SQL ORDER BY clause supports many types of expressions, including CASE statements, which can be very useful for sort indirections. You should probably never sort data in Java memory because you think that

• SQL sorting is too slow
• SQL sorting cannot do it

The Cure:

If you sort any SQL data in memory, think again if you cannot push sorting into your database. This goes along well with pushing paging into the database.

10. Inserting lots of records one by one

JDBC knows batching, and you should use it. Do not INSERT thousands of records one by one, re-creating a new PreparedStatement every time. If all of your records go to the same table, create a batch INSERT statement with a single SQL statement and multiple bind value sets. Depending on your database and database configuration, you may need to commit after a certain amount of inserted records, in order to keep the UNDO log slim.

The Cure:

Always batch-insert large sets of data.

Some interesting books

Some very interesting books on similar topics are

• SQL Antipatterns by Bill Karwin
• SQL Performance Explained by Markus Winand

本文选自：10-common-mistakes-java-developers-make-when-writing-sql

Java语言开发之SQL语句改善，首发于润物无声。