你的位置:首页 > 操作系统

[操作系统]Android细笔记


Provider的不常见访问方式

  • Batch access:访问ContentProvider的一中模式,使用该模式可以同时对provider进行多个操作,且支持同时操作多个表。使用时首先构建一个ContentProviderOperation序列,然后使用ContentResolver.applyBatch方法把这些操作分发到provdier中,调用applyBatch参数时需要传入provider的authority而不是某个表的Uri,这样就可以使得不同的operation查询不同的表。
  • 当你的应用A不具有访问某个provider的权限时,你可以通过Intent的方法来访问。典型的比如选择一个联系人,在A中可以发送一个Intent,设置相应的action和MIME类型,然后就会启动比如联系人应用来供用户选择一个联系人,带选择完后,应用A的onActivityResult中就会收到返回的Intent,通过getData方法得到其中的Uri,这个Uri就指向了用户选择的联系人,同时,在联系人应用通过对返回的intent设置了FLAG_GRANT_READ_URI_PERMISSION以及FLAG_GRANT_WRITE_URI_PERMISSION两个分别给接收该intent的Activity赋予临时读/写该Uri指向的数据的权限,该权限直到该Activity finish之后就失效。另外一中方法就是通过发送Intent,并把需要的额外数据放入Intent中,然后交由另外一个具有该权限的应用去完成你想对该provider的操作。

用户自定义MIME

  • 对于用户自定义的,也称作vendor-specific,的MIME类型,MIME类型的固定格式为type/subtype,对于自定的的MIME,其type固定为:对于多行:vnd.android.cursor.dir,对于单行为:vnd.android.cursor.item,而对于subtype类型则在遵守“vnd.<name>.<type>”形式的范围内由用户自定义。name必须全球唯一,一般为公司名或者报名,type则应该与URI类型有一对一的关系。例如对于一个authority为com.willhua.trains的provider,对应的表分别为list1和list2,那么对于uri,content://com.willhua.trains/list1,其对应的MIME类型可以设定为vnd.android.cursor.dir/vnd.willhua.list1,对于uri,content://com.willhua.trains/list2/5,其对应的MIME类型可以设定为vnd.android.cursor.dir/vnd.willhua.list2。

设计数据结构tips

  • 最好有一个名为_ID的int列来作为primary key,这样的话即可以把它当做foreign key来映射其他表中的数据,而且如果要把provider的查询结果链入listview的,那么就必须有_ID列(BaseColumns._ID;
  • 使用BOLB(binary large object)类型来存储数据体积变化大或者数据结构不同的数据,比如protocol buffer或者JSON数据
  • 同样可以使用BLOB来做一个schema-independent的表。一般来说,定一个int的primarykey,一个表示MIME类型的列,一个或者多个BLOB列,BLOB中的数据则可以根据MIME类型来解释,这样的话就实现了把不同shchema类型的数据存储在了同一个表中,ConatactsContract.Data就是这样一个例子的表。

URI

  • content Uri分成几个部分,首先是开始的schema部分,即content://,这个都是一样的;然后是provider的authority,ContentRsolver就是根据Uri这个部分匹配系统中已知的provider表而确定(resolver)需要使用哪个provider,从而调用相应provider的对于查询方法;然后就是路径或者表;最后就是若是表示单行的Uri则加上行ID。
  • 需要注意的是,路径或者表部分没有限定说只能有一个片段或者层级,比如content://com.willhua.blog/tablea/dataa/8或者content://com.willhua.blog/tablea/datab,这样的Uri也是可以的,其中tablea/dataa和tablea/datab即表示路径部分,且表示的表分别为dataa和datab,这样的做法可以更好的显示表的层级关系。
  • 在使用UriMatcher使用通配符判断Uri类型时,符号‘*’表示任意长度的有效字符,‘#’表示任意长度的数字字符

ContentProvider的实现

  • query():对于查询结果没有任何匹配的项的时候应该返回getCount==0的cursor,而不是null。只有当查询过程中发生错误才返回null。如果provider使用的数据存储不是SQLite,那么可以使用cursor的一些子类,比如MatrixCursor作为返回值。
  • insert():返回的值记得以该表的Uri然后append新插入行的ID.
  • delete():有时候可以考虑使用一个比如delete列来表示该行是否被删除来代替真正的从表中删除
  • update()
  • onCreate():应该尽可能的降低此函数的执行时间以提高响应速度。如果是使用SQLite作为数据存储,那么最好使用SQLiteOpenHelper,它将把创建SQL表的时候延迟到第一次打开database的时候。当第一次调用getWritableDatabase的时候,将调用Helper的onCreate函数。
  • getType():用于返回一个MIME格式的的字符串来描述根据content URI参数返回的数据类型。
  • getStreamTypes():如果provider提供files,那么应该实现此函数。用于返回与content URI对应的MIME类型序列。例如某provider提供.jpg, .png两种图片,如果另一个应用调用getStreamTypes传入的filter参数为“image/*”,那么getStreamTypes应该返回{“image/jpg”, "image/png"}。如果没有任何匹配该filter的,那么返回null。

Provider权限控制

  • 对于放置在内部存储器(internal)上的数据,默认是只能由本应用访问的。但是如果把这些数据作为一个provider的仓库的话,且在没有对provider做额外的权限控制的条件下,那么别的应用程序就可以通过provider完全访问这些数据,也就是相当于把一个私有的数据完全开放了。这并不合理。所以,我们应该根据需要对provider进行一些访问权限控制。
  • 对provider的权限设置可以分为三个级别:整个provider的完全权限,使用provider的android:permission控制,这个权限表示对整个provider的完全读写权限;单独的读或者写权限,使用provider的android:readPermission和android:writePermission分别控制对整个provider的读写权限控制;路径级别的权限控制,使用provider的子元素<path-permission>控制,可以控制针对某个具体的URI的读写,读,写或者三者的权限;
  • 这三个权限的优先级逐级增大,即假如某个数据同时被设定了整个provider的权限和path级别的权限,那么外部应用就得必须有path级别的权限才能访问这个数据。
  • 临时权限,使用provider的android:grantUriPermission属性(默认false)和子元素<grant-uri-permission>来分别控制对整个provider或者某个特定uri的临时权限。具有临时权限的访问忽视前面说的三级权限要求。可以通过Content.revokeUriPermission()来收回针对某个uri的临时权限。在Intent通过FLAG_GRANT_READ_URI_PERMISSION和FLAG_GRANT_WRITE_URI_PERMISSION来给别的应用分别赋予临时读写权限。
  • 如果provider没有指明所需的权限,那么别的应用就无法访问到这个provider。但是在provider所在应用中的其他组件是一直都是忽视所需权限要求的,有对该provider完整的读写权限。