❶ 怎麼提高android contentresolver的查詢效率優化
兩種辦法:
1.創建自己的ContentProvider,需要繼承ContentProvider類
2.如果你的數據和已存在的ContentProvider數據結構一致,可以將數據寫到已存在的ContentProvider中
當然前提是獲取寫該ContentProvider的許可權.比如把OA中的成員通訊信息加入到系統的聯系人ContentProvider中
ContentProvider基礎
所有ContentProvider都需要實現相同的介面,用於查詢ContentProvider並返回數據.也包括增加、修改和刪除數據.
步驟:
1.獲得一個ContentResolver的實例,可通過Activity的成員方法getContentResovler()方法:
ContentResolver cr = this.getContentResolver();
ContentResolver實例帶的方法可實現找到指定的ContentProvider並獲取到ContentProvider的數據
ContentResolver的查詢過程開始,Android系統將確定查詢所需的具體ContentProvider,確認它是否啟動並運行它.
android系統負責初始化所有的ContentProvider,不需要用戶自己去創建.實際上,ContentProvider的用戶都不可能直接訪問到ContentProvider實例,只能通過ContentResolver在中間代理.
2.數據模型
ContentProvider展示數據類似一個單個資料庫表.
其中:
每行有個帶唯一值的數字欄位,名為_ID,可用於對表中指定記錄的定位.
ContentProvider返回的數據結構,是類似JDBC的ResultSet,在android中,是Cursor對象.
URI,每個ContentProvider定義一個唯一的公開的URI,用於指定到它的數據集.
一個ContentProvider可以包含多個數據集(可以看作多張表),這樣,就需要有多個URI與每個數據集對應.
這些URI要以這樣的格式開頭:
content://
表示這個URI指定一個ContentProvider.
如果你想創建自己的ContentProvider,最好把自定義的URI設置為類的常量,這樣簡化別人的調用,並且以後如果更新URI也很容易.
android定義了CONTENT_URI常量用於URI,如:android.provider.Contacts.Phones.CONTENT_URI
2.查詢ContentProvider
要想使用一個ContentProvider,需要以下信息:
定義這個ContentProvider的URI,返回結果的欄位名稱,這些欄位的數據類型
如果需要查詢ContentProvider數據集的特定記錄(行),還需要知道該記錄的ID的值.
構建查詢
查詢就是輸入URI等參數,其中URI是必須的,其他是可選的,如果系統能找到URI對應的ContentProvider將返回一個Cursor對象.
可以通過ContentResolver.query()或者Activity.managedQuery()方法.
兩者的方法參數完全一樣,查詢過程和返回值也是相同的.
區別是,通過Activity.managedQuery()方法,不但獲取到Cursor對象,而且能夠管理Cursor對象的生命周期.
比如當Activity暫停(pause)的時候,卸載該Cursor對象,當Activity Restart的時候重新查詢.另外,也可以對一個沒有處於Activity管理的Cursor對象做成被Activity管理的,通過調用Activity.startManaginCursor()方法.
類似這樣:
Cursor cur = managedQuery(myPerson,null,null,null,null);
其中第一個參數myPerson是Uri類型實例.
如果需要查詢的是指定行的記錄,需要用_ID值,比如ID值為23,URI將是類似:
content://....../23
android提供了方便的方法,讓開發者不需要自己拼接上面這樣的URI,比如類似:
Uri myPerson = ContentUris.withAppendedId(People.CONTENT_URI,23);
或者:
Uri myPerson = Uri.withAppendedPath(People.CONTENT_URI,"23");
二者的區別是一個接收整數類型的ID值,一個接收字元串類型.
其他幾個參數:
names,可以為null,表示取數據集的全部列,或者聲明一個String數組,數組中存放列名稱,比如:People._ID.一般列名都在該ContentProvider中有常量對應;
針對返回結果的過濾器,格式類似於SQL中的WHERE子句,區別是不帶WHERE關鍵字,如果返回null表示不過濾,比如name=?;
前面過濾器的參數,是String數組,是針對前面條件中?佔位符的值;
排序參數,類似SQL的ORDER BY字句,不過不需要寫ORDER BY部分,比如name desc,如果不排序,可輸入null.
返回值是Cursor對象,游標位置在第一條記錄之前.
下面實例適用於android 2.0及以上版本,從android通訊錄中得到姓名欄位:
java代碼:
Cursor cursor = getContentResolver().query(ContactsContract.CommonDataKinds.Phone.CONTENT_URI,null,null,null,null);
讀取返回的數據
如果在查詢的時候使用到ID,那麼返回的數據只有一條記錄.在其他情況下,一般會有多條記錄.和JDBC的ResultSet類似,需要操作游標遍歷結果集,在每行,再通過列名獲取到列的值,可以通過getString()、getInt()、getFloat()等方法獲取值.
比如類似下面:
java代碼:
while(cursor.moveToNext()) {
builder.append(cursor.getString(cursor.getColumnIndex(ContactsContract.CommonDataKinds.Phone.DISPLAY_NAME))).append("-");
}
和JDBC中不同,沒有直接通過列名獲取列值的方法,只能先列名獲取到列的整型索引值,然後再通過該索引值定位獲取列的值.
編輯數據
可以通過ContentProvider實現以下編輯功能:
增加新的記錄:
在已經存在的記錄中增加新的值、批量更新已經存在的多個記錄、刪除記錄.
所有的編輯功能都是通過ContentResolver的方法實現.一些ContentProvider對許可權要求更嚴格一些,需要寫的許可權,如果沒有會報錯.
增加記錄
要想增加記錄到ContentProvider,首先,要在ContentValues對象中設置類似map的鍵值對,在這里,鍵的值對應ContentProvider中的列的名字,鍵值對的值,是對應列希望的類型.
然後,調用ContentResolver.insert()方法,傳入這個ContentValues對象,和對應ContentProvider的URI即可.返回值是這個新記錄的URI對象.這樣你可以通過這個URI獲得包含這條記錄的Cursor對象.
比如:
java代碼:
ContentValues values = new ContentValues();
values.put(People.NAME,"Abraham Lincoln");
Uri uri = getContentResolver().insert(People.CONTENT_URI, values);
在原有記錄上增加值
如果記錄已經存在,可在記錄上增加新的值,或者編輯已經存在的值.
首先要找到原來的值對象,然後要清除原有的值,然後像上面增加記錄一樣即可:
java代碼:
Uri uri = Uri.withAppendedPath(People.CONTENT_URI, "23");
Uri phoneUri = Uri.withAppendedPath(uri, People.Phones.CONTENT_DIRECTORY);
values.clear();
values.put(People.Phones.TYPE, People.Phones.TYPE_MOBILE);
values.put(People.Phones.NUMBER, "1233214567");
getContentResolver().insert(phoneUri, values);
批量更新值
批量更新一組記錄的值,比如NY改名為Eew York.可調用ContentResolver.update()方法.
刪除記錄
如果是刪除單個記錄,調用ContentResolver.delete()方法,URI參數,指定到具體行即可.
如果是刪除多個記錄,調用ContentResolver.delete()方法,URI參數指定Contentprovider即可,並帶一個類似SQL的WHERE子句條件.這里和上面類似,不帶WHERE關鍵字.
創建自己的ContentProvider
創建contentprovider,需要設置存儲系統.大多數ContentProvider使用文件或者SQLite資料庫,不過你可以用任何方式存儲數據.android提供SQLiteOpenHelper幫助開發者創建和管理SQLiteDatabase.
繼承ContentProvider,提供對數據的訪問.在manifest文件中聲明ContentProvider.繼承ContentProvider類
必須定義ContentProvider類的子類,需要實現如下方法:
java代碼:
query()
insert()
update()
delete()
getType()
onCreate()
在實現子類的時候,還有一些步驟可以簡化ContentProvider客戶端的使用:
定義public static final Uri常量,名稱為CONTENT_URI:
java代碼:
public static final Uri CONTENT_URI = Uri.parse("content://com.example.codelab.transportationprovider");
如果有多個表,它們也是使用相同的CONTENT_URI,只是它們的路徑部分不同.
聲明ContentProvider
創建ContentProvider後,需要在manifest文件中聲明,android系統才能知道它,當其他應用需要調用該ContentProvider時才能創建或者調用它.
語法類似:
<provider android:name="com.easymorse.cp.MyContentProvider"
android:authorities="com.easymorse.cp.mycp">
</provider>
android:name要寫ContentProvider繼承類的全名.
android:authorities要寫和CONTENT_URI常量的B部分
❷ android 中的uri到底是什麼
URI是統一資源標識符(Uniform Resource Identifier) 的意思,它的作用是根據這個URI找到某個資源文件,基本格式如: file:///sdcard/temp.jpg(就是根據你提供的例子生成的一個路徑)
ContentProvider是程序間共享數據的,它也需要生成URI供別的程序調用,格式如:
content:///StudentDB/student/name,以後你在別的程序想訪問另一個程序里的資料庫,就可以用這個URI去訪問了,而不用進行資料庫連接的操作,非常方便
URL顯得很宏觀,是網路資源定位的,而URI是應用程序內部或之間定位
❸ android如何通過path得到uri
最近做項目要通過圖片的絕對路徑找到圖片的URI,然後刪除圖片,小小總結一下獲取URI的方法,親自試驗在
android 4.1.3的系統上都是可用的。
1.將所有的圖片路徑取出,遍歷比較找到需要的路徑,取出URI,效率較低
其中 MediaStore.MediaColumns.DATA 欄位存的就是圖片的絕對路徑,
最後mImageUri得到的就是圖片的URI
1 Uri mUri = Uri.parse("content://media/external/images/media");
2 Uri mImageUri = null;
3 Cursor cursor = managedQuery(
4 MediaStore.Images.Media.EXTERNAL_CONTENT_URI, null, null, null,
5 MediaStore.Images.Media.DEFAULT_SORT_ORDER);
6 cursor.moveToFirst();
7
8 while (!cursor.isAfterLast()) {
9 String data = cursor.getString(cursor
10 .getColumnIndex(MediaStore.MediaColumns.DATA));
11 if (picPath.equals(data)) {
12 int ringtoneID = cursor.getInt(cursor
13 .getColumnIndex(MediaStore.MediaColumns._ID));
14 mImageUri = Uri.withAppendedPath(mUri, "" + ringtoneID);
15 break;
16 }
17 cursor.moveToNext();
18 }2.直接從媒體資料庫根據欄位取出相應的記錄,效率較高
1 //TYLT: add by anyf 20121027 start
2 String type = Utils.ensureNotNull(intent.getType());
3 Log.d(TAG, "uri is " + uri);
4 if (uri.getScheme().equals("file") && (type.contains("image/")))
{
5 String path = uri.getEncodedPath();
6 Log.d(TAG, "path1 is " + path);
7 if (path != null) {
8 path = Uri.decode(path);
9 Log.d(TAG, "path2 is " + path);
10 ContentResolver cr = this.getContentResolver();
11 StringBuffer buff = new StringBuffer();
12 buff.append("(")
13 .append(Images.ImageColumns.DATA)
14 .append("=")
15 .append("'" + path + "'")
16 .append(")");
17 Cursor cur = cr.query(
18 Images.Media.EXTERNAL_CONTENT_URI,
19 new String[] { Images.ImageColumns._ID },
20 buff.toString(), null, null);
21 int index = 0;
22 for (cur.moveToFirst(); !cur.isAfterLast(); cur
23 .moveToNext()) {
24 index = cur.getColumnIndex(Images.ImageColumns._ID);
25 // set _id value
26 index = cur.getInt(index);
27 }
28 if (index == 0) {
29 //do nothing
30 } else {
31 Uri uri_temp = Uri
32 .parse("content://media/external/images/media/"
33 + index);
34 Log.d(TAG, "uri_temp is " + uri_temp);
35 if (uri_temp != null) {
36 uri = uri_temp;
37 }
38 }
39 }
40 }
41 //TYLT: add by anyf 20121027 end3.直接根據路徑通過 ContentProvider 的 delete() 方法刪除圖片,兩行代碼搞定,效率最高
1 String params[] = new String[]{filepath};
2
ctx.getContentResolver().delete(MediaStore.Images.Media.EXTERNAL_CONTENT_URI,
MediaStore.Images.Media.DATA + " LIKE ?", params);
❹ Android四大組件是什麼講講你對它們的理解
Android有四大組件:Activity、Service、Broadcast Receiver、Content Provider。
Activity
做一個完整的Android程序,不想用到Activity,真的是比較困難的一件事情,除非是想做綠葉想瘋了。因為Activity是Android程序與用戶交互的窗口,在我看來,從這個層面的視角來看,Android的Activity特像網站的頁面。
Activity,在四大組件中,無疑是最復雜的,這年頭,一樣東西和界面掛上了勾,都簡化不了,想一想,獨立做一個應用有多少時間淪落在了界面上,就能琢磨清楚了。從視覺效果來看,一個Activity占據當前的窗口,響應所有窗口事件,具備有控制項,菜單等界面元素。從內部邏輯來看,Activity需要為了保持各個界面狀態,需要做很多持久化的事情,還需要妥善管理生命周期,和一些轉跳邏輯。對於開發者而言,就需要派生一個Activity的子類,然後埋頭苦幹上述事情。對於Activity的更多細節,先可以參見:reference/android/app/Activity.html。後續,會獻上更為詳盡的剖析。
Service
服務,從最直白的視角來看,就是剝離了界面的Activity,它們在很多Android的概念方面比較接近,都是封裝有一個完整的功能邏輯實現,只不過Service不拋頭露臉,只是默默無聲的做堅實的後盾。
但其實,換個角度來看,Android中的服務,和我們通常說的Windows服務,Web的後台服務又有一些相近,它們通常都是後台長時間運行,接受上層指令,完成相關事務的模塊。用運行模式來看,Activity是跳,從一個跳到一個,呃...,這有點像模態對話框(或者還像web頁面好了...),給一個輸入(抑或沒有...),然後不管不顧的讓它運行,離開時返回輸出(同抑或沒有...)。
而Service不是,它是等,等著上層連接上它,然後產生一段持久而纏綿的通信,這就像一個用了Ajax頁面,看著沒啥變化,偷偷摸摸的和Service不知眉來眼去多少回了。
但和一般的Service還是有所不同,Android的Service和所有四大組件一樣,其進程模型都是可以配置的,調用方和發布方都可以有權利來選擇是把這個組件運行在同一個進程下,還是不同的進程下。這句話,可以拿把指甲刀刻進腦海中去,它凸顯了Android的運行特徵。如果一個 Service,是有期望運行在於調用方不同進程的時候,就需要利用Android提供的RPC機制,為其部署一套進程間通信的策略。
Android的RPC實現,如上圖所示(好吧,也是從SDK中拿來主義的...),無甚稀奇,基於代理模式的一個實現,在調用端和服務端都去生成一個代理類,做一些序列化和反序列化的事情,使得調用端和伺服器端都可以像調用一個本地介面一樣使用RPC介面。
Android中用來做數據序列化的類是Parcel,參見:/reference/android/os/Parcel.html,封裝了序列化的細節,向外提供了足夠對象化的訪問介面,Android號稱實現非常高效。
還有就是AIDL (Android Interface Definition Language) ,一種介面定義的語言,服務的RPC介面,可以用AIDL來描述,這樣,ADT就可以幫助你自動生成一整套的代理模式需要用到的類,都是想起來很乏力寫起來很苦力的那種。更多內容,可以再看看:guide/developing/tools/aidl.html,如果有興致,可以找些其他PRC實現的資料lou幾眼。
關於Service的實現,還強推參看API Demos這個Sample裡面的RemoteService實現。它完整的展示了實現一個Service需要做的事情:那就是定義好需要接受的Intent,提供同步或非同步的介面,在上層綁定了它後,通過這些介面(很多時候都是RPC的...)進行通信。在RPC介面中使用的數據、回調介面對象,如果不是標準的系統實現(系統可序列化的),則需要自定義aidl,所有一切,在這個Sample里都有表達,強薦。
Service從實現角度看,最特別的就是這些RPC的實現了,其他內容,都會接近於Activity的一些實現,也許不再會詳述了。
Broadcast Receiver
在實際應用中,我們常需要等,等待系統抑或其他應用發出一道指令,為自己的應用擦亮明燈指明方向。而這種等待,在很多的平台上,都會需要付出不小的代價。
比如,在Symbian中,你要等待一個來電消息,顯示歸屬地之類的,必須讓自己的應用忍辱負重偷偷摸摸的開機啟動,消隱圖標隱藏任務項,潛伏在後台,監控著相關事件,等待轉瞬即逝的出手機會。這是一件很發指的事情,不但白白耗費了系統資源,還留了個流氓軟體的罵名,這真是賣力不討好的正面典型。
在Android中,充分考慮了廣泛的這類需求,於是就有了Broadcast Receiver這樣的一個組件。每個Broadcast Receiver都可以接收一種或若干種Intent作為觸發事件(有不知道Intent的么,後面會知道了...),當發生這樣事件的時候,系統會負責喚醒或傳遞消息到該Broadcast Receiver,任其處置。在此之前和這以後,Broadcast Receiver是否在運行都變得不重要了,及其綠色環保。
這個實現機制,顯然是基於一種注冊方式的,Broadcast Receiver將其特徵描述並注冊在系統中,根據注冊時機,可以分為兩類,被我冠名為冷熱插拔。所謂冷插拔,就是Broadcast Receiver的相關信息寫在配置文件中(求配置文件詳情?稍安,後續奉上...),系統會負責在相關事件發生的時候及時通知到該Broadcast Receiver,這種模式適合於這樣的場景。某事件方式 -> 通知Broadcast -> 啟動相關處理應用。比如,監聽來電、郵件、簡訊之類的,都隸屬於這種模式。而熱插拔,顧名思義,插拔這樣的事情,都是由應用自己來處理的,通常是在 OnResume事件中通過registerReceiver進行注冊,在OnPause等事件中反注冊,通過這種方式使其能夠在運行期間保持對相關事件的關注。比如,一款優秀的詞典軟體(比如,有道詞典...),可能會有在運行期間關注網路狀況變化的需求,使其可以在有廉價網路的時候優先使用網路查詢詞彙,在其他情況下,首先通過本地詞庫來查詞,從而兼顧腰包和體驗,一舉兩得一石二鳥一箭雙雕(注,真實在有道詞典中有這樣的能力,但不是通過 Broadcast Receiver實現的,僅以為例...)。而這樣的監聽,只需要在其工作狀態下保持就好,不運行的時候,管你是天大的網路變化,與我何干。其模式可以歸結為:啟動應用 -> 監聽事件 -> 發生時進行處理。
除了接受消息的一方有多種模式,發送者也有很重要的選擇權。通常,發送這有兩類,一個就是系統本身,我們稱之為系統Broadcast消息,在reference/android/content/Intent.html 的Standard Broadcast Actions,可以求到相關消息的詳情。除了系統,自定義的應用可以放出Broadcast消息,通過的介面可以是 Context.sendBroadcast,抑或是Context.sendOrderedBroadcast。前者發出的稱為Normal broadcast,所有關注該消息的Receiver,都有機會獲得並進行處理;後者放出的稱作Ordered broadcasts,顧名思義,接受者需要按資排輩,排在後面的只能吃前面吃剩下的,前面的心情不好私吞了,後面的只能喝西北風了。
當Broadcast Receiver接收到相關的消息,它們通常做一些簡單的處理,然後轉化稱為一條Notification,一次振鈴,一次震動,抑或是啟動一個 Activity進行進一步的交互和處理。所以,雖然Broadcast整個邏輯不復雜,卻是足夠有用和好用,它統一了Android的事件廣播模型,讓很多平台都相形見絀了。更多Broadcast Receiver相關內容,參見:/reference/android/content/BroadcastReceiver.html。
Content Provider
Content Provider,聽著就和數據相關,沒錯,這就是Android提供的第三方應用數據的訪問方案。在Android中,對數據的保護是很嚴密的,除了放在SD卡中的數據,一個應用所持有的資料庫、文件、等等內容,都是不允許其他直接訪問的,但有時候,溝通是必要的,不僅對第三方很重要,對應用自己也很重要。
比如,一個聯系人管理的應用。如果不允許第三方的應用對其聯系人資料庫進行增刪該查,整個應用就失去了可擴展力,必將被其他應用拋棄,然後另立門戶,自個玩自個的去了。
Andorid當然不會真的把每個應用都做成一座孤島,它為所有應用都准備了一扇窗,這就是Content Provider。應用想對外提供的數據,可以通過派生ContentProvider類, 封裝成一枚Content Provider,每個Content Provider都用一個uri作為獨立的標識,形如:content://com.xxxxx。所有東西看著像REST的樣子,但實際上,它比REST 更為靈活。和REST類似,uri也可以有兩種類型,一種是帶id的,另一種是列
表的,但實現者不需要按照這個模式來做,給你id的uri你也可以返回列表類型的數據,只要調用者明白,就無妨,不用苛求所謂的REST。
另外,Content Provider不和REST一樣只有uri可用,還可以接受Projection,Selection,OrderBy等參數,這樣,就可以像資料庫那樣進行投影,選擇和排序。查詢到的結果,以Cursor(參見:reference/android/database/Cursor.html )的形式進行返回,調用者可以移動Cursor來訪問各列的數據。
Content Provider屏蔽了內部數據的存儲細節,向外提供了上述統一的介面模型,這樣的抽象層次,大大簡化了上層應用的書寫,也對數據的整合提供了更方便的途徑。Content Provider內部,常用資料庫來實現,Android提供了強大的Sqlite支持,但很多時候,你也可以封裝文件或其他混合的數據。
在Android中,ContentResolver是用來發起Content Provider的定位和訪問的。不過它僅提供了同步訪問的Content Provider的介面。但通常,Content Provider需要訪問的可能是資料庫等大數據源,效率上不足夠快,會導致調用線程的擁塞。因此Android提供了一個AsyncQueryHandler(參見:reference/android/content/AsyncQueryHandler.html),幫助進行非同步訪問Content Provider。
在各大組件中,Service和Content Provider都是那種需要持續訪問的。Service如果是一個耗時的場景,往往會提供非同步訪問的介面,而Content Provider不論效率如何,都提供的是約定的同步訪問介面。我想這遵循的就是場景導向設計的原則,因為Content Provider僅是提供數據訪問的,它不能確信具體的使用場景如何,會怎樣使用它的數據;而相比之下,Service包含的邏輯更復雜更完整,可以抉擇大部分時候使用某介面的場景,從而確定最貼切的介面是同步還是非同步,簡化了上層調用的邏輯。
❺ Android 兩個Activity之間怎樣使用Uri傳遞圖片,怎樣獲取圖片的Uri,怎樣通過Uri得到圖片
Activity之間傳遞數據是通過Intent來傳遞的。
Intent是一種運行時綁定(run-time binding)機制,它能在程序運行過程中連接兩個不同的組件。通過Intent,你的程序可以向Android表達某種請求或者意願,Android會根據意願的內容選擇適當的組件來完成請求。比如,有一個Activity希望打開網頁瀏覽器查看某一網頁的內容,那麼這個Activity只需要發出WEB_SEARCH_ACTION給Android,Android就會根據Intent的請求內容,查詢各組件注冊時聲明的IntentFilter,找到網頁瀏覽器的Activity來瀏覽網頁。
Android的三個基本組件——Activity,Service和Broadcast Receiver——都是通過Intent機制激活的,不同類型的組件有不同的傳遞Intent方式:
要激活一個新的Activity,或者讓一個現有的Activity做新的操作,可以通過調用Context.startActivity()或者Activity.startActivityForResult()方法。
要啟動一個新的Service,或者向一個已有的Service傳遞新的指令,調用Context.startService()方法或者調用Context.bindService()方法將調用此方法的上下文對象與Service綁定。
Context.sendBroadcast()、Context.sendOrderBroadcast()、Context.sendStickBroadcast()這三個方法可以發送Broadcast Intent。發送之後,所有已注冊的並且擁有與之相匹配IntentFilter的BroadcastReceiver就會被激活。
Intent一旦發出,Android都會准確找到相匹配的一個或多個Activity,Service或者BroadcastReceiver作響應。所以,不同類型的Intent消息不會出現重疊,即Broadcast的Intent消息只會發送給BroadcastReceiver,而決不會發送給Activity或者Service。由startActivity()傳遞的消息也只會發給Activity,由startService()傳遞的Intent只會發送給Service。
❻ 怎麼使用融雲IM的推送功能,融雲推送API
為了接收推送消息,您需要自定義一個繼承自 PushMessageReceiver 類的 BroadcastReceiver (必須實現,否則會收不到推送消息),實現其中的 onNotificationMessageArrived,onNotificationMessageClicked 然後把該 receiver 注冊到 AndroidManifest.xml 文件中。
自定義的 BroadcastReceiver:
public class DemoNotificationReceiver extends PushMessageReceiver {
@Override
public boolean onNotificationMessageArrived(Context context, PushNotificationMessage message) {
return false;
}
@Override
public boolean onNotificationMessageClicked(Context context, PushNotificationMessage message) {
return false;
}
}
注冊到應用的 AndroidManifest.xml 裡面:
<receiver
android:exported="true"
android:name="您自定義的 broadcastReceiver 類名">
<intent-filter>
<action android:name="io.rong.push.intent.MESSAGE_ARRIVED" />
<action android:name="io.rong.push.intent.MI_MESSAGE_ARRIVED" />
<action android:name="io.rong.push.intent.MESSAGE_CLICKED" />
<action android:name="io.rong.push.intent.MI_MESSAGE_CLICKED" />
</intent-filter>
</receiver>
onNotificationMessageArrived 用來接收伺服器發來的通知欄消息(消息到達客戶端時觸發),默認return false,通知消息會以融雲 SDK 的默認形式展現。如果需要自定義通知欄的展示,在這里實現自己的通知欄展現代碼,同時 return true 即可。
onNotificationMessageClicked 是在用戶點擊通知欄消息時觸發 (注意:如果自定義了通知欄的展現,則不會觸發),默認 return false 。如果需要自定義點擊通知時的跳轉,return true 即可。融雲 SDK 默認跳轉規則如下
只有一個聯系人發來一條或者多條消息時,會通過 intent 隱式啟動會話 activity,intent 的 uri 如下:
Intent intent = new Intent();
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
Uri.Builder builder = Uri.parse("rong://" + this.getPackageName()).buildUpon();
builder.appendPath("conversation").appendPath(type.getName())
.appendQueryParameter("targetId", targetId)
.appendQueryParameter("title", targetName);
uri = builder.build();
intent.setData(uri);
startActivity(intent);
如果你的 AndroidManifest.xml 裡面配置 A activity 攔截了這個 intent ,那在點擊這條通知欄消息 時就會啟動 activity A 。
<activity
android:name="A"
android:launchMode="singleTop"
android:screenOrientation="portrait"
android:windowSoftInputMode="stateHidden|adjustResize">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<data
android:host="你的包名"
android:pathPrefix="/conversation/"
android:scheme="rong" />
</intent-filter>
</activity>
多個聯系人發來多條消息時,通過 intent 隱式啟動會話列表 activity,intent 的 uri 配置如下:
Intent intent = new Intent();
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
Uri.Builder builder = Uri.parse("rong://" + this.getPackageName()).buildUpon();
builder.appendPath("conversationlist");
Uri uri = builder.build();
intent.setData(uri);
startActivity(intent);
如果你的 AndroidManifest.xml 裡面配置 B activity 攔截了這個 intent,那在點擊這條通知欄消息 時就會啟動 activity B。
<activity
android:name="B"
android:launchMode="singleTask"
android:screenOrientation="portrait"
android:windowSoftInputMode="stateHidden|adjustResize">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<data
android:host="你的包名"
android:path="/conversationlist"
android:scheme="rong" />
</intent-filter>
</activity>
可以在融雲開發者後台廣播推送-廣播消息-推送中,發起遠程推送。
點擊推送消息時會觸發出如下 action 事件:
Intent intent = new Intent();
intent.setFlags(intent.FLAG_ACTIVITY_NEW_TASK);
Uri.Builder uriBuilder = Uri.parse("rong://" + this.getPackageName()).buildUpon();
uriBuilder.appendPath("push_message")
.appendQueryParameter("targetId", targetId)
.appendQueryParameter("pushData", pushData)
.appendQueryParameter("pushId", pushId)
.appendQueryParameter("extra", extra);
startActivity(intent);
如果你的 AndroidManifest.xml 裡面配置了 C activity 攔截這個 action, 那麼點擊時就會跳轉到 activity C。
<activity
android:name="C"
android:launchMode="singleTask"
android:screenOrientation="portrait">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<data
android:host="你的包名"
android:pathPrefix="/push_message"
android:scheme="rong" />
</intent-filter>
</activity>
通過以上步驟,您已完成了融雲推送服務的集成。
❼ URI是什麼,在Android中有什麼作用
通用資源標志符(Universal Resource Identifier, 簡稱"URI")。
Uri代表要操作的數據,Android上可用的每種資源 - 圖像、視頻片段等都可以用Uri來表示。
URI一般由三部分組成:
在Android平台,URI主要分三個部分:scheme, authority and path。
其中authority又分為host和port。格式如下:scheme://host:port/path
舉個實際的例子:
content://com.example.project:200/folder/subfolder/etc
\---------/ \------------------ -/ \--/ \----------------------/
scheme host port path
\---------------------------/
authority
我們很經常需要解析Uri,並從Uri中獲取數據。
Android系統提供了兩個用於操作Uri的工具類,分別為UriMatcher 和ContentUris 。
掌握它們的使用,會便於我們的Android開發工作。
❽ 什麼是android的四大組件
Android四大組件有Activity,Service服務,Content Provider內容提供,BroadcastReceiver廣播接收器。
Android應用程序由一些零散的有聯系的組件組成,通過一個工程manifest綁定在一起。在manifest中,描述了每一個組件以及組件的作用,其中有6個組件,它們是Android應用程序的基石
(8)androiribuilder擴展閱讀
Activities(活動)
應用程序的顯示層。每一個畫面對應於你的應用程序,將會是Activity類的擴展。Activity使用Views去構建UI來顯示信息和響應用戶的行為。就桌面開發而言,一個Activity相當於一張Form。
Services(服務)
Android應用程序中不可見的「工人」。 Service組件運行時不可見,但它負責更新的數據源和可見的Activity,以及觸發通知。它們常用來執行一些需要持續運行的處理,當你的 Activity已經不處於激活狀態或不可見。
Content(內容)
提供共享的數據存儲。Content Provider(內容提供器)用來管理和共享應用程序的資料庫。在應用程序間,Content Provider是共享數據的首選方式。
Broadcast Receivers(廣播接收器)
Intent廣播的「消費者」。通過創建和注冊一個Broadcast Receiver,應用程序可以監聽符合特定條件的廣播的Intent。Broadcast Receiver 會自動的啟動你的Android應用程序去響應新來的Intent。Broadcast Receiver是事件驅動程序的理想手段。
參考資料來源:網路-Android組件