udacity android 学习笔记: lesson 4 part b

udacity android 学习笔记: lesson 4 part b

---

作者：干货店打杂的 /titer1 /Archimedes
出处：https://code.csdn.net/titer1
联系：1307316一九六八
声明：本文採用下面协议进行授权： 自由转载-非商用-非衍生-保持署名|Creative Commons BY-NC-ND 3.0 ，转载请注明作者及出处。
tips:https://code.csdn.net/titer1/pat_aha/blob/master/Markdown/android/

---

lesson 4b，后期将拆分为4大小节
强烈建议保留自己重命名的字幕，又一次压制
29 units are waitted 

上一章节完毕了 db的创建和内容的创建，这章节将讲到content provider,
期待全部内容的大团结（汇总）

why contents providers matter

怎样 理解 多个app 与一个 content provider 的联系

一 create a content provider

more todo

深入 分析contentProvider,
see instructor notes below
在api sdk中

1.1 what is URI

data is assiated with views in the terms of universal resource identifiers or URIs.

一句话，universal resource identifiers简称

又见观察者模式
the code register an android construct called a content observer

1.2 重点 重复 how to build a content provider

- determine URIs
- update contract
- fill out URI matcher
- Implement fuctions

1.2.1 define a URI

- weather / location for insert /update/delete
- weather_with_location 多天情况
- weather_with_location_and_date 一天情况

回想 contract
it is an agreement etween the data models , storrage, and views

下一步将会讲到怎样 更新 contract

1.2.2 update URI

4b-3 lesson todo
？ 为什么要绑定一串数字？一个URI相应一常数？
最好的事就是这里加上调试的记录（动态）

这章节就是在讲 weatherContract类的变化
- add content_URI
- add content_type

细心的人会发现，上图中的部分是为URI的初始化做准备

这是须要兴许代码跟踪的位置，这里构成query.

build uri

下面是checklist

看下图，注意本图 和 上去两个图的差别
- buildweatheruri 曾经是没有实现的

1.2.3 fill out URImatcher

urimatcher:
uses a simple expression ayntax to help us match URI’s for a content provider

直觉，正則表達式

- #表示number
- *表示string

实践时间

让我们看看下一步干什么

代码如上，就是这样

曾经是fake data,如今是基于数据库的data 构成uri

1.2.4 content provider

1 2 4 1 register the content provider

复习，什么是contact ?约定？
进入到 test provider 的环节，

lesson 4b_9 now

1 2 4 2 content provider replace the SQL ?

register now, tell all(include pakage manager) by xml format

here, the content resolver can resolve it!

next to do:

now ,code time

1 2 4 3 code the content rovider 之 oncreate

时刻想着 这是最后一个环节，contenprovider..这里关注期中的onCreate

gettype 是 content provider的一函数

宛如凝视说的，这里的函数作用就是为了測试uribuilder的使用
还有我们的任务就是加入 weather_with_location_and_date等的响应

品读凝视，作用就在这里

终于这里介绍了原始testGetYpe, 可是不会终于使用！故凝视
又见到todo list

只是答案非常快就有了,
比上上一个图，我们添加了两种 uri类型

1 2 4 4 难 code the content rovider 之 query

刚刚把子标题标注好了,oh ,yeah!

悄悄看了下prtplayer 的视频选项，惊叹 多媒体播放器的集成画质改动！ yeah!
细心的点开 历史版本号记录，知道potplayer的开发历程，艰辛！

这就是query，传说中比較复杂的函数

下面是query函数的底部，有重要要说

• tell the observer they listen to the changes that happen to that URI and any of its descendants

又见观察者模式，界面感知底层增/减/变，都靠它了
话说 setNotificationUri不止一处，待确认.

当全部的query代码加入好了，我们能够打开下面的凝视，測试我们的provider

来吧，又是一个任务

这是 完毕 全部query的时候，aha!

first weahther query code:

then, location query code:

初步比較，感觉直觉第一个參数，table名字不一样。

有了两张表，不操作的话，就是独立的两张表，可是须要inner join他们
所以

meaning :
tbl inner join tbl2 on tbl.loc_key = tbl2.id

下面是selection，我觉得就是帮助记忆的

下面是调用sqlbuilder query相关函数，
- 调用了 sqlbuiler(简称呼）
- 使用了刚才封装的selection字符函数
- 參数（location/startDate)来源于uri

以上仅仅有location,下面将同一时候包括location和date进行查询

以上两个函数都被一下调用，content provider的query

能够为上面的三个函数图 绘制一个调用diagram
其它：有没有在线 sql 数据库 语法 练习器
online sql

小憩

• 假设单张表的查询（仅仅看天气或者Location），直接在content provider的query函数中调用
  sql相关的qurey函数
• 假设涉及到两张表的查询，就要单独处理，这里使用了 sqliteQueryBuilder

query操作完毕，只是第四环节还有其它操作，继续

task insert

前篇有2分钟，代码就是上面这幅，只是细节
- 异常处理
- 插入uri 相关的trick (待研究insert时深入 todo)

又见任务牌，先在目标就是完好insert
”’
强烈建议保留自己重命名的字幕，又一次压制
”’

get id for insert ? now:

tell oberserver now:

測试驱动的开发，例如以下，美丽

task update + delete

lesson 4b_22
这里的套路 和 Inset 是一样的，
取得 row courserr ,tell obersver... have a test
所以要补图，或者补代码，后期补上，ok

todo

• update get couser

• update fun tell observer

• delete function get courser

• delete functionj tell obersver

• call the test unit to ganrantee the work

高效的 update & insert

批量插入 比 逐条插入 快
封装为事务 transaction
第一轮的直觉，这不是 高效，这是为了 方便 事务回滚？
todo 思考 ,快多少？ 10倍？

重复 总结篇 content provider redux

理论上，我应该把经典的图再给站上来。、
事实上应该把这里虽有字幕给摘抄出来，逐步分析。
todo
最后一句，“but we still use it in our code ”,兴许将会用到实际项目里面

todo

creat fetch weahter task

拍一个有羽毛的机器人吧
重构