ContentProvider是Android四大元件之一，網上也有不少關於它的文章，基本用法都可以查到，但關於UriMatcher在其中的作用，文章中都有例子，但我覺得還沒有說清楚。

先說為什麼用UriMatcher。

實現query、insert.....方法都已經指定操作入口了，為何還要matcher uri，原來是解決多表等情況。

ContentProvider向外界提供了一個標準的，也是唯一的用於查詢的介面：

public final Cursor query(Uri uri, String[] projection,
            String selection, String[] selectionArgs, String sortOrder);

 

其中uri用於指定哪一個資料來源，當一個數據源含有多個內容（比如多個表），就需要用不同的Uri進行區分，例如：

public static final Uri CONTENT_URI_A = Uri.parse("content://" + AUTHORITY  + "/" + TABLE_A);
public static final Uri CONTENT_URI_B = Uri.parse("content://" + AUTHORITY  + "/" + TABLE_B);

這時候使用UriMatcher就可以幫助我們方便的過濾到TableA還是TableB, 然後進行下一步查詢， 如果不用UriMatcher也可以，我們就需要手動過濾字串，用起來有點麻煩，可維護性也不好。 再說怎麼用UriMatcher, 定義如下：

   // Set up our URL matchers to help us determine what an
   // incoming URI parameter is.
   private static final UriMatcher URI_MATCHER;
   static {
      URI_MATCHER = new UriMatcher(UriMatcher.NO_MATCH);
      URI_MATCHER.addURI(AUTHORITY, TABLE_A, TABLE_A_MSG);
      URI_MATCHER.addURI(AUTHORITY, TABLE_B, TABLE_B_MSG);
      
   }
 

在查詢中使用UriMatcher:

 @Override
   public Cursor query(Uri uri, String[] projection, String selection,
         String[] selectionArgs, String sortOrder) {     
 
      String table = null;
 
      switch (URI_MATCHER.match(uri)) {
      case ALL_MESSAGES:
         break;
      case OXFORD_MSG:
         table = TABLE_A;
         break;
      case CHENYU_MSG:
         table = TABLE_B;
         break;
      default:
         break;
      }
 
      Cursor resultCursor = mDB.query(table, projection, selection, selectionArgs, null, null, sortOrder);
 
      return resultCursor;
   }

總之，UriMatcher本質上是一個文字過濾器，用在contentProvider中幫助我們過濾，分辨出查詢者想要查詢哪個資料表。